Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Validate PDU length before reading SDU length in l2cap_ecred_data_rcv()<br /> <br /> l2cap_ecred_data_rcv() reads the SDU length field from skb-&gt;data using<br /> get_unaligned_le16() without first verifying that skb contains at least<br /> L2CAP_SDULEN_SIZE (2) bytes. When skb-&gt;len is less than 2, this reads<br /> past the valid data in the skb.<br /> <br /> The ERTM reassembly path correctly calls pskb_may_pull() before reading<br /> the SDU length (l2cap_reassemble_sdu, L2CAP_SAR_START case). Apply the<br /> same validation to the Enhanced Credit Based Flow Control data path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix stack-out-of-bounds read in l2cap_ecred_conn_req<br /> <br /> Syzbot reported a KASAN stack-out-of-bounds read in l2cap_build_cmd()<br /> that is triggered by a malformed Enhanced Credit Based Connection Request.<br /> <br /> The vulnerability stems from l2cap_ecred_conn_req(). The function allocates<br /> a local stack buffer (`pdu`) designed to hold a maximum of 5 Source Channel<br /> IDs (SCIDs), totaling 18 bytes. When an attacker sends a request with more<br /> than 5 SCIDs, the function calculates `rsp_len` based on this unvalidated<br /> `cmd_len` before checking if the number of SCIDs exceeds<br /> L2CAP_ECRED_MAX_CID.<br /> <br /> If the SCID count is too high, the function correctly jumps to the<br /> `response` label to reject the packet, but `rsp_len` retains the<br /> attacker&amp;#39;s oversized value. Consequently, l2cap_send_cmd() is instructed<br /> to read past the end of the 18-byte `pdu` buffer, triggering a<br /> KASAN panic.<br /> <br /> Fix this by moving the assignment of `rsp_len` to after the `num_scid`<br /> boundary check. If the packet is rejected, `rsp_len` will safely<br /> remain 0, and the error response will only read the 8-byte base header<br /> from the stack.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: set fileio bio failed in short read case<br /> <br /> For file-backed mount, IO requests are handled by vfs_iocb_iter_read().<br /> However, it can be interrupted by SIGKILL, returning the number of<br /> bytes actually copied. Unused folios in bio are unexpectedly marked<br /> as uptodate.<br /> <br /> vfs_read<br /> filemap_read<br /> filemap_get_pages<br /> filemap_readahead<br /> erofs_fileio_readahead<br /> erofs_fileio_rq_submit<br /> vfs_iocb_iter_read<br /> filemap_read<br /> filemap_get_pages

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_key: validate families in pfkey_send_migrate()<br /> <br /> syzbot was able to trigger a crash in skb_put() [1]<br /> <br /> Issue is that pfkey_send_migrate() does not check old/new families,<br /> and that set_ipsecrequest() @family argument was truncated,<br /> thus possibly overfilling the skb.<br /> <br /> Validate families early, do not wait set_ipsecrequest().<br /> <br /> [1]<br /> <br /> skbuff: skb_over_panic: text:ffffffff8a752120 len:392 put:16 head:ffff88802a4ad040 data:ffff88802a4ad040 tail:0x188 end:0x180 dev:<br /> kernel BUG at net/core/skbuff.c:214 !<br /> Call Trace:<br /> <br /> skb_over_panic net/core/skbuff.c:219 [inline]<br /> skb_put+0x159/0x210 net/core/skbuff.c:2655<br /> skb_put_zero include/linux/skbuff.h:2788 [inline]<br /> set_ipsecrequest net/key/af_key.c:3532 [inline]<br /> pfkey_send_migrate+0x1270/0x2e50 net/key/af_key.c:3636<br /> km_migrate+0x155/0x260 net/xfrm/xfrm_state.c:2848<br /> xfrm_migrate+0x2140/0x2450 net/xfrm/xfrm_policy.c:4705<br /> xfrm_do_migrate+0x8ff/0xaa0 net/xfrm/xfrm_user.c:3150

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: Fix dangling pointer on mgmt_add_adv_patterns_monitor_complete<br /> <br /> This fixes the condition checking so mgmt_pending_valid is executed<br /> whenever status != -ECANCELED otherwise calling mgmt_pending_free(cmd)<br /> would kfree(cmd) without unlinking it from the list first, leaving a<br /> dangling pointer. Any subsequent list traversal (e.g.,<br /> mgmt_pending_foreach during __mgmt_power_off, or another<br /> mgmt_pending_valid call) would dereference freed memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: nci: fix circular locking dependency in nci_close_device<br /> <br /> nci_close_device() flushes rx_wq and tx_wq while holding req_lock.<br /> This causes a circular locking dependency because nci_rx_work()<br /> running on rx_wq can end up taking req_lock too:<br /> <br /> nci_rx_work -&gt; nci_rx_data_packet -&gt; nci_data_exchange_complete<br /> -&gt; __sk_destruct -&gt; rawsock_destruct -&gt; nfc_deactivate_target<br /> -&gt; nci_deactivate_target -&gt; nci_request -&gt; mutex_lock(&amp;ndev-&gt;req_lock)<br /> <br /> Move the flush of rx_wq after req_lock has been released.<br /> This should safe (I think) because NCI_UP has already been cleared<br /> and the transport is closed, so the work will see it and return<br /> -ENETDOWN.<br /> <br /> NIPA has been hitting this running the nci selftest with a debug<br /> kernel on roughly 4% of the runs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: Avoid releasing netdev before teardown completes<br /> <br /> The patch cited in the Fixes tag below changed the teardown code for<br /> OVS ports to no longer unconditionally take the RTNL. After this change,<br /> the netdev_destroy() callback can proceed immediately to the call_rcu()<br /> invocation if the IFF_OVS_DATAPATH flag is already cleared on the<br /> netdev.<br /> <br /> The ovs_netdev_detach_dev() function clears the flag before completing<br /> the unregistration, and if it gets preempted after clearing the flag (as<br /> can happen on an -rt kernel), netdev_destroy() can complete and the<br /> device can be freed before the unregistration completes. This leads to a<br /> splat like:<br /> <br /> [ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI<br /> [ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el10_2.x86_64+rt #1 PREEMPT_RT<br /> [ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025<br /> [ 998.393889] RIP: 0010:dev_set_promiscuity+0x8d/0xa0<br /> [ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90<br /> [ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246<br /> [ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000<br /> [ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05<br /> [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000<br /> [ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006<br /> [ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000<br /> [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000<br /> [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0<br /> [ 998.393944] PKRU: 55555554<br /> [ 998.393946] Call Trace:<br /> [ 998.393949] <br /> [ 998.393952] ? show_trace_log_lvl+0x1b0/0x2f0<br /> [ 998.393961] ? show_trace_log_lvl+0x1b0/0x2f0<br /> [ 998.393975] ? dp_device_event+0x41/0x80 [openvswitch]<br /> [ 998.394009] ? __die_body.cold+0x8/0x12<br /> [ 998.394016] ? die_addr+0x3c/0x60<br /> [ 998.394027] ? exc_general_protection+0x16d/0x390<br /> [ 998.394042] ? asm_exc_general_protection+0x26/0x30<br /> [ 998.394058] ? dev_set_promiscuity+0x8d/0xa0<br /> [ 998.394066] ? ovs_netdev_detach_dev+0x3a/0x80 [openvswitch]<br /> [ 998.394092] dp_device_event+0x41/0x80 [openvswitch]<br /> [ 998.394102] notifier_call_chain+0x5a/0xd0<br /> [ 998.394106] unregister_netdevice_many_notify+0x51b/0xa60<br /> [ 998.394110] rtnl_dellink+0x169/0x3e0<br /> [ 998.394121] ? rt_mutex_slowlock.constprop.0+0x95/0xd0<br /> [ 998.394125] rtnetlink_rcv_msg+0x142/0x3f0<br /> [ 998.394128] ? avc_has_perm_noaudit+0x69/0xf0<br /> [ 998.394130] ? __pfx_rtnetlink_rcv_msg+0x10/0x10<br /> [ 998.394132] netlink_rcv_skb+0x50/0x100<br /> [ 998.394138] netlink_unicast+0x292/0x3f0<br /> [ 998.394141] netlink_sendmsg+0x21b/0x470<br /> [ 998.394145] ____sys_sendmsg+0x39d/0x3d0<br /> [ 998.394149] ___sys_sendmsg+0x9a/0xe0<br /> [ 998.394156] __sys_sendmsg+0x7a/0xd0<br /> [ 998.394160] do_syscall_64+0x7f/0x170<br /> [ 998.394162] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 998.394165] RIP: 0033:0x7fad61bf4724<br /> [ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89<br /> [ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e<br /> [ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724<br /> [ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003<br /> [ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f<br /> [ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix double-free of smc_spd_priv when tee() duplicates splice pipe buffer<br /> <br /> smc_rx_splice() allocates one smc_spd_priv per pipe_buffer and stores<br /> the pointer in pipe_buffer.private. The pipe_buf_operations for these<br /> buffers used .get = generic_pipe_buf_get, which only increments the page<br /> reference count when tee(2) duplicates a pipe buffer. The smc_spd_priv<br /> pointer itself was not handled, so after tee() both the original and the<br /> cloned pipe_buffer share the same smc_spd_priv *.<br /> <br /> When both pipes are subsequently released, smc_rx_pipe_buf_release() is<br /> called twice against the same object:<br /> <br /> 1st call: kfree(priv) sock_put(sk) smc_rx_update_cons() [correct]<br /> 2nd call: kfree(priv) sock_put(sk) smc_rx_update_cons() [UAF]<br /> <br /> KASAN reports a slab-use-after-free in smc_rx_pipe_buf_release(), which<br /> then escalates to a NULL-pointer dereference and kernel panic via<br /> smc_rx_update_consumer() when it chases the freed priv-&gt;smc pointer:<br /> <br /> BUG: KASAN: slab-use-after-free in smc_rx_pipe_buf_release+0x78/0x2a0<br /> Read of size 8 at addr ffff888004a45740 by task smc_splice_tee_/74<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x53/0x70<br /> print_report+0xce/0x650<br /> kasan_report+0xc6/0x100<br /> smc_rx_pipe_buf_release+0x78/0x2a0<br /> free_pipe_info+0xd4/0x130<br /> pipe_release+0x142/0x160<br /> __fput+0x1c6/0x490<br /> __x64_sys_close+0x4f/0x90<br /> do_syscall_64+0xa6/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> RIP: 0010:smc_rx_update_consumer+0x8d/0x350<br /> Call Trace:<br /> <br /> smc_rx_pipe_buf_release+0x121/0x2a0<br /> free_pipe_info+0xd4/0x130<br /> pipe_release+0x142/0x160<br /> __fput+0x1c6/0x490<br /> __x64_sys_close+0x4f/0x90<br /> do_syscall_64+0xa6/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Kernel panic - not syncing: Fatal exception<br /> <br /> Beyond the memory-safety problem, duplicating an SMC splice buffer is<br /> semantically questionable: smc_rx_update_cons() would advance the<br /> consumer cursor twice for the same data, corrupting receive-window<br /> accounting. A refcount on smc_spd_priv could fix the double-free, but<br /> the cursor-accounting issue would still need to be addressed separately.<br /> <br /> The .get callback is invoked by both tee(2) and splice_pipe_to_pipe()<br /> for partial transfers; both will now return -EFAULT. Users who need<br /> to duplicate SMC socket data must use a copy-based read path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bcmasp: fix double free of WoL irq<br /> <br /> We do not need to free wol_irq since it was instantiated with<br /> devm_request_irq(). So devres will free for us.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: fix out-of-bounds writes in iavf_get_ethtool_stats()<br /> <br /> iavf incorrectly uses real_num_tx_queues for ETH_SS_STATS. Since the<br /> value could change in runtime, we should use num_tx_queues instead.<br /> <br /> Moreover iavf_get_ethtool_stats() uses num_active_queues while<br /> iavf_get_sset_count() and iavf_get_stat_strings() use<br /> real_num_tx_queues, which triggers out-of-bounds writes when we do<br /> "ethtool -L" and "ethtool -S" simultaneously [1].<br /> <br /> For example when we change channels from 1 to 8, Thread 3 could be<br /> scheduled before Thread 2, and out-of-bounds writes could be triggered<br /> in Thread 3:<br /> <br /> Thread 1 (ethtool -L) Thread 2 (work) Thread 3 (ethtool -S)<br /> iavf_set_channels()<br /> ...<br /> iavf_alloc_queues()<br /> -&gt; num_active_queues = 8<br /> iavf_schedule_finish_config()<br /> iavf_get_sset_count()<br /> real_num_tx_queues: 1<br /> -&gt; buffer for 1 queue<br /> iavf_get_ethtool_stats()<br /> num_active_queues: 8<br /> -&gt; out-of-bounds!<br /> iavf_finish_config()<br /> -&gt; real_num_tx_queues = 8<br /> <br /> Use immutable num_tx_queues in all related functions to avoid the issue.<br /> <br /> [1]<br /> BUG: KASAN: vmalloc-out-of-bounds in iavf_add_one_ethtool_stat+0x200/0x270<br /> Write of size 8 at addr ffffc900031c9080 by task ethtool/5800<br /> <br /> CPU: 1 UID: 0 PID: 5800 Comm: ethtool Not tainted 6.19.0-enjuk-08403-g8137e3db7f1c #241 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6f/0xb0<br /> print_report+0x170/0x4f3<br /> kasan_report+0xe1/0x180<br /> iavf_add_one_ethtool_stat+0x200/0x270<br /> iavf_get_ethtool_stats+0x14c/0x2e0<br /> __dev_ethtool+0x3d0c/0x5830<br /> dev_ethtool+0x12d/0x270<br /> dev_ioctl+0x53c/0xe30<br /> sock_do_ioctl+0x1a9/0x270<br /> sock_ioctl+0x3d4/0x5e0<br /> __x64_sys_ioctl+0x137/0x1c0<br /> do_syscall_64+0xf3/0x690<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f7da0e6e36d<br /> ...<br /> <br /> <br /> The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900031c9000 allocated at __dev_ethtool+0x3cc9/0x5830<br /> The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000<br /> index:0xffff88813a013de0 pfn:0x13a013<br /> flags: 0x200000000000000(node=0|zone=2)<br /> raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000<br /> raw: ffff88813a013de0 0000000000000000 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffffc900031c8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ffffc900031c9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffffc900031c9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ^<br /> ffffc900031c9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ffffc900031c9180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix fanout UAF in packet_release() via NETDEV_UP race<br /> <br /> `packet_release()` has a race window where `NETDEV_UP` can re-register a<br /> socket into a fanout group&amp;#39;s `arr[]` array. The re-registration is not<br /> cleaned up by `fanout_release()`, leaving a dangling pointer in the fanout<br /> array.<br /> `packet_release()` does NOT zero `po-&gt;num` in its `bind_lock` section.<br /> After releasing `bind_lock`, `po-&gt;num` is still non-zero and `po-&gt;ifindex`<br /> still matches the bound device. A concurrent `packet_notifier(NETDEV_UP)`<br /> that already found the socket in `sklist` can re-register the hook.<br /> For fanout sockets, this re-registration calls `__fanout_link(sk, po)`<br /> which adds the socket back into `f-&gt;arr[]` and increments `f-&gt;num_members`,<br /> but does NOT increment `f-&gt;sk_ref`.<br /> <br /> The fix sets `po-&gt;num` to zero in `packet_release` while `bind_lock` is<br /> held to prevent NETDEV_UP from linking, preventing the race window.<br /> <br /> This bug was found following an additional audit with Claude Code based<br /> on CVE-2025-38617.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ti: icssg-prueth: fix use-after-free of CPPI descriptor in RX path<br /> <br /> cppi5_hdesc_get_psdata() returns a pointer into the CPPI descriptor.<br /> In both emac_rx_packet() and emac_rx_packet_zc(), the descriptor is<br /> freed via k3_cppi_desc_pool_free() before the psdata pointer is used<br /> by emac_rx_timestamp(), which dereferences psdata[0] and psdata[1].<br /> This constitutes a use-after-free on every received packet that goes<br /> through the timestamp path.<br /> <br /> Defer the descriptor free until after all accesses through the psdata<br /> pointer are complete. For emac_rx_packet(), move the free into the<br /> requeue label so both early-exit and success paths free the descriptor<br /> after all accesses are done. For emac_rx_packet_zc(), move the free to<br /> the end of the loop body after emac_dispatch_skb_zc() (which calls<br /> emac_rx_timestamp()) has returned.