- 27 Aug, 2020 40 commits
-
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit e1869678 ] The length of the key comes from the network and it's a 16 bit number. It needs to be capped to prevent a buffer overflow. Fixes: 5e6e3a92 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Ganapathi Bhat <ganapathi.bhat@nxp.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200708115857.GA13729@mwandaSigned-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by:
Ian May <ian.may@canonical.com> Signed-off-by:
Kelsey Skunberg <kelsey.skunberg@canonical.com>
-
Laurent Pinchart authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit a6ae2fe5 ] The LG LB070WV8 panel incorrectly reports a 16 bits per component value, while the panel uses 8 bits per component. Fix it. Fixes: dd015002 ("drm/panel: simple: Add support for LG LB070WV8 800x480 7" panel") Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200711225317.28476-1-laurent.pinchart+renesas@ideasonboard.comSigned-off-by:
-
Chuhong Yuan authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 18ffec75 ] fimc_md_get_pinctrl() misses a check for pinctrl_lookup_state(). Add the missed check to fix it. Fixes: 4163851f ("[media] s5p-fimc: Use pinctrl API for camera ports configuration]") Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 2505a210 ] If fw_csr_string() returns -ENOENT, then "name" is uninitialized. So then the "strlen(model_names[i]) <= name_len" is true because strlen() is unsigned and -ENOENT is type promoted to a very high positive value. Then the "strncmp(name, model_names[i], name_len)" uses uninitialized data because "name" is uninitialized. Fixes: 92374e88 ("[media] firedtv: drop obsolete backend abstraction") Signed-off-by:
-
Christophe JAILLET authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 86f2da11 ] The dev_id used in request_irq() and free_irq() should match. Use 'info' in both cases. Link: https://lore.kernel.org/r/20200626040553.944352-1-christophe.jaillet@wanadoo.fr Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Christophe JAILLET authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit d179f7c7 ] The dev_id used in request_irq() and free_irq() should match. Use 'info' in both cases. Link: https://lore.kernel.org/r/20200626035948.944148-1-christophe.jaillet@wanadoo.fr Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Colin Ian King authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 7ee78aff ] There is an off-by-one bounds check on the index into arrays table->mc_reg_address and table->mc_reg_table_entry[k].mc_data[j] that can lead to reads and writes outside of arrays. Fix the bound checking off-by-one error. Addresses-Coverity: ("Out-of-bounds read/write") Fixes: cc8dbbb4 ("drm/radeon: add dpm support for CI dGPUs (v2)") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Christophe JAILLET authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 040ab9c4 ] The dev_id used in request_irq() and free_irq() should match. Use 'info' in both cases. Link: https://lore.kernel.org/r/20200625204730.943520-1-christophe.jaillet@wanadoo.fr Fixes: 1da177e4 ("Linux-2.6.12-rc2") Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Chuhong Yuan authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit dc7690a7 ] preview_init_entities() does not call v4l2_ctrl_handler_free() when it fails. Add the missed function to fix it. Fixes: de1135d4 ("[media] omap3isp: CCDC, preview engine and resizer") Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 985b1f59 ] clang points out that doing arithmetic between diffent enums is usually a mistake: drivers/leds/leds-lm355x.c:167:28: warning: bitwise operation between different enumeration types ('enum lm355x_tx2' and 'enum lm355x_ntc') [-Wenum-enum-conversion] reg_val = pdata->pin_tx2 | pdata->ntc_pin; ~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~ drivers/leds/leds-lm355x.c:178:28: warning: bitwise operation between different enumeration types ('enum lm355x_tx2' and 'enum lm355x_ntc') [-Wenum-enum-conversion] reg_val = pdata->pin_tx2 | pdata->ntc_pin | pdata->pass_mode; ~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~ In this driver, it is intentional, so add a cast to hide the false-positive warning. It appears to be the only instance of this warning at the moment. Fixes: b98d13c7 ("leds: Add new LED driver for lm355x chips") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Tomasz Duszynski authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit df16c33a ] IIO_CONCENTRATION together with INFO_RAW specifier is used for reporting raw concentrations of pollutants. Raw value should be meaningless before being properly scaled. Because of that description shouldn't mention raw value unit whatsoever. Fix this by rephrasing existing description so it follows conventions used throughout IIO ABI docs. Fixes: 8ff6b3bc ("iio: chemical: Add IIO_CONCENTRATION channel type") Signed-off-by:
Tomasz Duszynski <tomasz.duszynski@octakon.com> Acked-by:
Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Dejin Zheng authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit fd4b8243 ] A call of the function do_take_over_console() can fail here. The corresponding system resources were not released then. Thus add a call of iounmap() and release_mem_region() together with the check of a failure predicate. and also add release_mem_region() on device removal. Fixes: e86bb8ac ("[PATCH] VT binding: Make newport_con support binding") Suggested-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
Dejin Zheng <zhengdejin5@gmail.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> cc: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Dejin Zheng authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 98bd4f72 ] the sfb->fb->screen_base is not save the value get by iounmap() when the chip id is 0x720. so iounmap() for address sfb->fb->screen_base is not right. Fixes: 1461d667 ("staging: sm7xxfb: merge sm712fb with fbdev") Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Cc: Teddy Wang <teddy.wang@siliconmotion.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Qiushi Wu authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit b975abbd ] In intel_gtt_setup_scratch_page(), pointer "page" is not released if pci_dma_mapping_error() return an error, leading to a memory leak on module initialisation failure. Simply fix this issue by freeing "page" before return. Fixes: 0e87d2b0 ("intel-gtt: initialize our own scratch page") Signed-off-by:
Qiushi Wu <wu000273@umn.edu> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Erik Kaneda authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 6a54ebae ] ACPICA commit e17b28cfcc31918d0db9547b6b274b09c413eb70 Object reference counts are used as a part of ACPICA's garbage collection mechanism. This mechanism keeps track of references to heap-allocated structures such as the ACPI operand objects. Recent server firmware has revealed that this reference count can overflow on large servers that declare many field units under the same operation_region. This occurs because each field unit declaration will add a reference count to the source operation_region. This change solves the reference count overflow for operation_regions objects by preventing fieldunits from incrementing their operation_region's reference count. Each operation_region's reference count will not be changed by named objects declared under the Field operator. During namespace deletion, the operation_region namespace node will be deleted and each fieldunit will be deleted without touching the deleted operation_region object. Link: https://github.com/acpica/acpica/commit/e17b28cfSigned-off-by:
Erik Kaneda <erik.kaneda@intel.com> Signed-off-by:
Bob Moore <robert.moore@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Coly Li authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 117f636e ] In register_cache_set(), c is pointer to struct cache_set, and ca is pointer to struct cache, if ca->sb.seq > c->sb.seq, it means this registering cache has up to date version and other members, the in- memory version and other members should be updated to the newer value. But current implementation makes a cache set only has a single cache device, so the above assumption works well except for a special case. The execption is when a cache device new created and both ca->sb.seq and c->sb.seq are 0, because the super block is never flushed out yet. In the location for the following if() check, 2156 if (ca->sb.seq > c->sb.seq) { 2157 c->sb.version = ca->sb.version; 2158 memcpy(c->sb.set_uuid, ca->sb.set_uuid, 16); 2159 c->sb.flags = ca->sb.flags; 2160 c->sb.seq = ca->sb.seq; 2161 pr_debug("set version = %llu\n", c->sb.version); 2162 } c->sb.version is not initialized yet and valued 0. When ca->sb.seq is 0, the if() check will fail (because both values are 0), and the cache set version, set_uuid, flags and seq won't be updated. The above problem is hiden for current code, because the bucket size is compatible among different super block version. And the next time when running cache set again, ca->sb.seq will be larger than 0 and cache set super block version will be updated properly. But if the large bucket feature is enabled, sb->bucket_size is the low 16bits of the bucket size. For a power of 2 value, when the actual bucket size exceeds 16bit width, sb->bucket_size will always be 0. Then read_super_common() will fail because the if() check to is_power_of_2(sb->bucket_size) is false. This is how the long time hidden bug is triggered. This patch modifies the if() check to the following way, 2156 if (ca->sb.seq > c->sb.seq || c->sb.seq == 0) { Then cache set's version, set_uuid, flags and seq will always be updated corectly including for a new created cache device. Signed-off-by:
Coly Li <colyli@suse.de> Reviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Jim Cromie authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit f678ce8c ] ddebug_describe_flags() currently fills a caller provided string buffer, after testing its size (also passed) in a BUG_ON. Fix this by replacing them with a known-big-enough string buffer wrapped in a struct, and passing that instead. Also simplify ddebug_describe_flags() flags parameter from a struct to a member in that struct, and hoist the member deref up to the caller. This makes the function reusable (soon) where flags are unpacked. Acked-by: <jbaron@akamai.com> Signed-off-by:
Jim Cromie <jim.cromie@gmail.com> Link: https://lore.kernel.org/r/20200719231058.1586423-8-jim.cromie@gmail.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Sasi Kumar authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit a95bdfd2 ] Multiple connects/disconnects can cause a crash on the second disconnect. The driver had a problem where it would try to send endpoint commands after it was disconnected which is not allowed by the hardware. The fix is to only allow the endpoint commands when the endpoint is connected. This will also fix issues that showed up when using configfs to create gadgets. Signed-off-by:
Sasi Kumar <sasi.kumar@broadcom.com> Signed-off-by:
Al Cooper <alcooperx@gmail.com> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Felipe Balbi <balbi@kernel.org> Signed-off-by:
-
Evgeny Novikov authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 2468c877 ] Driver does not release memory for device on error handling paths in net2280_probe() when gadget_release() is not registered yet. The patch fixes the bug like in other similar drivers. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Evgeny Novikov <novikov@ispras.ru> Signed-off-by:
-
Bolarinwa Olayemi Saheed authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 9018fd7f ] On failure pcie_capability_read_dword() sets it's last parameter, val to 0. However, with Patch 14/14, it is possible that val is set to ~0 on failure. This would introduce a bug because (x & x) == (~0 & x). This bug can be avoided without changing the function's behaviour if the return value of pcie_capability_read_dword is checked to confirm success. Check the return value of pcie_capability_read_dword() to ensure success. Suggested-by:
Bjorn Helgaas <bjorn@helgaas.com> Signed-off-by:
Bolarinwa Olayemi Saheed <refactormyself@gmail.com> Signed-off-by:
-
Prasanna Kerekoppa authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit fa326654 ] Bss info flag definition need to be fixed from 0x2 to 0x4 This flag is for rssi info received on channel. All Firmware branches defined as 0x4 and this is bug in brcmfmac. Signed-off-by:
Prasanna Kerekoppa <prasanna.kerekoppa@cypress.com> Signed-off-by:
Chi-hsien Lin <chi-hsien.lin@cypress.com> Signed-off-by:
Wright Feng <wright.feng@cypress.com> Signed-off-by:
-
Paul E. McKenney authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 0a3b3c25 ] A large process running on a heavily loaded system can encounter the following RCU CPU stall warning: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 3-....: (20998 ticks this GP) idle=4ea/1/0x4000000000000002 softirq=556558/556558 fqs=5190 (t=21013 jiffies g=1005461 q=132576) NMI backtrace for cpu 3 CPU: 3 PID: 501900 Comm: aio-free-ring-w Kdump: loaded Not tainted 5.2.9-108_fbk12_rc3_3858_gb83b75af7909 #1 Hardware name: Wiwynn HoneyBadger/PantherPlus, BIOS HBM6.71 02/03/2016 Call Trace: <IRQ> dump_stack+0x46/0x60 nmi_cpu_backtrace.cold.3+0x13/0x50 ? lapic_can_unplug_cpu.cold.27+0x34/0x34 nmi_trigger_cpumask_backtrace+0xba/0xca rcu_dump_cpu_stacks+0x99/0xc7 rcu_sched_clock_irq.cold.87+0x1aa/0x397 ? tick_sched_do_timer+0x60/0x60 update_process_times+0x28/0x60 tick_sched_timer+0x37/0x70 __hrtimer_run_queues+0xfe/0x270 hrtimer_interrupt+0xf4/0x210 smp_apic_timer_interrupt+0x5e/0x120 apic_timer_interrupt+0xf/0x20 </IRQ> RIP: 0010:kmem_cache_free+0x223/0x300 Code: 88 00 00 00 0f 85 ca 00 00 00 41 8b 55 18 31 f6 f7 da 41 f6 45 0a 02 40 0f 94 c6 83 c6 05 9c 41 5e fa e8 a0 a7 01 00 41 56 9d <49> 8b 47 08 a8 03 0f 85 87 00 00 00 65 48 ff 08 e9 3d fe ff ff 65 RSP: 0018:ffffc9000e8e3da8 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13 RAX: 0000000000020000 RBX: ffff88861b9de960 RCX: 0000000000000030 RDX: fffffffffffe41e8 RSI: 000060777fe3a100 RDI: 000000000001be18 RBP: ffffea00186e7780 R08: ffffffffffffffff R09: ffffffffffffffff R10: ffff88861b9dea28 R11: ffff88887ffde000 R12: ffffffff81230a1f R13: ffff888854684dc0 R14: 0000000000000206 R15: ffff8888547dbc00 ? remove_vma+0x4f/0x60 remove_vma+0x4f/0x60 exit_mmap+0xd6/0x160 mmput+0x4a/0x110 do_exit+0x278/0xae0 ? syscall_trace_enter+0x1d3/0x2b0 ? handle_mm_fault+0xaa/0x1c0 do_group_exit+0x3a/0xa0 __x64_sys_exit_group+0x14/0x20 do_syscall_64+0x42/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 And on a PREEMPT=n kernel, the "while (vma)" loop in exit_mmap() can run for a very long time given a large process. This commit therefore adds a cond_resched() to this loop, providing RCU any needed quiescent states. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: <linux-mm@kvack.org> Reviewed-by:
Shakeel Butt <shakeelb@google.com> Reviewed-by:
Joel Fernandes (Google) <joel@joelfernandes.org> Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> Signed-off-by:
-
Michael Tretter authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit c704b170 ] Using plain echo to set the "force" connector attribute fails with -EINVAL, because echo appends a newline to the output. Replace strcmp with sysfs_streq to also accept strings that end with a newline. v2: use sysfs_streq instead of stripping trailing whitespace Signed-off-by:
Michael Tretter <m.tretter@pengutronix.de> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Emil Velikov <emil.l.velikov@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170817104307.17124-1-m.tretter@pengutronix.deSigned-off-by:
-
Aditya Pakki authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 659fb5f1 ] On calling pm_runtime_get_sync() the reference count of the device is incremented. In case of failure, decrement the ref count before returning the error. Signed-off-by:
Aditya Pakki <pakki001@umn.edu> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Evgeny Novikov authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit edcb3895 ] neofb_probe() calls neo_scan_monitor() that can successfully allocate a memory for info->monspecs.modedb and proceed to case 0x03. There it does not free the memory and returns -1. neofb_probe() goes to label err_scan_monitor, thus, it does not free this memory through calling fb_destroy_modedb() as well. We can not go to label err_init_hw since neo_scan_monitor() can fail during memory allocation. So, the patch frees the memory directly for case 0x03. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
-
Aditya Pakki authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 9fb10671 ] On calling pm_runtime_get_sync() the reference count of the device is incremented. In case of failure, decrement the reference count before returning the error. Acked-by:
Evan Quan <evan.quan@amd.com> Signed-off-by:
-
Paul E. McKenney authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 9f47eb54 ] Very large I/Os can cause the following RCU CPU stall warning: RIP: 0010:rb_prev+0x8/0x50 Code: 49 89 c0 49 89 d1 48 89 c2 48 89 f8 e9 e5 fd ff ff 4c 89 48 10 c3 4c = 89 06 c3 4c 89 40 10 c3 0f 1f 00 48 8b 0f 48 39 cf 74 38 <48> 8b 47 10 48 85 c0 74 22 48 8b 50 08 48 85 d2 74 0c 48 89 d0 48 RSP: 0018:ffffc9002212bab0 EFLAGS: 00000287 ORIG_RAX: ffffffffffffff13 RAX: ffff888821f93630 RBX: ffff888821f93630 RCX: ffff888821f937e0 RDX: 0000000000000000 RSI: 0000000000102000 RDI: ffff888821f93630 RBP: 0000000000103000 R08: 000000000006c000 R09: 0000000000000238 R10: 0000000000102fff R11: ffffc9002212bac8 R12: 0000000000000001 R13: ffffffffffffffff R14: 0000000000102000 R15: ffff888821f937e0 __lookup_extent_mapping+0xa0/0x110 try_release_extent_mapping+0xdc/0x220 btrfs_releasepage+0x45/0x70 shrink_page_list+0xa39/0xb30 shrink_inactive_list+0x18f/0x3b0 shrink_lruvec+0x38e/0x6b0 shrink_node+0x14d/0x690 do_try_to_free_pages+0xc6/0x3e0 try_to_free_mem_cgroup_pages+0xe6/0x1e0 reclaim_high.constprop.73+0x87/0xc0 mem_cgroup_handle_over_high+0x66/0x150 exit_to_usermode_loop+0x82/0xd0 do_syscall_64+0xd4/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 On a PREEMPT=n kernel, the try_release_extent_mapping() function's "while" loop might run for a very long time on a large I/O. This commit therefore adds a cond_resched() to this loop, providing RCU any needed quiescent states. Signed-off-by:
-
Lihong Kou authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit f9c70bdc ] In the case we set or free the global value listen_chan in different threads, we can encounter the UAF problems because the method is not protected by any lock, add one to avoid this bug. BUG: KASAN: use-after-free in l2cap_chan_close+0x48/0x990 net/bluetooth/l2cap_core.c:730 Read of size 8 at addr ffff888096950000 by task kworker/1:102/2868 CPU: 1 PID: 2868 Comm: kworker/1:102 Not tainted 5.5.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events do_enable_set Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fb/0x318 lib/dump_stack.c:118 print_address_description+0x74/0x5c0 mm/kasan/report.c:374 __kasan_report+0x149/0x1c0 mm/kasan/report.c:506 kasan_report+0x26/0x50 mm/kasan/common.c:641 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135 l2cap_chan_close+0x48/0x990 net/bluetooth/l2cap_core.c:730 do_enable_set+0x660/0x900 net/bluetooth/6lowpan.c:1074 process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264 worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410 kthread+0x332/0x350 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Allocated by task 2870: save_stack mm/kasan/common.c:72 [inline] set_track mm/kasan/common.c:80 [inline] __kasan_kmalloc+0x118/0x1c0 mm/kasan/common.c:515 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529 kmem_cache_alloc_trace+0x221/0x2f0 mm/slab.c:3551 kmalloc include/linux/slab.h:555 [inline] kzalloc include/linux/slab.h:669 [inline] l2cap_chan_create+0x50/0x320 net/bluetooth/l2cap_core.c:446 chan_create net/bluetooth/6lowpan.c:640 [inline] bt_6lowpan_listen net/bluetooth/6lowpan.c:959 [inline] do_enable_set+0x6a4/0x900 net/bluetooth/6lowpan.c:1078 process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264 worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410 kthread+0x332/0x350 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Freed by task 2870: save_stack mm/kasan/common.c:72 [inline] set_track mm/kasan/common.c:80 [inline] kasan_set_free_info mm/kasan/common.c:337 [inline] __kasan_slab_free+0x12e/0x1e0 mm/kasan/common.c:476 kasan_slab_free+0xe/0x10 mm/kasan/common.c:485 __cache_free mm/slab.c:3426 [inline] kfree+0x10d/0x220 mm/slab.c:3757 l2cap_chan_destroy net/bluetooth/l2cap_core.c:484 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_chan_put+0x170/0x190 net/bluetooth/l2cap_core.c:498 do_enable_set+0x66c/0x900 net/bluetooth/6lowpan.c:1075 process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264 worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410 kthread+0x332/0x350 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 The buggy address belongs to the object at ffff888096950000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 0 bytes inside of 2048-byte region [ffff888096950000, ffff888096950800) The buggy address belongs to the page: page:ffffea00025a5400 refcount:1 mapcount:0 mapping:ffff8880aa400e00 index:0x0 flags: 0xfffe0000000200(slab) raw: 00fffe0000000200 ffffea00027d1548 ffffea0002397808 ffff8880aa400e00 raw: 0000000000000000 ffff888096950000 0000000100000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88809694ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88809694ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff888096950000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888096950080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888096950100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Reported-by: syzbot+96414aa0033c363d8458@syzkaller.appspotmail.com Signed-off-by:
Lihong Kou <koulihong@huawei.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Tomi Valkeinen authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 3f9c1c87 ] If videomode_from_timings() returns true, the mode allocated with drm_mode_create will be leaked. Also, the return value of drm_mode_create() is never checked, and thus could cause NULL deref. Fix these two issues. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429104234.18910-1-tomi.valkeinen@ti.comReviewed-by:
Jyri Sarha <jsarha@ti.com> Acked-by:
-
Yu Kuai authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 3ad7b4e8 ] if of_find_device_by_node() succeed, socfpga_setup_ocram_self_refresh doesn't have a corresponding put_device(). Thus add a jump target to fix the exception handling for this function implementation. Fixes: 44fd8c7d ("ARM: socfpga: support suspend to ram") Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Signed-off-by:
Dinh Nguyen <dinguyen@kernel.org> Signed-off-by:
-
yu kuai authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit f87a4f02 ] if of_find_device_by_node() succeed, at91_pm_sram_init() doesn't have a corresponding put_device(). Thus add a jump target to fix the exception handling for this function implementation. Fixes: d2e46790 ("ARM: at91: pm: use the mmio-sram pool to access SRAM") Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200604123301.3905837-1-yukuai3@huawei.comSigned-off-by:
-
Finn Thain authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 931fc82a ] When writing values to the IOP status/control register make sure those values do not have any extraneous bits that will clear interrupt flags. To place the SCC IOP into bypass mode would be desirable but this is not achieved by writing IOP_DMAINACTIVE | IOP_RUN | IOP_AUTOINC | IOP_BYPASS to the control register. Drop this ineffective register write. Remove the flawed and unused iop_bypass() function. Make use of the unused iop_stop() function. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Finn Thain <fthain@telegraphics.com.au> Tested-by:
Stan Johnson <userm57@yahoo.com> Cc: Joshua Thompson <funaho@jurai.org> Link: https://lore.kernel.org/r/09bcb7359a1719a18b551ee515da3c4c3cf709e6.1590880333.git.fthain@telegraphics.com.auSigned-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Finn Thain authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit aeb445bf ] In the following sequence of calls, iop_do_send() gets called when the "send" channel is not in the IOP_MSG_IDLE state: iop_ism_irq() iop_handle_send() (msg->handler)() iop_send_message() iop_do_send() Avoid this by testing the channel state before calling iop_do_send(). When sending, and iop_send_queue is empty, call iop_do_send() because the channel is idle. If iop_send_queue is not empty, iop_do_send() will get called later by iop_handle_send(). Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Qiushi Wu authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 17ed808a ] When kobject_init_and_add() returns an error, it should be handled because kobject_init_and_add() takes a reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Therefore, replace calling kfree() and call kobject_put() and add a missing kobject_put() in the edac_device_register_sysfs_main_kobj() error path. [ bp: Massage and merge into a single patch. ] Fixes: b2ed215a ("Kobject: change drivers/edac to use kobject_init_and_add") Signed-off-by:
Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20200528202238.18078-1-wu000273@umn.edu Link: https://lkml.kernel.org/r/20200528203526.20908-1-wu000273@umn.eduSigned-off-by:
-
Uwe Kleine-König authored
BugLink: https://bugs.launchpad.net/bugs/1892822 This happens for the spi-imx driver when running a dt-enabled kernel on a non-dt machine on Linux 4.0. Among the still supported stable versions only 4.4 and 4.9 are affected. (However the spi-imx driver doesn't call of_get_named_gpio() since v4.8-rc1 (commit b36581df ("spi: imx: Using existing properties for chipselects")) any more, but the problem might still affect other users of of_get_named_gpio().) In 4.14-rc1 this problem is gone with commit 7eb6ce2f ("gpio: Convert to using %pOF instead of full_name"). This commit however doesn't seem sensible to backport as it depends on ce4fecf1 ("vsprintf: Add %p extension "%pOF" for device tree") which doesn't trivially apply to v4.4. [ 1.649453] Unable to handle kernel NULL pointer dereference at virtual address 0000000c [ 1.659270] pgd = c0004000 [ 1.662036] [0000000c] *pgd=00000000 [ 1.665919] Internal error: Oops - BUG: 5 [#1] PREEMPT ARM [ 1.671438] Modules linked in: [ 1.674552] CPU: 0 PID: 1 Comm: swapper Not tainted 4.0.0 #1 [ 1.680235] Hardware name: Eckelmann ECU01 [ 1.684361] task: c7840000 ti: c7842000 task.ti: c7842000 [ 1.689821] PC is at of_get_named_gpiod_flags+0xac/0xe0 [ 1.695104] LR is at of_find_property+0x38/0x7c [ 1.699674] pc : [<c025db2c>] lr : [<c03c5f54>] psr: a0000013 [ 1.699674] sp : c7843cc8 ip : c7843c38 fp : c7843d3c [ 1.711183] r10: c7884dc0 r9 : c7a8de10 r8 : 00000000 [ 1.716434] r7 : 00000000 r6 : 00000000 r5 : c065ef50 r4 : fffffffe [ 1.722986] r3 : 00000000 r2 : 00000000 r1 : c065ef50 r0 : fffffffe [ 1.729541] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 1.736879] Control: 0005317f Table: 80004000 DAC: 00000017 [ 1.742652] Process swapper (pid: 1, stack limit = 0xc7842190) [ 1.748510] Stack: (0xc7843cc8 to 0xc7844000) [ 1.752906] 3cc0: c7843cd4 c003ccec 00000000 00000000 00000000 00000000 [ 1.761125] 3ce0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.769345] 3d00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 fffffdfb [ 1.777566] 3d20: 00000000 c78b4e10 c7a8dc00 000001ff c7843d4c c7843d40 c025db70 c025da90 [ 1.785788] 3d40: c7843dcc c7843d50 c02f8938 c025db70 c7843d74 c7843d60 c79bc3c0 c79bc320 [ 1.794007] 3d60: c78bb140 c065476c c7a8de10 00000000 c78b4e10 c78b4e00 00000004 00000001 [ 1.802227] 3d80: c06d25d4 00000000 c7843dbc c7843d98 c0115a68 c0112538 00000001 c78b4e10 [ 1.810448] 3da0: c78b4e18 ffffffed c78b4e10 fffffdfb c070bc80 00000000 c06d25d4 00000000 [ 1.818669] 3dc0: c7843dec c7843dd0 c02a0670 c02f8828 c78b4e10 c073fcb0 00000000 c070bc80 [ 1.826890] 3de0: c7843e14 c7843df0 c029f064 c02a0630 00000000 c78b4e10 c070bc80 c78b4e44 [ 1.835110] 3e00: 00000000 c06c8cac c7843e34 c7843e18 c029f204 c029ef70 c029f170 00000000 [ 1.843332] 3e20: c070bc80 c029f170 c7843e5c c7843e38 c029d6f4 c029f180 c785c1cc c7873c30 [ 1.851553] 3e40: c0235728 c070bc80 c7ab9720 c0701e20 c7843e6c c7843e60 c029eb74 c029d6a4 [ 1.859774] 3e60: c7843e94 c7843e70 c029e7f4 c029eb64 c065f390 c7843e80 c070bc80 c06f0718 [ 1.867998] 3e80: c7ab8d60 c06b1528 c7843eac c7843e98 c029f810 c029e728 c06f0718 c06f0718 [ 1.876220] 3ea0: c7843ebc c7843eb0 c02a04dc c029f7ac c7843ecc c7843ec0 c06c8cc4 c02a049c [ 1.884443] 3ec0: c7843f4c c7843ed0 c00089dc c06c8cbc c0109ec0 c0109d18 c780ac00 00000001 [ 1.892665] 3ee0: c7843f00 c7843ef0 c06b1544 c0238a24 c7ffca48 c054c854 c7843f4c c7843f08 [ 1.900886] 3f00: c002e7f4 c06b1538 c003d0e0 00000006 00000006 c06af1a4 00000000 c066ccb4 [ 1.909107] 3f20: c7843f4c c06ea994 00000006 c071ff20 c06b1528 c06d25e0 c06d25d4 0000008f [ 1.917327] 3f40: c7843f94 c7843f50 c06b1e6c c0008964 00000006 00000006 c06b1528 dfe48a08 [ 1.925547] 3f60: 33f73660 3fd760c5 0b5d4bfd 00000000 c0527ef0 00000000 00000000 00000000 [ 1.933768] 3f80: 00000000 00000000 c7843fac c7843f98 c0527f00 c06b1d00 c7842000 00000000 [ 1.941988] 3fa0: 00000000 c7843fb0 c0009798 c0527f00 00000000 00000000 00000000 00000000 [ 1.950206] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.958424] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 b3cf731f fe6afeef [ 1.966617] Backtrace: [ 1.969150] [<c025da80>] (of_get_named_gpiod_flags) from [<c025db70>] (of_get_named_gpio_flags+0x10/0x24) [ 1.978744] r7:000001ff r6:c7a8dc00 r5:c78b4e10 r4:00000000 [ 1.984548] [<c025db60>] (of_get_named_gpio_flags) from [<c02f8938>] (spi_imx_probe+0x120/0x67c) [ 1.993390] [<c02f8818>] (spi_imx_probe) from [<c02a0670>] (platform_drv_probe+0x50/0xac) [ 2.001589] r10:00000000 r9:c06d25d4 r8:00000000 r7:c070bc80 r6:fffffdfb r5:c78b4e10 [ 2.009549] r4:ffffffed [ 2.012144] [<c02a0620>] (platform_drv_probe) from [<c029f064>] (driver_probe_device+0x104/0x210) [ 2.021040] r7:c070bc80 r6:00000000 r5:c073fcb0 r4:c78b4e10 [ 2.026822] [<c029ef60>] (driver_probe_device) from [<c029f204>] (__driver_attach+0x94/0x98) [ 2.035282] r8:c06c8cac r7:00000000 r6:c78b4e44 r5:c070bc80 r4:c78b4e10 r3:00000000 [ 2.043191] [<c029f170>] (__driver_attach) from [<c029d6f4>] (bus_for_each_dev+0x60/0x90) [ 2.051394] r6:c029f170 r5:c070bc80 r4:00000000 r3:c029f170 [ 2.057185] [<c029d694>] (bus_for_each_dev) from [<c029eb74>] (driver_attach+0x20/0x28) [ 2.065212] r6:c0701e20 r5:c7ab9720 r4:c070bc80 [ 2.069931] [<c029eb54>] (driver_attach) from [<c029e7f4>] (bus_add_driver+0xdc/0x1dc) [ 2.077894] [<c029e718>] (bus_add_driver) from [<c029f810>] (driver_register+0x74/0xec) [ 2.085919] r7:c06b1528 r6:c7ab8d60 r5:c06f0718 r4:c070bc80 [ 2.091705] [<c029f79c>] (driver_register) from [<c02a04dc>] (__platform_driver_register+0x50/0x64) [ 2.100774] r5:c06f0718 r4:c06f0718 [ 2.104437] [<c02a048c>] (__platform_driver_register) from [<c06c8cc4>] (spi_imx_driver_init+0x18/0x20) [ 2.113884] [<c06c8cac>] (spi_imx_driver_init) from [<c00089dc>] (do_one_initcall+0x88/0x1b0) [ 2.122459] [<c0008954>] (do_one_initcall) from [<c06b1e6c>] (kernel_init_freeable+0x17c/0x248) [ 2.131182] r10:0000008f r9:c06d25d4 r8:c06d25e0 r7:c06b1528 r6:c071ff20 r5:00000006 [ 2.139141] r4:c06ea994 [ 2.141751] [<c06b1cf0>] (kernel_init_freeable) from [<c0527f00>] (kernel_init+0x10/0xec) [ 2.149955] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0527ef0 [ 2.157909] r4:00000000 [ 2.160508] [<c0527ef0>] (kernel_init) from [<c0009798>] (ret_from_fork+0x14/0x3c) [ 2.168099] r4:00000000 r3:c7842000 [ 2.171755] Code: eb0b2dc2 e51b0020 e24bd01c e89da8f0 (e597300c) Cc: stable@vger.kernel.org # v4.4.x, v4.9.x Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Dexuan Cui authored
BugLink: https://bugs.launchpad.net/bugs/1892822 The v4.4 stable kernel lacks this bugfix: commit 32786821 ("make skb_copy_datagram_msg() et.al. preserve ->msg_iter on error"). As a result, the v4.4 kernel can deliver corrupt data to the application when a corrupt UDP packet is closely followed by a valid UDP packet: the same invocation of the recvmsg() syscall can deliver the corrupt packet's UDP payload to the application with the UDP payload length and the "from IP/Port" of the valid packet. Details: For a UDP packet longer than 76 bytes (see the v5.8-rc6 kernel's include/linux/skbuff.h:3951), Linux delays the UDP checksum verification until the application invokes the syscall recvmsg(). In the recvmsg() syscall handler, while Linux is copying the UDP payload to the application's memory, it calculates the UDP checksum. If the calculated checksum doesn't match the received checksum, Linux drops the corrupt UDP packet, and then starts to process the next packet (if any), and if the next packet is valid (i.e. the checksum is correct), Linux will copy the valid UDP packet's payload to the application's receiver buffer. The bug is: before Linux starts to copy the valid UDP packet, the data structure used to track how many more bytes should be copied to the application memory is not reset to what it was when the application just entered the kernel by the syscall! Consequently, only a small portion or none of the valid packet's payload is copied to the application's receive buffer, and later when the application exits from the kernel, actually most of the application's receive buffer contains the payload of the corrupt packet while recvmsg() returns the length of the UDP payload of the valid packet. For the mainline kernel, the bug was fixed in commit 32786821, but unluckily the bugfix is only backported to v4.9+. It turns out backporting 32786821 to v4.4 means that some supporting patches must be backported first, so the overall changes seem too big, so the alternative is performs the csum validation earlier and drops the corrupt packets earlier. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Dexuan Cui <decui@microsoft.com> Acked-by:
-
Nick Desaulniers authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit f3751ad0 upstream. __tracepoint_string's have their string data stored in .rodata, and an address to that data stored in the "__tracepoint_str" section. Functions that refer to those strings refer to the symbol of the address. Compiler optimization can replace those address references with references directly to the string data. If the address doesn't appear to have other uses, then it appears dead to the compiler and is removed. This can break the /tracing/printk_formats sysfs node which iterates the addresses stored in the "__tracepoint_str" section. Like other strings stored in custom sections in this header, mark these __used to inform the compiler that there are other non-obvious users of the address, so they should still be emitted. Link: https://lkml.kernel.org/r/20200730224555.2142154-2-ndesaulniers@google.com Cc: Ingo Molnar <mingo@redhat.com> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Cc: stable@vger.kernel.org Fixes: 102c9323 ("tracing: Add __tracepoint_string() to export string pointers") Reported-by:
Tim Murray <timmurray@google.com> Reported-by:
Simon MacMullen <simonmacm@google.com> Suggested-by:
Greg Hackmann <ghackmann@google.com> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Eric Biggers authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit beb4ee67 upstream. smk_write_relabel_self() frees memory from the task's credentials with no locking, which can easily cause a use-after-free because multiple tasks can share the same credentials structure. Fix this by using prepare_creds() and commit_creds() to correctly modify the task's credentials. Reproducer for "BUG: KASAN: use-after-free in smk_write_relabel_self": #include <fcntl.h> #include <pthread.h> #include <unistd.h> static void *thrproc(void *arg) { int fd = open("/sys/fs/smackfs/relabel-self", O_WRONLY); for (;;) write(fd, "foo", 3); } int main() { pthread_t t; pthread_create(&t, NULL, thrproc, NULL); thrproc(NULL); } Reported-by: syzbot+e6416dabb497a650da40@syzkaller.appspotmail.com Fixes: 38416e53 ("Smack: limited capability for changing process label") Cc: <stable@vger.kernel.org> # v4.4+ Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
-
Ido Schimmel authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit b5141915 ] The commit cited below removed the RCU read-side critical section from rtnl_fdb_dump() which means that the ndo_fdb_dump() callback is invoked without RCU protection. This results in the following warning [1] in the VXLAN driver, which relied on the callback being invoked from an RCU read-side critical section. Fix this by calling rcu_read_lock() in the VXLAN driver, as already done in the bridge driver. [1] WARNING: suspicious RCU usage 5.8.0-rc4-custom-01521-g481007553ce6 #29 Not tainted ----------------------------- drivers/net/vxlan.c:1379 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by bridge/166: #0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xea/0x1090 stack backtrace: CPU: 1 PID: 166 Comm: bridge Not tainted 5.8.0-rc4-custom-01521-g481007553ce6 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack+0x100/0x184 lockdep_rcu_suspicious+0x153/0x15d vxlan_fdb_dump+0x51e/0x6d0 rtnl_fdb_dump+0x4dc/0xad0 netlink_dump+0x540/0x1090 __netlink_dump_start+0x695/0x950 rtnetlink_rcv_msg+0x802/0xbd0 netlink_rcv_skb+0x17a/0x480 rtnetlink_rcv+0x22/0x30 netlink_unicast+0x5ae/0x890 netlink_sendmsg+0x98a/0xf40 __sys_sendto+0x279/0x3b0 __x64_sys_sendto+0xe6/0x1a0 do_syscall_64+0x54/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fe14fa2ade0 Code: Bad RIP value. RSP: 002b:00007fff75bb5b88 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00005614b1ba0020 RCX: 00007fe14fa2ade0 RDX: 000000000000011c RSI: 00007fff75bb5b90 RDI: 0000000000000003 RBP: 00007fff75bb5b90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00005614b1b89160 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Fixes: 5e6d2435 ("bridge: netlink dump interface at par with brctl") Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Rustam Kovhaev authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit e911e99a ] in case of an error tty_register_device_attr() returns ERR_PTR(), add IS_ERR() check Reported-and-tested-by: syzbot+67b2bd0e34f952d0321e@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=67b2bd0e34f952d0321eSigned-off-by:
Rustam Kovhaev <rkovhaev@gmail.com> Reviewed-by:
-
