CVE-2026-46323

What it actually does

This is a Linux kernel use-after-free flaw in the networking Generic Receive Offload (GRO) path. The vulnerable code can merge packet buffer fragments from zero-copy socket buffers without properly accounting for page references, particularly when SKBFL_MANAGED_FRAG_REFS is set. That can cause the kernel to reference memory after it has been freed, creating a kernel memory corruption condition. With local low-privileged access, an attacker may be able to trigger a crash, corrupt kernel memory, disclose sensitive memory, or potentially escalate privileges to kernel-level execution.

Why it matters to the business

Systems running vulnerable Linux kernels are exposed to local privilege-escalation and denial-of-service risk. The most relevant business concern is that a low-privileged local user, compromised application process, or containerized workload could potentially destabilize the host or gain higher privileges. This can affect availability of Linux servers, container hosts, virtualization platforms, and appliances that rely on affected kernels. The vulnerability is not currently listed in CISA KEV, has no reported ransomware use, and has a low EPSS score, so broad active exploitation is not indicated, but kernel-level memory corruption should still be treated as high impact where untrusted local code can run.

How an attack unfolds

An attacker first needs local code execution or access to run a process with low privileges on a vulnerable Linux system. They then attempt to create network traffic patterns and socket-buffer conditions that cause the kernel GRO path to merge fragments involving zero-copy socket buffers. In the vulnerable path, skb_gro_receive() may append fragments from one socket buffer to another without holding the required page references. Once the original pages are released, the GRO chain can retain references to freed memory. The attacker then tries to reclaim or shape that freed memory with controlled data and cause the kernel to reuse it, resulting in a use-after-free condition. Depending on allocator behavior, kernel configuration, mitigations, and exploit reliability, this may lead to a kernel panic, information disclosure, or privilege escalation.

How to fix it

Apply the Linux kernel update that includes the fix for the GRO zero-copy socket-buffer handling issue. Use the corrected kernel packages from the operating-system or appliance vendor and reboot into the patched kernel. Where immediate patching is not possible, reduce exposure by limiting shell or workload access for untrusted users, isolating untrusted containers, and restricting local code execution on affected hosts. As a temporary risk-reduction measure, consider disabling GRO on exposed interfaces with tools such as ethtool where operationally acceptable, recognizing that this may reduce network performance and should not be treated as a replacement for patching. Monitor vendor advisories for exact fixed kernel versions because affected product and fixed-version data were not provided in the input.

How to confirm the fix worked

Confirm that the running kernel, not only the installed package, is updated to a vendor build that contains the fix. Validate with uname -a, package-manager queries, and vendor advisory mapping for the deployed distribution or appliance. If GRO was disabled as a temporary mitigation, verify interface settings with ethtool -k <interface> and confirm generic-receive-offload is off where intended. After patching, reboot and confirm the active kernel version changed. Review kernel logs for recurring crashes or use-after-free diagnostics in the networking receive path, especially messages referencing skb_gro_receive, GRO, KASAN, page reference issues, or kernel oops events.

Typical attack path

1. Obtain local low-privileged execution on a Linux system running a vulnerable kernel.
2. Generate or control network traffic and socket activity capable of reaching the GRO receive path.
3. Trigger conditions where zero-copy socket buffers are processed and eligible for GRO merging.
4. Cause skb_gro_receive() to append fragments without proper page-reference handling.
5. Force release and reuse of the underlying pages to create a use-after-free condition.
6. Abuse the resulting kernel memory corruption for denial of service, information disclosure, or privilege escalation.

How to detect it

There is no reliable network-only indicator for successful exploitation because this is a local kernel memory-corruption issue and exploitation artifacts depend on host configuration and allocator state. Detection should focus on host telemetry: kernel logs, crash dumps, audit logs, EDR process lineage, and privilege-change events. Search dmesg, journald, /var/log/kern.log, /var/log/messages, vmcore data, and KASAN reports for use-after-free, kernel oops, page-reference, or GRO/socket-buffer stack traces. Pay particular attention to crashes involving skb_gro_receive(), napi_gro_receive(), netif_receive_skb(), skb_release_data(), or page reference/freeing routines. Correlate such events with local user activity, container workload activity, unusual network traffic generation from local processes, unexpected root shells, setuid file creation, kernel module loading, credential changes, or suspicious post-crash persistence. Absence of these artifacts does not prove non-exploitation, because a reliable privilege-escalation exploit may leave minimal kernel logging.

• skb_gro_receive
• napi_gro_receive
• netif_receive_skb
• skb_release_data
• SKBFL_MANAGED_FRAG_REFS
• BUG: KASAN: use-after-free
• KASAN: use-after-free
• use-after-free in skb_gro_receive
• general protection fault
• kernel BUG at net/core/gro.c
• Oops:
• page refcount
• refcount_t: underflow
• generic-receive-offload: on

What your security team should do

• Prioritize patching Linux systems that allow untrusted local users, shared hosting, CI/CD runners, container workloads, research sandboxes, or third-party application code.
• Inventory externally managed appliances and embedded Linux platforms that may lag upstream kernel fixes, and track vendor-specific fixed releases.
• Where patching is delayed, restrict local interactive access, reduce container escape blast radius, and enforce least privilege for workloads.
• Consider temporarily disabling GRO on high-risk hosts if performance impact is acceptable and patching cannot be completed quickly.
• Review kernel crash telemetry and system logs for evidence of use-after-free, KASAN, general protection fault, or oops events in the networking stack.
• Treat unexplained kernel panics on vulnerable hosts as potentially security-relevant until patched and reviewed.
• Monitor for public exploit development even though current exploit maturity is listed as none and the EPSS score is low.