high CVSS 7.8

CVE-2024-26961·Kernel vulnerability

In the Linux kernel, the following vulnerability has been resolved: mac802154: fix llsec key resources release in mac802154_llsec_key_del mac802154_llsec_key_del() can free resources of a key directly without following the RCU rules for waiting before the end of a grace period. This may lead to use-after-free in case llsec_lookup_key() is traversing the list of keys in parallel with a key deletion: refcount_t: addition on 0; use-after-free. WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0 Modules linked in: CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:refcount_warn_saturate+0x162/0x2a0 Call Trace: <TASK> llsec_lookup_key.isra.0+0x890/0x9e0 mac802154_llsec_encrypt+0x30c/0x9c0 ieee802154_subif_start_xmit+0x24/0x1e0 dev_hard_start_xmit+0x13e/0x690 sch_direct_xmit+0x2ae/0xbc0 __dev_queue_xmit+0x11dd/0x3c20 dgram_sendmsg+0x90b/0xd60 __sys_sendto+0x466/0x4c0 __x64_sys_sendto+0xe0/0x1c0 do_syscall_64+0x45/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Also, ieee802154_llsec_key_entry structures are not freed by mac802154_llsec_key_del(): unreferenced object 0xffff8880613b6980 (size 64): comm "iwpan", pid 2176, jiffies 4294761134 (age 60.475s) hex dump (first 32 bytes): 78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de x......."....... 00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00 ................ backtrace: [<ffffffff81dcfa62>] __kmem_cache_alloc_node+0x1e2/0x2d0 [<ffffffff81c43865>] kmalloc_trace+0x25/0xc0 [<ffffffff88968b09>] mac802154_llsec_key_add+0xac9/0xcf0 [<ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80 [<ffffffff8892adc6>] nl802154_add_llsec_key+0x426/0x5b0 [<ffffffff86ff293e>] genl_family_rcv_msg_doit+0x1fe/0x2f0 [<ffffffff86ff46d1>] genl_rcv_msg+0x531/0x7d0 [<ffffffff86fee7a9>] netlink_rcv_skb+0x169/0x440 [<ffffffff86ff1d88>] genl_rcv+0x28/0x40 [<ffffffff86fec15c>] netlink_unicast+0x53c/0x820 [<ffffffff86fecd8b>] netlink_sendmsg+0x93b/0xe60 [<ffffffff86b91b35>] ____sys_sendmsg+0xac5/0xca0 [<ffffffff86b9c3dd>] ___sys_sendmsg+0x11d/0x1c0 [<ffffffff86b9c65a>] __sys_sendmsg+0xfa/0x1d0 [<ffffffff88eadbf5>] do_syscall_64+0x45/0xf0 [<ffffffff890000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 Handle the proper resource release in the RCU callback function mac802154_llsec_key_del_rcu(). Note that if llsec_lookup_key() finds a key, it gets a refcount via llsec_key_get() and locally copies key id from key_entry (which is a list element). So it's safe to call llsec_key_put() and free the list entry after the RCU grace period elapses. Found by Linux Verification Center (linuxtesting.org).

Severity
high
Software
Kernel
Fixed in
6.8.3
Published
2024-05-01

Affected versions

From: 6.8

Until: 6.8.3

Fixed in: 6.8.3

How to fix this CVE

Update your Linux kernel to version 6.8.3 or later to resolve a critical use-after-free vulnerability in the MAC 802.15.4 link-layer security key deletion function. This vulnerability allows concurrent access to freed memory when keys are deleted while being looked up, potentially causing kernel crashes or memory corruption. Apply the patch immediately if you are running kernel versions 6.8 through 6.8.2.

sudo dnf check-update kernel && sudo dnf update kernel

Defensia detects this vulnerability

How to check if you are affected

  1. Check your kernel version: uname -r — confirm if it is between 6.8.0 and 6.8.2 (vulnerable range)
  2. Verify if 802.15.4 WPAN (Wireless Personal Area Network) is active: lsmod | grep mac802154 — if no output, the vulnerable component is not loaded
  3. Search kernel logs for refcount warnings: dmesg | grep -i 'refcount_t: addition on 0' or journalctl -b | grep -i refcount — these indicate exploitation attempts
  4. After patching, confirm the new kernel version: uname -r — should show 6.8.3 or later, and verify module reload: modprobe -r mac802154 && modprobe mac802154

FAQ

What is CVE-2024-26961?

CVE-2024-26961 is a use-after-free vulnerability in the Linux kernel's MAC 802.15.4 link-layer security implementation where the key deletion function fails to properly synchronize with RCU (Read-Copy-Update), allowing freed memory to be accessed by concurrent key lookup operations.

Is CVE-2024-26961 being actively exploited?

No, CVE-2024-26961 is not listed on CISA's Known Exploited Vulnerabilities (KEV) catalog and there are no public exploits available. However, it can be triggered locally by an unprivileged user with access to 802.15.4 network interfaces.

What versions of Kernel are affected by CVE-2024-26961?

Linux kernel versions 6.8.0 through 6.8.2 are affected. The vulnerability was fixed in kernel 6.8.3 and later releases.

How do I check if my server is vulnerable to CVE-2024-26961?

Run 'uname -r' and check if the kernel version is 6.8.0, 6.8.1, or 6.8.2. Additionally, verify if MAC 802.15.4 support is enabled with 'grep -i 802154 /boot/config-$(uname -r)' or 'lsmod | grep mac802154'.

Does Defensia detect CVE-2024-26961?

Yes — Defensia's CVE advisory scanner compares installed package versions against the NVD database. If Kernel is installed on a monitored server, CVE-2024-26961 will appear in your dashboard with remediation steps.

Related Kernel CVEs

CVE-2026-43501CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: reserve mac_len headroom when recompressed SRH grows ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6_hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes). pskb_expand_head() was gated on segments_left == 0, so on earlier segments the push consumed unchecked headroom. Once skb_push() leaves fewer than skb->mac_len bytes in front of data, skb_mac_header_rebuild()'s call to: skb_set_mac_header(skb, -skb->mac_len); will store (data - head) - mac_len into the u16 mac_header field, which wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB past skb->head. A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv. Fix this by expanding the head whenever the remaining room is less than the push size plus mac_len, and request that much extra so the rebuilt MAC header fits afterwards.
CVE-2026-64385CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: smb: client: fix double-free in SMB2_ioctl() replay A response-bearing attempt can return a replayable error and free its response buffer. If SMB2_ioctl_init() fails before the next send, cleanup retains the previous buffer type and frees that response again. Reset response bookkeeping before each attempt to prevent the stale free.
CVE-2026-64391CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: ksmbd: use opener credentials for ADS I/O Alternate data streams are stored as xattrs. Unlike regular file I/O, their read and write paths therefore call VFS xattr helpers which recheck inode permissions and LSM policy using the current task credentials. Run ADS I/O with the credentials captured when the SMB handle was opened.
CVE-2026-64383CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: smb: client: fix double-free in SMB2_flush() replay SMB2_flush() keeps its response buffer bookkeeping across replay attempts. If a replayable flush response is received and the retry then fails before cifs_send_recv() stores a replacement response, flush_exit will free the stale response pointer a second time. Reinitialize resp_buftype and rsp_iov at the top of the replay loop so cleanup only acts on response state produced by the current attempt. This fixes a double-free without changing replay handling for successful requests.
CVE-2026-53176CVSS 9.8In the Linux kernel, the following vulnerability has been resolved: IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN In drivers/infiniband/ulp/isert/ib_isert.c, isert_login_recv_done() computes the login request payload length as wc->byte_len minus ISER_HEADERS_LEN with no lower bound, and login_req_len is a signed int. A remote iSER initiator can post a login Send work request carrying fewer than ISER_HEADERS_LEN (76) bytes, so the subtraction underflows and login_req_len becomes negative. isert_rx_login_req() then reads that negative length back into a signed int, takes size = min(rx_buflen, MAX_KEY_VALUE_PAIRS), and because the min() is signed it keeps the negative value; the value is then passed as the memcpy() length and sign-extended to a multi-gigabyte size_t. The copy into the 8192-byte login->req_buf runs far out of bounds and faults, crashing the target node. The login phase precedes iSCSI authentication, so no credentials are required to reach this path. Reject any login PDU shorter than ISER_HEADERS_LEN before the subtraction, mirroring the existing early return on a failed work completion, so login_req_len can never go negative. The upper bound was already safe: a posted login buffer cannot deliver more than ISER_RX_PAYLOAD_SIZE, so the difference stays at or below MAX_KEY_VALUE_PAIRS and the existing min() clamps it; only the missing lower bound needs to be added.

References

Track CVEs across your fleet automatically

Defensia scans your Linux servers and tells you exactly which ones are running vulnerable versions — including CVE-2024-26961. Free for 1 server.

Get started free