Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-bufio: fix sched in atomic context<br /> <br /> If "try_verify_in_tasklet" is set for dm-verity, DM_BUFIO_CLIENT_NO_SLEEP<br /> is enabled for dm-bufio. However, when bufio tries to evict buffers, there<br /> is a chance to trigger scheduling in spin_lock_bh, the following warning<br /> is hit:<br /> <br /> BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2<br /> preempt_count: 201, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> 4 locks held by kworker/2:2/123:<br /> #0: ffff88800a2d1548 ((wq_completion)dm_bufio_cache){....}-{0:0}, at: process_one_work+0xe46/0x1970<br /> #1: ffffc90000d97d20 ((work_completion)(&amp;dm_bufio_replacement_work)){....}-{0:0}, at: process_one_work+0x763/0x1970<br /> #2: ffffffff8555b528 (dm_bufio_clients_lock){....}-{3:3}, at: do_global_cleanup+0x1ce/0x710<br /> #3: ffff88801d5820b8 (&amp;c-&gt;spinlock){....}-{2:2}, at: do_global_cleanup+0x2a5/0x710<br /> Preemption disabled at:<br /> [] 0x0<br /> CPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 #305 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> Workqueue: dm_bufio_cache do_global_cleanup<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x53/0x70<br /> __might_resched+0x360/0x4e0<br /> do_global_cleanup+0x2f5/0x710<br /> process_one_work+0x7db/0x1970<br /> worker_thread+0x518/0xea0<br /> kthread+0x359/0x690<br /> ret_from_fork+0xf3/0x1b0<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> That can be reproduced by:<br /> <br /> veritysetup format --data-block-size=4096 --hash-block-size=4096 /dev/vda /dev/vdb<br /> SIZE=$(blockdev --getsz /dev/vda)<br /> dmsetup create myverity -r --table "0 $SIZE verity 1 /dev/vda /dev/vdb 4096 4096 1 sha256 1 try_verify_in_tasklet"<br /> mount /dev/dm-0 /mnt -o ro<br /> echo 102400 &gt; /sys/module/dm_bufio/parameters/max_cache_size_bytes<br /> [read files in /mnt]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: core: do not bypass hid_hw_raw_request<br /> <br /> hid_hw_raw_request() is actually useful to ensure the provided buffer<br /> and length are valid. Directly calling in the low level transport driver<br /> function bypassed those checks and allowed invalid paramto be used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: das6402: Fix bit shift out of bounds<br /> <br /> When checking for a supported IRQ number, the following test is used:<br /> <br /> /* IRQs 2,3,5,6,7, 10,11,15 are valid for "enhanced" mode */<br /> if ((1 options[i]` is an unchecked `int` value from userspace, so<br /> the shift amount could be negative or out of bounds. Fix the test by<br /> requiring `it-&gt;options[1]` to be within bounds before proceeding with<br /> the original test. Valid `it-&gt;options[1]` values that select the IRQ<br /> will be in the range [1,15]. The value 0 explicitly disables the use of<br /> interrupts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: das16m1: Fix bit shift out of bounds<br /> <br /> When checking for a supported IRQ number, the following test is used:<br /> <br /> /* only irqs 2, 3, 4, 5, 6, 7, 10, 11, 12, 14, and 15 are valid */<br /> if ((1 options[i]` is an unchecked `int` value from userspace, so<br /> the shift amount could be negative or out of bounds. Fix the test by<br /> requiring `it-&gt;options[1]` to be within bounds before proceeding with<br /> the original test.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: accel: fxls8962af: Fix use after free in fxls8962af_fifo_flush<br /> <br /> fxls8962af_fifo_flush() uses indio_dev-&gt;active_scan_mask (with<br /> iio_for_each_active_channel()) without making sure the indio_dev<br /> stays in buffer mode.<br /> There is a race if indio_dev exits buffer mode in the middle of the<br /> interrupt that flushes the fifo. Fix this by calling<br /> synchronize_irq() to ensure that no interrupt is currently running when<br /> disabling buffer mode.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read<br /> [...]<br /> _find_first_bit_le from fxls8962af_fifo_flush+0x17c/0x290<br /> fxls8962af_fifo_flush from fxls8962af_interrupt+0x80/0x178<br /> fxls8962af_interrupt from irq_thread_fn+0x1c/0x7c<br /> irq_thread_fn from irq_thread+0x110/0x1f4<br /> irq_thread from kthread+0xe0/0xfc<br /> kthread from ret_from_fork+0x14/0x2c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: aspeed: lpc-snoop: Don&amp;#39;t disable channels that aren&amp;#39;t enabled<br /> <br /> Mitigate e.g. the following:<br /> <br /> # echo 1e789080.lpc-snoop &gt; /sys/bus/platform/drivers/aspeed-lpc-snoop/unbind<br /> ...<br /> [ 120.363594] Unable to handle kernel NULL pointer dereference at virtual address 00000004 when write<br /> [ 120.373866] [00000004] *pgd=00000000<br /> [ 120.377910] Internal error: Oops: 805 [#1] SMP ARM<br /> [ 120.383306] CPU: 1 UID: 0 PID: 315 Comm: sh Not tainted 6.15.0-rc1-00009-g926217bc7d7d-dirty #20 NONE<br /> ...<br /> [ 120.679543] Call trace:<br /> [ 120.679559] misc_deregister from aspeed_lpc_snoop_remove+0x84/0xac<br /> [ 120.692462] aspeed_lpc_snoop_remove from platform_remove+0x28/0x38<br /> [ 120.700996] platform_remove from device_release_driver_internal+0x188/0x200<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix use-after-free in crypt_message when using async crypto<br /> <br /> The CVE-2024-50047 fix removed asynchronous crypto handling from<br /> crypt_message(), assuming all crypto operations are synchronous.<br /> However, when hardware crypto accelerators are used, this can cause<br /> use-after-free crashes:<br /> <br /> crypt_message()<br /> // Allocate the creq buffer containing the req<br /> creq = smb2_get_aead_req(..., &amp;req);<br /> <br /> // Async encryption returns -EINPROGRESS immediately<br /> rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);<br /> <br /> // Free creq while async operation is still in progress<br /> kvfree_sensitive(creq, ...);<br /> <br /> Hardware crypto modules often implement async AEAD operations for<br /> performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS,<br /> the operation completes asynchronously. Without crypto_wait_req(),<br /> the function immediately frees the request buffer, leading to crashes<br /> when the driver later accesses the freed memory.<br /> <br /> This results in a use-after-free condition when the hardware crypto<br /> driver later accesses the freed request structure, leading to kernel<br /> crashes with NULL pointer dereferences.<br /> <br /> The issue occurs because crypto_alloc_aead() with mask=0 doesn&amp;#39;t<br /> guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in<br /> the mask, async implementations can be selected.<br /> <br /> Fix by restoring the async crypto handling:<br /> - DECLARE_CRYPTO_WAIT(wait) for completion tracking<br /> - aead_request_set_callback() for async completion notification<br /> - crypto_wait_req() to wait for operation completion<br /> <br /> This ensures the request buffer isn&amp;#39;t freed until the crypto operation<br /> completes, whether synchronous or asynchronous, while preserving the<br /> CVE-2024-50047 fix.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: backend: fix out-of-bound write<br /> <br /> The buffer is set to 80 character. If a caller write more characters,<br /> count is truncated to the max available space in "simple_write_to_buffer".<br /> But afterwards a string terminator is written to the buffer at offset count<br /> without boundary check. The zero termination is written OUT-OF-BOUND.<br /> <br /> Add a check that the given buffer is smaller then the buffer to prevent.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soundwire: Revert "soundwire: qcom: Add set_channel_map api support"<br /> <br /> This reverts commit 7796c97df6b1b2206681a07f3c80f6023a6593d5.<br /> <br /> This patch broke Dragonboard 845c (sdm845). I see:<br /> <br /> Unexpected kernel BRK exception at EL1<br /> Internal error: BRK handler: 00000000f20003e8 [#1] SMP<br /> pc : qcom_swrm_set_channel_map+0x7c/0x80 [soundwire_qcom]<br /> lr : snd_soc_dai_set_channel_map+0x34/0x78<br /> Call trace:<br /> qcom_swrm_set_channel_map+0x7c/0x80 [soundwire_qcom] (P)<br /> sdm845_dai_init+0x18c/0x2e0 [snd_soc_sdm845]<br /> snd_soc_link_init+0x28/0x6c<br /> snd_soc_bind_card+0x5f4/0xb0c<br /> snd_soc_register_card+0x148/0x1a4<br /> devm_snd_soc_register_card+0x50/0xb0<br /> sdm845_snd_platform_probe+0x124/0x148 [snd_soc_sdm845]<br /> platform_probe+0x6c/0xd0<br /> really_probe+0xc0/0x2a4<br /> __driver_probe_device+0x7c/0x130<br /> driver_probe_device+0x40/0x118<br /> __device_attach_driver+0xc4/0x108<br /> bus_for_each_drv+0x8c/0xf0<br /> __device_attach+0xa4/0x198<br /> device_initial_probe+0x18/0x28<br /> bus_probe_device+0xb8/0xbc<br /> deferred_probe_work_func+0xac/0xfc<br /> process_one_work+0x244/0x658<br /> worker_thread+0x1b4/0x360<br /> kthread+0x148/0x228<br /> ret_from_fork+0x10/0x20<br /> Kernel panic - not syncing: BRK handler: Fatal exception<br /> <br /> Dan has also reported following issues with the original patch<br /> https://lore.kernel.org/all/33fe8fe7-719a-405a-9ed2-d9f816ce1d57@sabinyo.mountain/<br /> <br /> Bug #1:<br /> The zeroeth element of ctrl-&gt;pconfig[] is supposed to be unused. We<br /> start counting at 1. However this code sets ctrl-&gt;pconfig[0].ch_mask = 128.<br /> <br /> Bug #2:<br /> There are SLIM_MAX_TX_PORTS (16) elements in tx_ch[] array but only<br /> QCOM_SDW_MAX_PORTS + 1 (15) in the ctrl-&gt;pconfig[] array so it corrupts<br /> memory like Yongqin Liu pointed out.<br /> <br /> Bug 3:<br /> Like Jie Gan pointed out, it erases all the tx information with the rx<br /> information.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again<br /> <br /> Commit 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") has<br /> accidentally removed the critical piece of commit c730fce7c70c<br /> ("s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL"), causing<br /> intermittent kernel panics in e.g. perf&amp;#39;s on_switch() prog to reappear.<br /> <br /> Restore the fix and add a comment.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rpl: Fix use-after-free in rpl_do_srh_inline().<br /> <br /> Running lwt_dst_cache_ref_loop.sh in selftest with KASAN triggers<br /> the splat below [0].<br /> <br /> rpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it after<br /> skb_cow_head(), which is illegal as the header could be freed then.<br /> <br /> Let&amp;#39;s fix it by making oldhdr to a local struct instead of a pointer.<br /> <br /> [0]:<br /> [root@fedora net]# ./lwt_dst_cache_ref_loop.sh<br /> ...<br /> TEST: rpl (input)<br /> [ 57.631529] ==================================================================<br /> BUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)<br /> Read of size 40 at addr ffff888122bf96d8 by task ping6/1543<br /> <br /> CPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl (lib/dump_stack.c:122)<br /> print_report (mm/kasan/report.c:409 mm/kasan/report.c:521)<br /> kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)<br /> kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1))<br /> __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2))<br /> rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)<br /> rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282)<br /> lwtunnel_input (net/core/lwtunnel.c:459)<br /> ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1))<br /> __netif_receive_skb_one_core (net/core/dev.c:5967)<br /> process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440)<br /> __napi_poll.constprop.0 (net/core/dev.c:7452)<br /> net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643)<br /> handle_softirqs (kernel/softirq.c:579)<br /> do_softirq (kernel/softirq.c:480 (discriminator 20))<br /> <br /> <br /> __local_bh_enable_ip (kernel/softirq.c:407)<br /> __dev_queue_xmit (net/core/dev.c:4740)<br /> ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141)<br /> ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226)<br /> ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248)<br /> ip6_send_skb (net/ipv6/ip6_output.c:1983)<br /> rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918)<br /> __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1))<br /> __x64_sys_sendto (net/socket.c:2231)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)<br /> RIP: 0033:0x7f68cffb2a06<br /> Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08<br /> RSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06<br /> RDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003<br /> RBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c<br /> R10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4<br /> R13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0<br /> <br /> <br /> Allocated by task 1543:<br /> kasan_save_stack (mm/kasan/common.c:48)<br /> kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))<br /> __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)<br /> kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249)<br /> kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88))<br /> __alloc_skb (net/core/skbuff.c:669)<br /> __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1))<br /> ip6_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: net: sierra: check for no status endpoint<br /> <br /> The driver checks for having three endpoints and<br /> having bulk in and out endpoints, but not that<br /> the third endpoint is interrupt input.<br /> Rectify the omission.