Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb()<br /> <br /> syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0]<br /> <br /> l2cap_sock_resume_cb() has a similar problem that was fixed by commit<br /> 1bff51ea59a9 ("Bluetooth: fix use-after-free error in lock_sock_nested()").<br /> <br /> Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executed<br /> under l2cap_sock_resume_cb(), we can avoid the issue simply by checking<br /> if chan-&gt;data is NULL.<br /> <br /> Let&amp;#39;s not access to the killed socket in l2cap_sock_resume_cb().<br /> <br /> [0]:<br /> BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline]<br /> BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]<br /> BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711<br /> Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52<br /> <br /> CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> Workqueue: hci0 hci_rx_work<br /> Call trace:<br /> show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C)<br /> __dump_stack+0x30/0x40 lib/dump_stack.c:94<br /> dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120<br /> print_report+0x58/0x84 mm/kasan/report.c:524<br /> kasan_report+0xb0/0x110 mm/kasan/report.c:634<br /> check_region_inline mm/kasan/generic.c:-1 [inline]<br /> kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189<br /> __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37<br /> instrument_atomic_write include/linux/instrumented.h:82 [inline]<br /> clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]<br /> l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711<br /> l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357<br /> hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline]<br /> hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514<br /> hci_event_func net/bluetooth/hci_event.c:7511 [inline]<br /> hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565<br /> hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070<br /> process_one_work+0x7e8/0x155c kernel/workqueue.c:3238<br /> process_scheduled_works kernel/workqueue.c:3321 [inline]<br /> worker_thread+0x958/0xed8 kernel/workqueue.c:3402<br /> kthread+0x5fc/0x75c kernel/kthread.c:464<br /> ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack: fix crash due to removal of uninitialised entry<br /> <br /> A crash in conntrack was reported while trying to unlink the conntrack<br /> entry from the hash bucket list:<br /> [exception RIP: __nf_ct_delete_from_lists+172]<br /> [..]<br /> #7 [ff539b5a2b043aa0] nf_ct_delete at ffffffffc124d421 [nf_conntrack]<br /> #8 [ff539b5a2b043ad0] nf_ct_gc_expired at ffffffffc124d999 [nf_conntrack]<br /> #9 [ff539b5a2b043ae0] __nf_conntrack_find_get at ffffffffc124efbc [nf_conntrack]<br /> [..]<br /> <br /> The nf_conn struct is marked as allocated from slab but appears to be in<br /> a partially initialised state:<br /> <br /> ct hlist pointer is garbage; looks like the ct hash value<br /> (hence crash).<br /> ct-&gt;status is equal to IPS_CONFIRMED|IPS_DYING, which is expected<br /> ct-&gt;timeout is 30000 (=30s), which is unexpected.<br /> <br /> Everything else looks like normal udp conntrack entry. If we ignore<br /> ct-&gt;status and pretend its 0, the entry matches those that are newly<br /> allocated but not yet inserted into the hash:<br /> - ct hlist pointers are overloaded and store/cache the raw tuple hash<br /> - ct-&gt;timeout matches the relative time expected for a new udp flow<br /> rather than the absolute &amp;#39;jiffies&amp;#39; value.<br /> <br /> If it were not for the presence of IPS_CONFIRMED,<br /> __nf_conntrack_find_get() would have skipped the entry.<br /> <br /> Theory is that we did hit following race:<br /> <br /> cpu x cpu y cpu z<br /> found entry E found entry E<br /> E is expired <br /> nf_ct_delete()<br /> return E to rcu slab<br /> init_conntrack<br /> E is re-inited,<br /> ct-&gt;status set to 0<br /> reply tuplehash hnnode.pprev<br /> stores hash value.<br /> <br /> cpu y found E right before it was deleted on cpu x.<br /> E is now re-inited on cpu z. cpu y was preempted before<br /> checking for expiry and/or confirm bit.<br /> <br /> -&gt;refcnt set to 1<br /> E now owned by skb<br /> -&gt;timeout set to 30000<br /> <br /> If cpu y were to resume now, it would observe E as<br /> expired but would skip E due to missing CONFIRMED bit.<br /> <br /> nf_conntrack_confirm gets called<br /> sets: ct-&gt;status |= CONFIRMED<br /> This is wrong: E is not yet added<br /> to hashtable.<br /> <br /> cpu y resumes, it observes E as expired but CONFIRMED:<br /> <br /> nf_ct_expired()<br /> -&gt; yes (ct-&gt;timeout is 30s)<br /> confirmed bit set.<br /> <br /> cpu y will try to delete E from the hashtable:<br /> nf_ct_delete() -&gt; set DYING bit<br /> __nf_ct_delete_from_lists<br /> <br /> Even this scenario doesn&amp;#39;t guarantee a crash:<br /> cpu z still holds the table bucket lock(s) so y blocks:<br /> <br /> wait for spinlock held by z<br /> <br /> CONFIRMED is set but there is no<br /> guarantee ct will be added to hash:<br /> "chaintoolong" or "clash resolution"<br /> logic both skip the insert step.<br /> reply hnnode.pprev still stores the<br /> hash value.<br /> <br /> unlocks spinlock<br /> return NF_DROP<br /> <br /> <br /> In case CPU z does insert the entry into the hashtable, cpu y will unlink<br /> E again right away but no crash occurs.<br /> <br /> Without &amp;#39;cpu y&amp;#39; race, &amp;#39;garbage&amp;#39; hlist is of no consequence:<br /> ct refcnt remains at 1, eventually skb will be free&amp;#39;d and E gets<br /> destroyed via: nf_conntrack_put -&gt; nf_conntrack_destroy -&gt; nf_ct_destroy.<br /> <br /> To resolve this, move the IPS_CONFIRMED assignment after the table<br /> insertion but before the unlock.<br /> <br /> Pablo points out that the confirm-bit-store could be reordered to happen<br /> before hlist add resp. the timeout fixup, so switch to set_bit and<br /> before_atomic memory barrier to prevent this.<br /> <br /> It doesn&amp;#39;t matter if other CPUs can observe a newly inserted entry right<br /> before the CONFIRMED bit was set:<br /> <br /> Such event cannot be distinguished from above "E is the old incarnation"<br /> case: the entry will be skipped.<br /> <br /> Also change nf_ct_should_gc() to first check the confirmed bit.<br /> <br /> The gc sequence is:<br /> 1. Check if entry has expired, if not skip to next entry<br /> 2. Obtain a reference to the expired entry.<br /> 3. Call nf_ct_should_gc() to double-check step 1.<br /> <br /> nf_ct_should_gc() is thus called only for entries that already failed an<br /> expiry check. After this patch, once the confirmed bit check pas<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: Fix initialization of data for instructions that write to subdevice<br /> <br /> Some Comedi subdevice instruction handlers are known to access<br /> instruction data elements beyond the first `insn-&gt;n` elements in some<br /> cases. The `do_insn_ioctl()` and `do_insnlist_ioctl()` functions<br /> allocate at least `MIN_SAMPLES` (16) data elements to deal with this,<br /> but they do not initialize all of that. For Comedi instruction codes<br /> that write to the subdevice, the first `insn-&gt;n` data elements are<br /> copied from user-space, but the remaining elements are left<br /> uninitialized. That could be a problem if the subdevice instruction<br /> handler reads the uninitialized data. Ensure that the first<br /> `MIN_SAMPLES` elements are initialized before calling these instruction<br /> handlers, filling the uncopied elements with 0. For<br /> `do_insnlist_ioctl()`, the same data buffer elements are used for<br /> handling a list of instructions, so ensure the first `MIN_SAMPLES`<br /> elements are initialized for each instruction that writes to the<br /> subdevice.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_qfq: Fix race condition on qfq_aggregate<br /> <br /> A race condition can occur when &amp;#39;agg&amp;#39; is modified in qfq_change_agg<br /> (called during qfq_enqueue) while other threads access it<br /> concurrently. For example, qfq_dump_class may trigger a NULL<br /> dereference, and qfq_delete_class may cause a use-after-free.<br /> <br /> This patch addresses the issue by:<br /> <br /> 1. Moved qfq_destroy_class into the critical section.<br /> <br /> 2. Added sch_tree_lock protection to qfq_dump_class and<br /> qfq_dump_class_stats.