Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> devlink: Release nested relation on devlink free<br /> <br /> devlink relation state is normally released from devl_unregister(), which<br /> calls devlink_rel_put(). This misses devlink instances that get a nested<br /> relation before registration and then fail probe before devl_register() is<br /> reached.<br /> <br /> That flow can happen for SFs. The child devlink gets linked to its<br /> parent before registration, then a later probe error calls devlink_free()<br /> directly. Since the instance was never registered, devl_unregister() is not<br /> called and devlink-&gt;rel is leaked.<br /> <br /> Release any pending relation from devlink_free() as well. The registered<br /> path is unchanged because devl_unregister() already clears devlink-&gt;rel<br /> before devlink_free() runs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: anycast: insert aca into global hash under idev-&gt;lock<br /> <br /> syzbot reported a splat [1]: a slab-use-after-free in<br /> ipv6_chk_acast_addr(), which walks the global inet6_acaddr_lst[] hash<br /> under RCU and dereferences a struct ifacaddr6 that has already been<br /> freed while still linked in the hash, so a later reader walks into a<br /> dangling node.<br /> <br /> In __ipv6_dev_ac_inc() the aca is allocated with refcount 1, then<br /> aca_get() bumps it to 2 to keep it alive across the unlocked region.<br /> It is published to idev-&gt;ac_list under idev-&gt;lock, but<br /> ipv6_add_acaddr_hash() runs after write_unlock_bh(). A concurrent<br /> teardown (ipv6_ac_destroy_dev() from addrconf_ifdown(), under RTNL)<br /> can slip into that window:<br /> <br /> CPU0 __ipv6_dev_ac_inc CPU1 ipv6_ac_destroy_dev (RTNL)<br /> ------------------------------ ------------------------------------<br /> aca_alloc() refcnt 1<br /> aca_get() refcnt 2<br /> write_lock_bh(idev-&gt;lock)<br /> add aca to ac_list<br /> write_unlock_bh(idev-&gt;lock)<br /> write_lock_bh(idev-&gt;lock)<br /> pull aca off ac_list<br /> write_unlock_bh(idev-&gt;lock)<br /> ipv6_del_acaddr_hash(aca)<br /> hlist_del_init_rcu() is a no-op,<br /> aca is not in the hash yet<br /> aca_put() refcnt 2-&gt;1<br /> ipv6_add_acaddr_hash(aca)<br /> aca now inserted into the hash<br /> aca_put() refcnt 1-&gt;0<br /> call_rcu(aca_free_rcu) -&gt; kfree(aca)<br /> <br /> The hash removal becomes a no-op because the insertion has not<br /> happened yet, so once CPU0 inserts and drops the last reference, the<br /> aca is freed while still linked in inet6_acaddr_lst[], and readers<br /> dereference freed memory after the slab slot is reused.<br /> <br /> This window opened once RTNL stopped serializing the join path against<br /> device teardown. Move ipv6_add_acaddr_hash() inside the idev-&gt;lock<br /> section so the ac_list and hash insertions are atomic with respect to<br /> teardown: a racing remover now either misses the aca entirely or finds<br /> it in both lists.<br /> <br /> acaddr_hash_lock is now nested under idev-&gt;lock, which is acquired in<br /> softirq context, so switch all acaddr_hash_lock sites to spin_lock_bh()<br /> to avoid the irq lock inversion reported in [2].<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=a01df04303c131efbf3a<br /> [2] https://lore.kernel.org/netdev/6a194ef7.ba3b1513.1890b4.0000.GAE@google.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: fix leak if split 6 GHz scanning fails<br /> <br /> rdev-&gt;int_scan_req is leaked if cfg80211_scan() fails. Note that it&amp;#39;s<br /> supposed to be released at ___cfg80211_scan_done() but this doesn&amp;#39;t happen<br /> as rdev-&gt;scan_req is NULL at that point, too, leading to the early return<br /> from the freeing function.<br /> <br /> unreferenced object 0xffff8881161d0800 (size 512):<br /> comm "wpa_supplicant", pid 379, jiffies 4294749765<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 f0 81 13 16 81 88 ff ff ................<br /> backtrace (crc c867fdb6):<br /> kmemleak_alloc+0x89/0x90<br /> __kmalloc_noprof+0x2fd/0x410<br /> cfg80211_scan+0x133/0x730<br /> nl80211_trigger_scan+0xc69/0x1cc0<br /> genl_family_rcv_msg_doit+0x204/0x2f0<br /> genl_rcv_msg+0x431/0x6b0<br /> netlink_rcv_skb+0x143/0x3f0<br /> genl_rcv+0x27/0x40<br /> netlink_unicast+0x4f6/0x820<br /> netlink_sendmsg+0x797/0xce0<br /> __sock_sendmsg+0xc4/0x160<br /> ____sys_sendmsg+0x5e4/0x890<br /> ___sys_sendmsg+0xf8/0x180<br /> __sys_sendmsg+0x136/0x1e0<br /> __x64_sys_sendmsg+0x76/0xc0<br /> x64_sys_call+0x13f0/0x17d0<br /> <br /> Found by Linux Verification Center (linuxtesting.org).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: enforce HE/EHT cap/oper consistency<br /> <br /> Xiang Mei reports that mac80211 could crash if eht_cap is set<br /> but eht_oper isn&amp;#39;t. Rather than fixing that for the individual<br /> user(s), enforce that both HE/EHT have consistent elements.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: RFCOMM: hold listener socket in rfcomm_connect_ind()<br /> <br /> rfcomm_get_sock_by_channel() scans rfcomm_sk_list under the list lock,<br /> but returns the selected listener after dropping that lock without<br /> taking a reference. rfcomm_connect_ind() then locks the listener,<br /> queues a child socket on it, and may notify it after unlocking it.<br /> <br /> The buggy scenario involves two paths, with each column showing the<br /> order within that path:<br /> <br /> rfcomm_connect_ind(): listener close:<br /> 1. Find parent in 1. close() enters<br /> rfcomm_get_sock_by_channel() rfcomm_sock_release().<br /> 2. Drop rfcomm_sk_list.lock 2. rfcomm_sock_shutdown()<br /> without pinning parent. closes the listener.<br /> 3. Call lock_sock(parent) and 3. rfcomm_sock_kill()<br /> bt_accept_enqueue(parent, unlinks and puts parent.<br /> sk, true).<br /> 4. Read parent flags and may 4. parent can be freed.<br /> call sk_state_change().<br /> <br /> If close wins the race, parent can be freed before<br /> rfcomm_connect_ind() reaches lock_sock(), bt_accept_enqueue(), or the<br /> deferred-setup callback.<br /> <br /> Take a reference on the listener before leaving rfcomm_sk_list.lock.<br /> After lock_sock() succeeds, recheck that it is still in BT_LISTEN<br /> before queueing a child, cache the deferred-setup bit while the parent<br /> is locked, and drop the reference after the last parent use.<br /> <br /> KASAN reported a slab-use-after-free in lock_sock_nested() from<br /> rfcomm_connect_ind(), with the freeing stack going through<br /> rfcomm_sock_kill() and rfcomm_sock_release().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: validate advertising TLV before type checks<br /> <br /> tlv_data_is_valid() reads each advertising data field length from<br /> data[i], then inspects data[i + 1] for managed EIR types before<br /> checking that the current field still fits inside the supplied buffer.<br /> <br /> A malformed field whose length byte is the last byte of the buffer can<br /> therefore make the parser read one byte past the advertising data.<br /> <br /> KASAN reported the following when a malformed MGMT_OP_ADD_ADVERTISING<br /> request reached that path:<br /> <br /> BUG: KASAN: vmalloc-out-of-bounds in tlv_data_is_valid()<br /> Read of size 1<br /> Call trace:<br /> tlv_data_is_valid()<br /> add_advertising()<br /> hci_mgmt_cmd()<br /> hci_sock_sendmsg()<br /> <br /> Move the existing element-length check before any type-octet inspection<br /> so each non-empty element is proven to contain its type byte before the<br /> parser looks at data[i + 1].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: RFCOMM: validate skb length in MCC handlers<br /> <br /> The RFCOMM MCC handlers cast skb-&gt;data to protocol-specific structs<br /> without validating skb-&gt;len first. A malicious remote device can send<br /> truncated MCC frames and trigger out-of-bounds reads in these handlers.<br /> <br /> Fix this by using skb_pull_data() to validate and access the required<br /> data before dereferencing it.<br /> <br /> rfcomm_recv_rpn() requires special handling since ETSI TS 07.10 allows<br /> 1-byte RPN requests. Handle this by validating only the DLCI byte first,<br /> and validating the full struct only when len &gt; 1.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: bnep: reject short frames before parsing<br /> <br /> A BNEP peer can send a short BNEP SDU. bnep_rx_frame() reads the<br /> packet type byte immediately and, for control packets, reads the control<br /> opcode and setup UUID-size byte before proving that those bytes are<br /> present. bnep_rx_control() also dereferences the control opcode without<br /> rejecting an empty control payload.<br /> <br /> Use skb_pull_data() for the fixed fields in bnep_rx_frame() so a NULL<br /> return gates each dereference. Split the control handler so the frame<br /> path can pass an opcode that has already been pulled, and keep the<br /> byte-buffer wrapper for extension control payloads.<br /> <br /> For BNEP_SETUP_CONN_REQ, name the UUID-size byte before pulling the<br /> setup payload. struct bnep_setup_conn_req carries destination and source<br /> service UUIDs after that byte, each uuid_size bytes, so the parser now<br /> documents that tuple explicitly instead of leaving the pull length as an<br /> opaque multiplication.<br /> <br /> Validation reproduced this kernel report:<br /> KASAN slab-out-of-bounds in bnep_rx_frame.isra.0+0x130c/0x1790<br /> The buggy address belongs to the object at ffff88800c0f7908 which belongs<br /> to the cache kmalloc-8 of size 8<br /> The buggy address is located 0 bytes to the right of allocated 1-byte<br /> region [ffff88800c0f7908, ffff88800c0f7909)<br /> Read of size 1<br /> Call trace:<br /> dump_stack_lvl+0xb3/0x140 (?:?)<br /> print_address_description+0x57/0x3a0 (?:?)<br /> bnep_rx_frame+0x130c/0x1790 (net/bluetooth/bnep/core.c:306)<br /> print_report+0xb9/0x2b0 (?:?)<br /> __virt_addr_valid+0x1ba/0x3a0 (?:?)<br /> srso_alias_return_thunk+0x5/0xfbef5 (?:?)<br /> kasan_addr_to_slab+0x21/0x60 (?:?)<br /> kasan_report+0xe0/0x110 (?:?)<br /> process_one_work+0xfce/0x17e0 (kernel/workqueue.c:3200)<br /> worker_thread+0x65c/0xe40 (?:?)<br /> __kthread_parkme+0x184/0x230 (?:?)<br /> kthread+0x35e/0x470 (?:?)<br /> _raw_spin_unlock_irq+0x28/0x50 (?:?)<br /> ret_from_fork+0x586/0x870 (?:?)<br /> __switch_to+0x74f/0xdc0 (?:?)<br /> ret_from_fork_asm+0x1a/0x30 (?:?)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: fix memory leak in error path of hci_alloc_dev()<br /> <br /> Early failures in Bluetooth HCI UART configuration leak SRCU percpu<br /> memory.<br /> <br /> When device initialization fails before hci_register_dev() completes,<br /> the HCI_UNREGISTER flag is never set. As a result, when the device<br /> reference count reaches zero, bt_host_release() evaluates this flag as<br /> false and falls back to a direct kfree(hdev).<br /> <br /> Because hci_release_dev() is bypassed, the SRCU struct initialized<br /> early in hci_alloc_dev() is never cleaned up, resulting in a leak of<br /> percpu memory.<br /> <br /> Fix the leak by explicitly calling cleanup_srcu_struct() in the<br /> fallback (unregistered) branch of bt_host_release() before freeing<br /> the device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: ISO: Fix not releasing hdev reference on iso_conn_big_sync<br /> <br /> hci_get_route() returns a reference-counted hci_dev pointer via<br /> hci_dev_hold(). The function exits normally or with an error without ever<br /> releasing it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Add preempt_{disable,enable}_nested() in reqsk_queue_hash_req().<br /> <br /> syzbot reported a weird reqsk-&gt;rsk_refcnt underflow in<br /> __inet_csk_reqsk_queue_drop().<br /> <br /> The captured reqsk_put() in __inet_csk_reqsk_queue_drop()<br /> is called only when it successfully removes reqsk from ehash.<br /> <br /> Moreover, reqsk_timer_handler() calls another reqsk_put()<br /> after that.<br /> <br /> This indicates that the reqsk was missing both refcnts for<br /> ehash and the timer itself.<br /> <br /> Since all the syzbot reports had PREEMPT_RT enabled, the only<br /> possible scenario is that reqsk_queue_hash_req() is preempted<br /> after mod_timer() and before refcount_set(), and then the timer<br /> triggered after 1s aborts the reqsk due to its listener&amp;#39;s close().<br /> <br /> Let&amp;#39;s wrap mod_timer() and refcount_set() with<br /> preempt_disable_nested() and preempt_enable_nested().<br /> <br /> Note that inet_ehash_insert() holds the normal spin_lock()<br /> (mutex in PREEMPT_RT), so it must be called outside of<br /> preempt_disable_nested(), but this is fine.<br /> <br /> The lookup path just ignores 0 sk_refcnt entries in ehash<br /> and tries to create another reqsk, but this will fail at<br /> inet_ehash_insert().<br /> <br /> [0]:<br /> refcount_t: underflow; use-after-free.<br /> WARNING: lib/refcount.c:28 at refcount_warn_saturate+0xb2/0x110 lib/refcount.c:28, CPU#0: ktimers/0/16<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 16 Comm: ktimers/0 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)}<br /> Tainted: [L]=SOFTLOCKUP<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026<br /> RIP: 0010:refcount_warn_saturate+0xb2/0x110 lib/refcount.c:28<br /> Code: e4 7d d1 0a 67 48 0f b9 3a eb 4a e8 38 3d 23 fd 48 8d 3d e1 7d d1 0a 67 48 0f b9 3a eb 37 e8 25 3d 23 fd 48 8d 3d de 7d d1 0a 48 0f b9 3a eb 24 e8 12 3d 23 fd 48 8d 3d db 7d d1 0a 67 48 0f<br /> RSP: 0000:ffffc90000157948 EFLAGS: 00010246<br /> RAX: ffffffff84a1301b RBX: 0000000000000003 RCX: ffff88801ca98000<br /> RDX: 0000000000000100 RSI: 0000000000000000 RDI: ffffffff8f72ae00<br /> RBP: ffffffff99ae3b01 R08: ffff88801ca98000 R09: 0000000000000005<br /> R10: 0000000000000100 R11: 0000000000000004 R12: ffff8880425ef568<br /> R13: ffff8880425ef4f8 R14: ffff8880425ef578 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff888126386000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f7b46710e9c CR3: 000000000dbb6000 CR4: 00000000003526f0<br /> Call Trace:<br /> <br /> __refcount_sub_and_test include/linux/refcount.h:400 [inline]<br /> __refcount_dec_and_test include/linux/refcount.h:432 [inline]<br /> refcount_dec_and_test include/linux/refcount.h:450 [inline]<br /> reqsk_put include/net/request_sock.h:136 [inline]<br /> __inet_csk_reqsk_queue_drop+0x3ce/0x440 net/ipv4/inet_connection_sock.c:1007<br /> reqsk_timer_handler+0x651/0xdf0 net/ipv4/inet_connection_sock.c:1137<br /> call_timer_fn+0x192/0x5e0 kernel/time/timer.c:1748<br /> expire_timers kernel/time/timer.c:1799 [inline]<br /> __run_timers kernel/time/timer.c:2374 [inline]<br /> __run_timer_base+0x6a3/0x9f0 kernel/time/timer.c:2386<br /> run_timer_base kernel/time/timer.c:2395 [inline]<br /> run_timer_softirq+0x67/0x170 kernel/time/timer.c:2403<br /> handle_softirqs+0x1de/0x6d0 kernel/softirq.c:622<br /> __do_softirq kernel/softirq.c:656 [inline]<br /> run_ktimerd+0x69/0x100 kernel/softirq.c:1151<br /> smpboot_thread_fn+0x541/0xa50 kernel/smpboot.c:160<br /> kthread+0x388/0x470 kernel/kthread.c:436<br /> ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: restrict IPOPT_SSRR and IPOPT_LSRR options<br /> <br /> This patch restricts setting Loose Source and Record Route (LSRR)<br /> and Strict Source and Record Route (SSRR) IP options to users<br /> with CAP_NET_RAW capability.<br /> <br /> This prevents unprivileged applications from forcing packets to route<br /> through attacker-controlled nodes to leak TCP ISN and possibly other<br /> protocol information.<br /> <br /> While LSRR and SSRR are commonly filtered in many network environments,<br /> they may still be supported and forwarded along some network paths.<br /> <br /> RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing<br /> IPv4 Options) recommend to drop these options in 4.3 and 4.4.