Linux Kernel Memory Corruption: Fixes Explained

What happened

Linux has fixed a memory corruption vulnerability in the Linux Kernel, the core software that manages tasks and system resources. Think of a clerk removing someone from a waiting list but updating the wrong person's record: the list and the records can stop matching. This flaw involves a similar mix-up when the kernel removes a task from a lock's waiting list.

The vulnerability, CVE-2026-43499, affects the kernel's rtmutex code, which coordinates access to resources shared by different tasks. Under the affected cleanup path, the code uses the task currently executing the operation instead of the task represented by the waiting-list entry. That can leave an outdated reference behind and cause other task-management operations to use the wrong task.

The vendor's advisory identifies corrected Linux Kernel releases across several version branches. NVD published its entry on 2026-05-21 and assigns the vulnerability a HIGH severity rating. KISA, Korea's Internet & Security Agency, also published an advisory on 2026-11-03.

Technical details

NVD classifies the weakness as CWE-416, Use After Free. This means software can retain a reference to memory after that memory has been released. Accessing it later can corrupt memory because the reference no longer reliably points to a valid object. Here, the affected task's record of the lock it is waiting for can retain a dangling pointer, creating the conditions for that weakness.

The root cause is in remove_waiter(), a function that removes a waiting entry during lock handling. It also runs during rollback of a proxy-lock operation reached through futex_requeue(). A futex is a mechanism used to coordinate waiting between application code and the kernel; a proxy-lock operation handles a lock on another task's behalf. In that rollback case, the task associated with the waiting entry can differ from the task currently running the cleanup.

The affected code performs related operations using the current task. As a result, it can remove the entry without holding the waiting task's required protective lock, leave that task's blocked-on state uncleared, and adjust the priority chain using the wrong task. The correction consistently uses waiter::task, the task associated with the waiting entry. The described failure depends on reaching this proxy-lock rollback path with different current and waiting tasks; the advisory description does not establish an attacker access level, a remote entry point, or a complete exploitation method.

NVD gives CVE-2026-43499 a CVSS 3.1 score of 7.8, rated HIGH. CVSS is a standardized measure of vulnerability severity; the score is not evidence that a particular system has been attacked. CVE-2026-43499 is not listed in CISA's Known Exploited Vulnerabilities catalog as of the 2026-11-03 check date. That catalog status alone does not establish whether exploitation has occurred.

Weakness types: Memory corruption

Who is affected

Everyday users

For everyday users, the relevant question is whether a device runs an affected Linux Kernel and whether its software supplier has delivered the correction. Because the problem is in the kernel, updating an individual application does not by itself establish that the underlying flaw has been fixed.

You do not need to diagnose the lock-handling problem yourself. Follow the update steps in the vendor's advisory, then confirm that the device is running a corrected kernel. The severity rating supports giving the update attention, but it does not tell you that your device has been compromised.

Developers

Developers should distinguish an application dependency update from a kernel update. The defect sits in the Linux Kernel's handling of waiting tasks, so changing an application library does not demonstrate that the affected kernel code has been corrected. Check the running kernel on the development and deployment systems you maintain.

For developers reviewing the underlying fix, the key detail is task identity during cleanup performed on another task's behalf. A cleanup function cannot assume that the current task owns the waiting entry it receives. In this case, that assumption affects protective locking, the task's blocked-on state, and priority-chain processing.

Server and IT admins

Server and IT admins should identify affected systems and match each to the appropriate correction in the vendor's advisory. The listed fixed releases are 5.10.261, 5.15.212, 6.1.175, 6.6.140, 6.12.86, 6.18.27, 7.0.4, and 7.1, with later releases covered by the corresponding fixed-version entries.

The advisory includes overlapping affected-version ranges, including a broad entry for releases earlier than 7.1 alongside fixes for earlier branches. Read those entries together and use the vendor's guidance for the installed branch. Do not treat the broad entry as a reason to disregard a specifically listed branch correction.

What to do now

1. Identify which devices and servers run Linux Kernel versions covered by the advisory. Check the running kernel version, rather than relying only on the version of a package downloaded previously.
2. Match the installed kernel to the vendor's affected-and-fixed entry. The listed ranges are >= 2.6.39 and < 5.10.261; >= 5.15 and < 5.15.212; >= 6.1 and < 6.1.175; >= 6.6 and < 6.6.140; >= 6.12 and < 6.12.86; >= 6.18 and < 6.18.27; >= 7.0 and < 7.0.4; and earlier than 7.1.
3. Select the correction appropriate to that entry: 5.10.261 and later, 5.15.212 and later, 6.1.175 and later, 6.6.140 and later, 6.12.86 and later, 6.18.27 and later, 7.0.4 and later, or 7.1 and later. Follow the update steps in the vendor's advisory to resolve overlapping entries.
4. Apply the appropriate kernel update through your system's supported update process. Use the package-update command below only when it matches your distribution, and follow any additional steps in the vendor's advisory.
5. Complete the vendor's instructions for activating the updated kernel, including a restart if directed. Then check the running version again and record which systems have been verified.

uname -r

sudo apt update && sudo apt upgrade

sudo dnf upgrade

How to confirm the fix

• Run the kernel-version check after completing the vendor's update and activation steps. Confirm that the running kernel matches a corrected release for the applicable advisory entry.
• Confirm that the vendor's update information identifies the installed correction as addressing CVE-2026-43499. A successful package-update command alone does not establish that the corrected kernel is running.
• For managed systems, record the running kernel version and the applicable fixed-version entry so another administrator can review the result.

NVD scores and CISA KEV status

As of November 3, 2026, none of these CVEs is listed in the CISA Known Exploited Vulnerabilities catalog.

Affected products and fixed versions 8 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-43499.dyad
• NVD: CVE-2026-43499
• CISA Known Exploited Vulnerabilities catalog
• Also reported by KISA (Korea Internet & Security Agency) on November 3, 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.