CVE-2026-22977: Linux Kernel Use-After-Free Vulnerability

CVE-2026-22977 Overview

A kernel vulnerability has been identified in the Linux kernel's networking subsystem involving hardened usercopy protections. The vulnerability exists in the sock_recv_errqueue function where the skbuff_fclone_cache was created without defining a proper usercopy region, unlike skbuff_head_cache which properly whitelists the cb[] field. This causes a usercopy BUG() panic when CONFIG_HARDENED_USERCOPY is enabled and the kernel attempts to copy sk_buff.cb data to userspace via sock_recv_errqueue() → put_cmsg().

Critical Impact

Systems with CONFIG_HARDENED_USERCOPY enabled can experience kernel panics when processing socket error queue messages containing timestamp data from cloned skbs allocated from skbuff_fclone_cache.

Affected Products

• Linux kernel with CONFIG_HARDENED_USERCOPY enabled
• Systems using TCP timestamp reporting via socket error queues
• Linux kernel versions prior to the security patch

Discovery Timeline

• January 21, 2026 - CVE CVE-2026-22977 published to NVD
• January 21, 2026 - Last updated in NVD database

Technical Details for CVE-2026-22977

Vulnerability Analysis

This vulnerability stems from an inconsistency in how SLAB object usercopy regions are defined for different skbuff caches in the Linux kernel. When CONFIG_HARDENED_USERCOPY is enabled, the kernel enforces strict checks to prevent arbitrary kernel memory from being copied to userspace. The skbuff_head_cache correctly defines a usercopy whitelist for the cb[] (control buffer) field, but skbuff_fclone_cache was created without this same protection.

The crash occurs through a specific sequence: TCP allocates an skb using alloc_skb_fclone() from skbuff_fclone_cache, the skb is cloned via skb_clone() using the pre-allocated fclone, the cloned skb is queued to sk_error_queue for timestamp reporting, and when userspace reads the error queue via recvmsg(MSG_ERRQUEUE), the sock_recv_errqueue() function calls put_cmsg() to copy serr->ee from skb->cb. At this point, __check_heap_object() fails because skbuff_fclone_cache has no usercopy whitelist defined.

The crash offset of 296 corresponds to skb2->cb within the skbuff_fclones structure, calculated as: sizeof(struct sk_buff) (232) + offsetof(struct sk_buff, cb) (40) = 272, with the crash occurring at offset 296 (272 + 24, inside sock_exterr_skb.ee).

Root Cause

The root cause is the missing usercopy region definition in skbuff_fclone_cache creation. While skbuff_head_cache properly defines which portions of the sk_buff structure can be safely copied to userspace (specifically the cb[] field used for control data), the fclone cache was created without equivalent protections. This oversight means that when cloned skbs from this cache are used in operations that copy data to userspace, the hardened usercopy mechanism correctly identifies this as a potential kernel memory exposure attempt and triggers a kernel BUG.

Attack Vector

The vulnerability is triggered when:

1. A TCP connection allocates skbs from skbuff_fclone_cache for operations requiring cloning
2. The cloned skb is used to report timestamps or other socket-level errors
3. The application calls recvmsg() with MSG_ERRQUEUE flag to retrieve error queue data
4. The kernel's put_cmsg() attempts to copy the sock_exterr_skb structure from skb->cb to userspace
5. The hardened usercopy check detects the copy from an unmarked region and triggers a kernel panic

The kernel panic message indicates: "usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_fclone_cache' (offset 296, size 16)!"

This is primarily a denial-of-service condition that can be triggered by any local process with the ability to create network sockets and read error queues, particularly affecting TLS connections using timestamp reporting functionality.

Detection Methods for CVE-2026-22977

Indicators of Compromise

• Kernel panic messages containing "usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_fclone_cache'"
• System crashes with stack traces showing usercopy_abort, __check_heap_object, and put_cmsg in the call chain
• Repeated kernel BUG reports in /var/log/kern.log or dmesg output referencing mm/usercopy.c

Detection Strategies

• Monitor system logs for kernel oops or BUG messages mentioning skbuff_fclone_cache or usercopy violations
• Check for processes calling recvmsg() with MSG_ERRQUEUE flag that precede system crashes
• Review kernel configuration to determine if CONFIG_HARDENED_USERCOPY is enabled
• Implement kernel tracing on sock_recv_errqueue() and put_cmsg() functions to identify triggering conditions

Monitoring Recommendations

• Deploy kernel crash dump collection (kdump) to capture diagnostic information when panics occur
• Enable audit logging for socket operations, particularly error queue reads
• Monitor for abnormal rates of TLS connection establishments that may be attempting to trigger the vulnerability
• Use SentinelOne Singularity Platform for real-time kernel-level anomaly detection and automated response

How to Mitigate CVE-2026-22977

Immediate Actions Required

• Apply the kernel patches from the official Linux kernel git repository
• If patching is not immediately possible, consider temporarily disabling CONFIG_HARDENED_USERCOPY (note: this reduces overall kernel security)
• Restrict local user access to prevent untrusted users from triggering the vulnerability
• Monitor systems for crash events and prioritize patching on affected hosts

Patch Information

Multiple patches have been released to address this vulnerability. The fix introduces a local stack variable as a bounce buffer to avoid the hardened usercopy check failure when copying data from skb->cb to userspace. Organizations should apply the appropriate patch for their kernel version:

• Kernel commit 005671c60fcf
• Kernel commit 2a71a1a8d0ed
• Kernel commit 582a5e922a96
• Kernel commit 88dd6be7ebb3
• Kernel commit 8c6901aa2962
• Kernel commit c655d2167bf0
• Kernel commit e00b169eaac5

Workarounds

• Recompile the kernel with CONFIG_HARDENED_USERCOPY=n to disable the hardened usercopy checks (reduces security posture)
• Limit local user access to sensitive systems until patches can be applied
• If TLS timestamp reporting is not required, consider disabling socket timestamp options at the application level
• Use container isolation to limit the blast radius of potential kernel panics

# Check if CONFIG_HARDENED_USERCOPY is enabled on your system
zcat /proc/config.gz | grep CONFIG_HARDENED_USERCOPY

# Alternatively, check the kernel config file
grep CONFIG_HARDENED_USERCOPY /boot/config-$(uname -r)

# Check current kernel version
uname -r