Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: fix deadlock caused by calling printk() under tty_port-&gt;lock<br /> <br /> pty_write() invokes kmalloc() which may invoke a normal printk() to print<br /> failure message. This can cause a deadlock in the scenario reported by<br /> syz-bot below:<br /> <br /> CPU0 CPU1 CPU2<br /> ---- ---- ----<br /> lock(console_owner);<br /> lock(&amp;port_lock_key);<br /> lock(&amp;port-&gt;lock);<br /> lock(&amp;port_lock_key);<br /> lock(&amp;port-&gt;lock);<br /> lock(console_owner);<br /> <br /> As commit dbdda842fe96 ("printk: Add console owner and waiter logic to<br /> load balance console writes") said, such deadlock can be prevented by<br /> using printk_deferred() in kmalloc() (which is invoked in the section<br /> guarded by the port-&gt;lock). But there are too many printk() on the<br /> kmalloc() path, and kmalloc() can be called from anywhere, so changing<br /> printk() to printk_deferred() is too complicated and inelegant.<br /> <br /> Therefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so<br /> that printk() will not be called, and this deadlock problem can be<br /> avoided.<br /> <br /> Syzbot reported the following lockdep error:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> 5.4.143-00237-g08ccc19a-dirty #10 Not tainted<br /> ------------------------------------------------------<br /> syz-executor.4/29420 is trying to acquire lock:<br /> ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]<br /> ffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023<br /> <br /> but task is already holding lock:<br /> ffff8880119c9158 (&amp;port-&gt;lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #2 (&amp;port-&gt;lock){-.-.}-{2:2}:<br /> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]<br /> _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159<br /> tty_port_tty_get drivers/tty/tty_port.c:288 [inline] lock);<br /> tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47<br /> serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767<br /> serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854<br /> serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] #1 (&amp;port_lock_key){-.-.}-{2:2}:<br /> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]<br /> _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159<br /> serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers/base/node.c: fix compaction sysfs file leak<br /> <br /> Compaction sysfs file is created via compaction_register_node in<br /> register_node. But we forgot to remove it in unregister_node. Thus<br /> compaction sysfs file is leaked. Using compaction_unregister_node to fix<br /> this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> list: fix a data-race around ep-&gt;rdllist<br /> <br /> ep_poll() first calls ep_events_available() with no lock held and checks<br /> if ep-&gt;rdllist is empty by list_empty_careful(), which reads<br /> rdllist-&gt;prev. Thus all accesses to it need some protection to avoid<br /> store/load-tearing.<br /> <br /> Note INIT_LIST_HEAD_RCU() already has the annotation for both prev<br /> and next.<br /> <br /> Commit bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socket<br /> fds.") added the first lockless ep_events_available(), and commit<br /> c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epoll_wait()")<br /> made some ep_events_available() calls lockless and added single call under<br /> a lock, finally commit e59d3c64cba6 ("epoll: eliminate unnecessary lock<br /> for zero timeout") made the last ep_events_available() lockless.<br /> <br /> BUG: KCSAN: data-race in do_epoll_wait / do_epoll_wait<br /> <br /> write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0:<br /> INIT_LIST_HEAD include/linux/list.h:38 [inline]<br /> list_splice_init include/linux/list.h:492 [inline]<br /> ep_start_scan fs/eventpoll.c:622 [inline]<br /> ep_send_events fs/eventpoll.c:1656 [inline]<br /> ep_poll fs/eventpoll.c:1806 [inline]<br /> do_epoll_wait+0x4eb/0xf40 fs/eventpoll.c:2234<br /> do_epoll_pwait fs/eventpoll.c:2268 [inline]<br /> __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]<br /> __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275<br /> __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1:<br /> list_empty_careful include/linux/list.h:329 [inline]<br /> ep_events_available fs/eventpoll.c:381 [inline]<br /> ep_poll fs/eventpoll.c:1797 [inline]<br /> do_epoll_wait+0x279/0xf40 fs/eventpoll.c:2234<br /> do_epoll_pwait fs/eventpoll.c:2268 [inline]<br /> __do_sys_epoll_pwait fs/eventpoll.c:2281 [inline]<br /> __se_sys_epoll_pwait+0x12b/0x240 fs/eventpoll.c:2275<br /> __x64_sys_epoll_pwait+0x74/0x80 fs/eventpoll.c:2275<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> value changed: 0xffff88810480c7d0 -&gt; 0xffff888103c15098<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> module: fix [e_shstrndx].sh_size=0 OOB access<br /> <br /> It is trivial to craft a module to trigger OOB access in this line:<br /> <br /> if (info-&gt;secstrings[strhdr-&gt;sh_size - 1] != &amp;#39;\0&amp;#39;) {<br /> <br /> BUG: unable to handle page fault for address: ffffc90000aa0fff<br /> PGD 100000067 P4D 100000067 PUD 100066067 PMD 10436f067 PTE 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 7 PID: 1215 Comm: insmod Not tainted 5.18.0-rc5-00007-g9bf578647087-dirty #10<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014<br /> RIP: 0010:load_module+0x19b/0x2391<br /> <br /> [rebased patch onto modules-next]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: renesas: core: Fix possible null-ptr-deref in sh_pfc_map_resources()<br /> <br /> It will cause null-ptr-deref when using &amp;#39;res&amp;#39;, if platform_get_resource()<br /> returns NULL, so move using &amp;#39;res&amp;#39; after devm_ioremap_resource() that<br /> will check it to avoid null-ptr-deref.<br /> And use devm_platform_get_and_ioremap_resource() to simplify code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/arm-smmu-v3-sva: Fix mm use-after-free<br /> <br /> We currently call arm64_mm_context_put() without holding a reference to<br /> the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to<br /> ensure the mm only gets freed after we unpinned the ASID.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/mediatek: Remove clk_disable in mtk_iommu_remove<br /> <br /> After the commit b34ea31fe013 ("iommu/mediatek: Always enable the clk on<br /> resume"), the iommu clock is controlled by the runtime callback.<br /> thus remove the clk control in the mtk_iommu_remove.<br /> <br /> Otherwise, it will warning like:<br /> <br /> echo 14018000.iommu &gt; /sys/bus/platform/drivers/mtk-iommu/unbind<br /> <br /> [ 51.413044] ------------[ cut here ]------------<br /> [ 51.413648] vpp0_smi_iommu already disabled<br /> [ 51.414233] WARNING: CPU: 2 PID: 157 at */v5.15-rc1/kernel/mediatek/<br /> drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8<br /> [ 51.417174] Hardware name: MT8195V/C(ENG) (DT)<br /> [ 51.418635] pc : clk_core_disable+0xb0/0xb8<br /> [ 51.419177] lr : clk_core_disable+0xb0/0xb8<br /> ...<br /> [ 51.429375] Call trace:<br /> [ 51.429694] clk_core_disable+0xb0/0xb8<br /> [ 51.430193] clk_core_disable_lock+0x24/0x40<br /> [ 51.430745] clk_disable+0x20/0x30<br /> [ 51.431189] mtk_iommu_remove+0x58/0x118<br /> [ 51.431705] platform_remove+0x28/0x60<br /> [ 51.432197] device_release_driver_internal+0x110/0x1f0<br /> [ 51.432873] device_driver_detach+0x18/0x28<br /> [ 51.433418] unbind_store+0xd4/0x108<br /> [ 51.433886] drv_attr_store+0x24/0x38<br /> [ 51.434363] sysfs_kf_write+0x40/0x58<br /> [ 51.434843] kernfs_fop_write_iter+0x164/0x1e0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on inline_dots inode<br /> <br /> As Wenqing reported in bugzilla:<br /> <br /> https://bugzilla.kernel.org/show_bug.cgi?id=215765<br /> <br /> It will cause a kernel panic with steps:<br /> - mkdir mnt<br /> - mount tmp40.img mnt<br /> - ls mnt<br /> <br /> folio_mark_dirty+0x33/0x50<br /> f2fs_add_regular_entry+0x541/0xad0 [f2fs]<br /> f2fs_add_dentry+0x6c/0xb0 [f2fs]<br /> f2fs_do_add_link+0x182/0x230 [f2fs]<br /> __recover_dot_dentries+0x2d6/0x470 [f2fs]<br /> f2fs_lookup+0x5af/0x6a0 [f2fs]<br /> __lookup_slow+0xac/0x200<br /> lookup_slow+0x45/0x70<br /> walk_component+0x16c/0x250<br /> path_lookupat+0x8b/0x1f0<br /> filename_lookup+0xef/0x250<br /> user_path_at_empty+0x46/0x70<br /> vfs_statx+0x98/0x190<br /> __do_sys_newlstat+0x41/0x90<br /> __x64_sys_newlstat+0x1a/0x30<br /> do_syscall_64+0x37/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The root cause is for special file: e.g. character, block, fifo or<br /> socket file, f2fs doesn&amp;#39;t assign address space operations pointer array<br /> for mapping-&gt;a_ops field, so, in a fuzzed image, if inline_dots flag was<br /> tagged in special file, during lookup(), when f2fs runs into<br /> __recover_dot_dentries(), it will cause NULL pointer access once<br /> f2fs_add_regular_entry() calls a_ops-&gt;set_dirty_page().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hfi1: Prevent panic when SDMA is disabled<br /> <br /> If the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to<br /> hfi1_write_iter() will dereference a NULL pointer and panic. A typical<br /> stack frame is:<br /> <br /> sdma_select_user_engine [hfi1]<br /> hfi1_user_sdma_process_request [hfi1]<br /> hfi1_write_iter [hfi1]<br /> do_iter_readv_writev<br /> do_iter_write<br /> vfs_writev<br /> do_writev<br /> do_syscall_64<br /> <br /> The fix is to test for SDMA in hfi1_write_iter() and fail the I/O with<br /> EINVAL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: gpio-keys - cancel delayed work only in case of GPIO<br /> <br /> gpio_keys module can either accept gpios or interrupts. The module<br /> initializes delayed work in case of gpios only and is only used if<br /> debounce timer is not used, so make sure cancel_delayed_work_sync()<br /> is called only when its gpio-backed and debounce_use_hrtimer is false.<br /> <br /> This fixes the issue seen below when the gpio_keys module is unloaded and<br /> an interrupt pin is used instead of GPIO:<br /> <br /> [ 360.297569] ------------[ cut here ]------------<br /> [ 360.302303] WARNING: CPU: 0 PID: 237 at kernel/workqueue.c:3066 __flush_work+0x414/0x470<br /> [ 360.310531] Modules linked in: gpio_keys(-)<br /> [ 360.314797] CPU: 0 PID: 237 Comm: rmmod Not tainted 5.18.0-rc5-arm64-renesas-00116-g73636105874d-dirty #166<br /> [ 360.324662] Hardware name: Renesas SMARC EVK based on r9a07g054l2 (DT)<br /> [ 360.331270] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 360.338318] pc : __flush_work+0x414/0x470<br /> [ 360.342385] lr : __cancel_work_timer+0x140/0x1b0<br /> [ 360.347065] sp : ffff80000a7fba00<br /> [ 360.350423] x29: ffff80000a7fba00 x28: ffff000012b9c5c0 x27: 0000000000000000<br /> [ 360.357664] x26: ffff80000a7fbb80 x25: ffff80000954d0a8 x24: 0000000000000001<br /> [ 360.364904] x23: ffff800009757000 x22: 0000000000000000 x21: ffff80000919b000<br /> [ 360.372143] x20: ffff00000f5974e0 x19: ffff00000f5974e0 x18: ffff8000097fcf48<br /> [ 360.379382] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000053f40<br /> [ 360.386622] x14: ffff800009850e88 x13: 0000000000000002 x12: 000000000000a60c<br /> [ 360.393861] x11: 000000000000a610 x10: 0000000000000000 x9 : 0000000000000008<br /> [ 360.401100] x8 : 0101010101010101 x7 : 00000000a473c394 x6 : 0080808080808080<br /> [ 360.408339] x5 : 0000000000000001 x4 : 0000000000000000 x3 : ffff80000919b458<br /> [ 360.415578] x2 : ffff8000097577f0 x1 : 0000000000000001 x0 : 0000000000000000<br /> [ 360.422818] Call trace:<br /> [ 360.425299] __flush_work+0x414/0x470<br /> [ 360.429012] __cancel_work_timer+0x140/0x1b0<br /> [ 360.433340] cancel_delayed_work_sync+0x10/0x18<br /> [ 360.437931] gpio_keys_quiesce_key+0x28/0x58 [gpio_keys]<br /> [ 360.443327] devm_action_release+0x10/0x18<br /> [ 360.447481] release_nodes+0x8c/0x1a0<br /> [ 360.451194] devres_release_all+0x90/0x100<br /> [ 360.455346] device_unbind_cleanup+0x14/0x60<br /> [ 360.459677] device_release_driver_internal+0xe8/0x168<br /> [ 360.464883] driver_detach+0x4c/0x90<br /> [ 360.468509] bus_remove_driver+0x54/0xb0<br /> [ 360.472485] driver_unregister+0x2c/0x58<br /> [ 360.476462] platform_driver_unregister+0x10/0x18<br /> [ 360.481230] gpio_keys_exit+0x14/0x828 [gpio_keys]<br /> [ 360.486088] __arm64_sys_delete_module+0x1e0/0x270<br /> [ 360.490945] invoke_syscall+0x40/0xf8<br /> [ 360.494661] el0_svc_common.constprop.3+0xf0/0x110<br /> [ 360.499515] do_el0_svc+0x20/0x78<br /> [ 360.502877] el0_svc+0x48/0xf8<br /> [ 360.505977] el0t_64_sync_handler+0x88/0xb0<br /> [ 360.510216] el0t_64_sync+0x148/0x14c<br /> [ 360.513930] irq event stamp: 4306<br /> [ 360.517288] hardirqs last enabled at (4305): [] __cancel_work_timer+0x130/0x1b0<br /> [ 360.526359] hardirqs last disabled at (4306): [] el1_dbg+0x24/0x88<br /> [ 360.534204] softirqs last enabled at (4278): [] _stext+0x4a0/0x5e0<br /> [ 360.542133] softirqs last disabled at (4267): [] irq_exit_rcu+0x18c/0x1b0<br /> [ 360.550591] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/iommu: Add missing of_node_put in iommu_init_early_dart<br /> <br /> The device_node pointer is returned by of_find_compatible_node<br /> with refcount incremented. We should use of_node_put() to avoid<br /> the refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/xics: fix refcount leak in icp_opal_init()<br /> <br /> The of_find_compatible_node() function returns a node pointer with<br /> refcount incremented, use of_node_put() on it when done.