Linux Kernel Memory Corruption: Fixes and Impact

What happened

Linux has fixed a memory corruption vulnerability in the Linux Kernel, the core software that manages a system's hardware and essential operations. Think of it like moving borrowed items into a new box but leaving behind the label that says they belong to someone else. During network processing, the kernel can move pieces of data without preserving a marker that tells later code those pieces share storage with other users of that memory.

The flaw, CVE-2026-46300, can cause later network processing to modify shared data without taking the protective step that the missing marker would normally trigger. The vendor's fix preserves that marker when the kernel transfers the affected data fragments. NVD published the vulnerability on 2026-05-23 and rates it HIGH, with a CVSS score of 7.8.

CVE-2026-46300 is known to be exploited. CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on 2026-10-28, with a catalog remediation due date of 2026-10-31. Its ransomware-use status is Unknown, which does not establish whether ransomware operators have used it. KISA, Korea's Internet & Security Agency, also published an advisory on 2026-10-29.

Technical details

This is a memory corruption vulnerability. NVD associates it with CWE-123, Write-what-where Condition; CWE-456, Missing Initialization of a Variable; and CWE-787, Out-of-bounds Write. These classifications describe weaknesses involving unsafe writes or missing initialization. The specific mechanism here concerns a lost marker that should tell later code to protect shared memory before modifying it.

The kernel function skb_try_coalesce() combines network data held in socket buffers, which are structures used to manage packets. It can transfer paged fragments, meaning pieces of packet data stored in memory pages, from a source buffer into a destination buffer. When the source carries SKBFL_SHARED_FRAG, the destination can inherit fragments backed by externally owned memory or the page cache, which holds file data in memory. The vulnerable code transfers those fragments without carrying over the shared-fragment marker.

That missing marker matters during ESP input processing, the receive-side handling of Encapsulating Security Payload traffic. ESP checks skb_has_shared_frag() to decide whether it needs skb_cow_data(), a routine used to prepare data for safe modification. After TCP receive processing combines fragments into an unmarked buffer, ESP can incorrectly conclude that this protective preparation is unnecessary and decrypt directly into page-cache-backed fragments. The described failure depends on shared fragments moving through this processing path; it does not establish a complete attack procedure, required attacker privileges, or that every network-facing system can be exploited remotely.

The fix propagates SKBFL_SHARED_FRAG when paged fragments are transferred. A separate path that copies bytes into the destination buffer's directly stored data does not need that marker because it does not transfer the shared fragment references. The CVSS 3.1 score of 7.8 places the flaw in the HIGH severity category. That score describes technical severity; CISA's KEV listing separately establishes that exploitation is known to have occurred.

Weakness types: Memory corruption

Who is affected

Everyday users

For everyday users, the relevant component is the operating system kernel rather than an individual browser or application. If your device runs an affected Linux Kernel, updating applications alone does not establish that this flaw has been fixed. The issue concerns how the kernel handles network data and can lead to unintended changes to shared memory or cached file data.

Use your operating system's supported update process and follow the update steps in the vendor's advisory. An installed update and the kernel currently running are separate things, so confirm that the fixed kernel is active after completing the update process. The KEV listing makes checking your system's status a practical priority, even though the advisory does not describe an identical exposure for every device.

Developers

Developers should distinguish between updating application dependencies and updating the kernel on the machine that runs the application. This flaw sits in kernel networking code, so a change to an application's packet-handling logic does not by itself establish remediation. Check the kernel status of development machines and the systems that host your deployed services.

The underlying programming lesson is about preserving ownership information when moving data. Transferring references to memory can also transfer obligations about how that memory may be modified. Here, later code relies on a marker to decide whether it can write directly into packet data. Losing that marker during buffer combination breaks the assumption, even though the fragments themselves remain available.

Server and IT admins

Server and IT administrators should inventory running kernels and match them to the vendor's affected ranges. The listed ranges and fixes are: >= 3.9 and < 5.10.257, fixed in 5.10.257 and later; >= 5.11 and < 5.15.208, fixed in 5.15.208 and later; and >= 5.16 and < 6.1.174, fixed in 6.1.174 and later.

The remaining listed ranges and fixes are: >= 6.2 and < 6.6.141, fixed in 6.6.141 and later; >= 6.7 and < 6.12.91, fixed in 6.12.91 and later; >= 6.13 and < 6.18.33, fixed in 6.18.33 and later; and >= 6.19 and < 7.0.10, fixed in 7.0.10 and later. Keep each fixed release paired with its corresponding range when planning updates, and use the vendor's advisory to resolve package-specific applicability.

What to do now

1. Check the running kernel version on each relevant system with the allowed version-check command. Record which systems fall into the vendor's listed affected ranges.
2. Read the vendor's advisory for CVE-2026-46300 and confirm the supported fixed kernel package for each system. Match the affected range to its corresponding fixed release.
3. Prioritize remediation because CISA KEV identifies the vulnerability as known to be exploited. Include the catalog due date of 2026-10-31 in your remediation tracking.
4. Follow the update steps in the vendor's advisory. For systems using the listed package managers, use the appropriate package-update command and confirm that the update includes the kernel fix.
5. Complete the vendor's steps for activating the updated kernel, including a restart if required. For servers, coordinate the necessary service interruption.
6. Check the running kernel again after activation and confirm its remediation status against the vendor's advisory. Record the result for each affected system.

uname -r

sudo apt update && sudo apt upgrade

sudo dnf upgrade

How to confirm the fix

• Run the kernel-version check after completing the update and any required restart. Verify the active kernel, rather than relying only on confirmation that a package was downloaded or installed.
• Compare the active kernel with the fixed release corresponding to its affected range, and confirm package-specific remediation through the vendor's advisory.
• Confirm that every system identified as affected has completed the activation and verification steps. Leave systems with an unverified running kernel open in your remediation tracking.

NVD scores and CISA KEV status

Listed in CISA's Known Exploited Vulnerabilities catalog: CVE-2026-46300 (added October 28, 2026). CISA adds a CVE only when it has evidence of exploitation in the real world.

Affected products and fixed versions 7 rows

The vendor's advisory is the authority on affected and fixed versions. If a cell says “See the vendor advisory”, check it there.

Frequently asked questions

References

• Linux advisory: https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published/2026/CVE-2026-46300.dyad
• NVD: CVE-2026-46300
• CISA Known Exploited Vulnerabilities catalog
• Also reported by KISA (Korea Internet & Security Agency) on October 29, 2026: KISA advisory (Korean)

How this page is made: versions and CVE IDs come from the vendor advisory table; CVSS scores and weakness types from NVD; exploitation status only from CISA KEV. The explainer is written with AI from those facts and published only after an automated check matches every version, CVE, score and command against the sources. Commands are limited to ones in official documentation. Always follow the vendor's advisory. Read in Korean.