Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: sungem: remove .ndo_poll_controller to avoid deadlocks<br /> <br /> Erhard reports netpoll warnings from sungem:<br /> <br /> netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)<br /> WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c<br /> <br /> gem_poll_controller() disables interrupts, which may sleep.<br /> We can&amp;#39;t sleep in netpoll, it has interrupts disabled completely.<br /> Strangely, gem_poll_controller() doesn&amp;#39;t even poll the completions,<br /> and instead acts as if an interrupt has fired so it just schedules<br /> NAPI and exits. None of this has been necessary for years, since<br /> netpoll invokes NAPI directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: fix resync softlockup when bitmap size is less than array size<br /> <br /> Is is reported that for dm-raid10, lvextend + lvchange --syncaction will<br /> trigger following softlockup:<br /> <br /> kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]<br /> CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1<br /> RIP: 0010:_raw_spin_unlock_irq+0x13/0x30<br /> Call Trace:<br /> <br /> md_bitmap_start_sync+0x6b/0xf0<br /> raid10_sync_request+0x25c/0x1b40 [raid10]<br /> md_do_sync+0x64b/0x1020<br /> md_thread+0xa7/0x170<br /> kthread+0xcf/0x100<br /> ret_from_fork+0x30/0x50<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> And the detailed process is as follows:<br /> <br /> md_do_sync<br /> j = mddev-&gt;resync_min<br /> while (j

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: Fix deadlocks with kctl removals at disconnection<br /> <br /> In snd_card_disconnect(), we set card-&gt;shutdown flag at the beginning,<br /> call callbacks and do sync for card-&gt;power_ref_sleep waiters at the<br /> end. The callback may delete a kctl element, and this can lead to a<br /> deadlock when the device was in the suspended state. Namely:<br /> <br /> * A process waits for the power up at snd_power_ref_and_wait() in<br /> snd_ctl_info() or read/write() inside card-&gt;controls_rwsem.<br /> <br /> * The system gets disconnected meanwhile, and the driver tries to<br /> delete a kctl via snd_ctl_remove*(); it tries to take<br /> card-&gt;controls_rwsem again, but this is already locked by the<br /> above. Since the sleeper isn&amp;#39;t woken up, this deadlocks.<br /> <br /> An easy fix is to wake up sleepers before processing the driver<br /> disconnect callbacks but right after setting the card-&gt;shutdown flag.<br /> Then all sleepers will abort immediately, and the code flows again.<br /> <br /> So, basically this patch moves the wait_event() call at the right<br /> timing. While we&amp;#39;re at it, just to be sure, call wait_event_all()<br /> instead of wait_event(), although we don&amp;#39;t use exclusive events on<br /> this queue for now.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Modify the print level of CQE error<br /> <br /> Too much print may lead to a panic in kernel. Change ibdev_err() to<br /> ibdev_err_ratelimited(), and change the printing level of cqe dump<br /> to debug level.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: Init `ddp_comp` with devm_kcalloc()<br /> <br /> In the case where `conn_routes` is true we allocate an extra slot in<br /> the `ddp_comp` array but mtk_drm_crtc_create() never seemed to<br /> initialize it in the test case I ran. For me, this caused a later<br /> crash when we looped through the array in mtk_drm_crtc_mode_valid().<br /> This showed up for me when I booted with `slub_debug=FZPUA` which<br /> poisons the memory initially. Without `slub_debug` I couldn&amp;#39;t<br /> reproduce, presumably because the later code handles the value being<br /> NULL and in most cases (not guaranteed in all cases) the memory the<br /> allocator returned started out as 0.<br /> <br /> It really doesn&amp;#39;t hurt to initialize the array with devm_kcalloc()<br /> since the array is small and the overhead of initting a handful of<br /> elements to 0 is small. In general initting memory to zero is a safer<br /> practice and usually it&amp;#39;s suggested to only use the non-initting alloc<br /> functions if you really need to.<br /> <br /> Let&amp;#39;s switch the function to use an allocation function that zeros the<br /> memory. For me, this avoids the crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jffs2: prevent xattr node from overflowing the eraseblock<br /> <br /> Add a check to make sure that the requested xattr node size is no larger<br /> than the eraseblock minus the cleanmarker.<br /> <br /> Unlike the usual inode nodes, the xattr nodes aren&amp;#39;t split into parts<br /> and spread across multiple eraseblocks, which means that a xattr node<br /> must not occupy more than one eraseblock. If the requested xattr value is<br /> too large, the xattr node can spill onto the next eraseblock, overwriting<br /> the nodes and causing errors such as:<br /> <br /> jffs2: argh. node added in wrong place at 0x0000b050(2)<br /> jffs2: nextblock 0x0000a000, expected at 0000b00c<br /> jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,<br /> read=0xfc892c93, calc=0x000000<br /> jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed<br /> at 0x01e00c. {848f,2fc4,0fef511f,59a3d171}<br /> jffs2: Node at 0x0000000c with length 0x00001044 would run over the<br /> end of the erase block<br /> jffs2: Perhaps the file system was created with the wrong erase size?<br /> jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found<br /> at 0x00000010: 0x1044 instead<br /> <br /> This breaks the filesystem and can lead to KASAN crashes such as:<br /> <br /> BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0<br /> Read of size 4 at addr ffff88802c31e914 by task repro/830<br /> CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> BIOS Arch Linux 1.16.3-1-1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xc6/0x120<br /> print_report+0xc4/0x620<br /> ? __virt_addr_valid+0x308/0x5b0<br /> kasan_report+0xc1/0xf0<br /> ? jffs2_sum_add_kvec+0x125e/0x15d0<br /> ? jffs2_sum_add_kvec+0x125e/0x15d0<br /> jffs2_sum_add_kvec+0x125e/0x15d0<br /> jffs2_flash_direct_writev+0xa8/0xd0<br /> jffs2_flash_writev+0x9c9/0xef0<br /> ? __x64_sys_setxattr+0xc4/0x160<br /> ? do_syscall_64+0x69/0x140<br /> ? entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [...]<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix potential hang in nilfs_detach_log_writer()<br /> <br /> Syzbot has reported a potential hang in nilfs_detach_log_writer() called<br /> during nilfs2 unmount.<br /> <br /> Analysis revealed that this is because nilfs_segctor_sync(), which<br /> synchronizes with the log writer thread, can be called after<br /> nilfs_segctor_destroy() terminates that thread, as shown in the call trace<br /> below:<br /> <br /> nilfs_detach_log_writer<br /> nilfs_segctor_destroy<br /> nilfs_segctor_kill_thread --&gt; Shut down log writer thread<br /> flush_work<br /> nilfs_iput_work_func<br /> nilfs_dispose_list<br /> iput<br /> nilfs_evict_inode<br /> nilfs_transaction_commit<br /> nilfs_construct_segment (if inode needs sync)<br /> nilfs_segctor_sync --&gt; Attempt to synchronize with<br /> log writer thread<br /> *** DEADLOCK ***<br /> <br /> Fix this issue by changing nilfs_segctor_sync() so that the log writer<br /> thread returns normally without synchronizing after it terminates, and by<br /> forcing tasks that are already waiting to complete once after the thread<br /> terminates.<br /> <br /> The skipped inode metadata flushout will then be processed together in the<br /> subsequent cleanup work in nilfs_segctor_destroy().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ti: icssg_prueth: Fix NULL pointer dereference in prueth_probe()<br /> <br /> In the prueth_probe() function, if one of the calls to emac_phy_connect()<br /> fails due to of_phy_connect() returning NULL, then the subsequent call to<br /> phy_attached_info() will dereference a NULL pointer.<br /> <br /> Check the return code of emac_phy_connect and fail cleanly if there is an<br /> error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tools/nolibc/stdlib: fix memory error in realloc()<br /> <br /> Pass user_p_len to memcpy() instead of heap-&gt;len to prevent realloc()<br /> from copying an extra sizeof(heap) bytes from beyond the allocated<br /> region.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> r8169: Fix possible ring buffer corruption on fragmented Tx packets.<br /> <br /> An issue was found on the RTL8125b when transmitting small fragmented<br /> packets, whereby invalid entries were inserted into the transmit ring<br /> buffer, subsequently leading to calls to dma_unmap_single() with a null<br /> address.<br /> <br /> This was caused by rtl8169_start_xmit() not noticing changes to nr_frags<br /> which may occur when small packets are padded (to work around hardware<br /> quirks) in rtl8169_tso_csum_v2().<br /> <br /> To fix this, postpone inspecting nr_frags until after any padding has been<br /> applied.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Fix possible use-after-free issue in ftrace_location()<br /> <br /> KASAN reports a bug:<br /> <br /> BUG: KASAN: use-after-free in ftrace_location+0x90/0x120<br /> Read of size 8 at addr ffff888141d40010 by task insmod/424<br /> CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+<br /> [...]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x68/0xa0<br /> print_report+0xcf/0x610<br /> kasan_report+0xb5/0xe0<br /> ftrace_location+0x90/0x120<br /> register_kprobe+0x14b/0xa40<br /> kprobe_init+0x2d/0xff0 [kprobe_example]<br /> do_one_initcall+0x8f/0x2d0<br /> do_init_module+0x13a/0x3c0<br /> load_module+0x3082/0x33d0<br /> init_module_from_file+0xd2/0x130<br /> __x64_sys_finit_module+0x306/0x440<br /> do_syscall_64+0x68/0x140<br /> entry_SYSCALL_64_after_hwframe+0x71/0x79<br /> <br /> The root cause is that, in lookup_rec(), ftrace record of some address<br /> is being searched in ftrace pages of some module, but those ftrace pages<br /> at the same time is being freed in ftrace_release_mod() as the<br /> corresponding module is being deleted:<br /> <br /> CPU1 | CPU2<br /> register_kprobes() { | delete_module() {<br /> check_kprobe_address_safe() { |<br /> arch_check_ftrace_location() { |<br /> ftrace_location() { |<br /> lookup_rec() // USE! | ftrace_release_mod() // Free!<br /> <br /> To fix this issue:<br /> 1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();<br /> 2. Use ftrace_location_range() instead of lookup_rec() in<br /> ftrace_location();<br /> 3. Call synchronize_rcu() before freeing any ftrace pages both in<br /> ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> epoll: be better about file lifetimes<br /> <br /> epoll can call out to vfs_poll() with a file pointer that may race with<br /> the last &amp;#39;fput()&amp;#39;. That would make f_count go down to zero, and while<br /> the ep-&gt;mtx locking means that the resulting file pointer tear-down will<br /> be blocked until the poll returns, it means that f_count is already<br /> dead, and any use of it won&amp;#39;t actually get a reference to the file any<br /> more: it&amp;#39;s dead regardless.<br /> <br /> Make sure we have a valid ref on the file pointer before we call down to<br /> vfs_poll() from the epoll routines.