CVE-2026-43085
Medium · 5.5CVSS
5.5
EPSS
0.1%
Published
May 6, 2026
CISA due date
—
Cloudanix analysis
A local user on an affected Linux system may be able to read tiny fragments of sensitive system memory, so the system should be updated through the normal kernel patch process.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- Low
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Information Disclosure
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
A Linux kernel netfilter NFLOG batching bug can copy four bytes of uninitialized kernel heap memory into the NLMSG_DONE terminator returned to userspace. The issue occurs when multiple NFLOG messages are batched and the nfgenmsg payload in the terminating netlink message is allocated but not initialized. An attacker with local access and sufficient permission to interact with NFLOG/netfilter logging paths may be able to repeatedly trigger the condition to disclose small fragments of stale kernel heap data. The direct impact is limited information disclosure; however, kernel memory disclosures can sometimes assist bypasses of kernel hardening when chained with other local vulnerabilities.
Why it matters to the business
The primary business risk is exposure of small amounts of kernel memory on affected Linux systems, which could aid a local attacker attempting to escalate privileges or develop a more reliable exploit chain. Because exploitation requires local access and relevant netfilter/NFLOG interaction, the likelihood of broad remote compromise is low. The CVE is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported public exploit maturity, and has a very low, flat EPSS score, so remediation should be handled through normal kernel patch cycles unless the systems are multi-user, container-dense, or allow untrusted workloads.
How an attack unfolds
An attacker first obtains local code execution on an affected Linux host, such as through a shell, compromised user account, container escape-adjacent foothold, or malicious local workload. They then interact with the netfilter NFLOG subsystem in a way that causes multiple log messages to be batched. When the kernel emits the batched netlink response, it appends an NLMSG_DONE message containing an nfgenmsg-sized payload. Due to the flaw, that payload contains stale heap bytes rather than initialized data. The attacker reads the returned netlink messages from userspace and extracts the leaked bytes. By repeating the operation, they may gather small memory fragments that could potentially reveal kernel heap contents useful for further exploitation, although there are no known public exploits or active exploitation reports for this issue.
How to fix it
Upgrade to a Linux kernel build that includes the upstream fix for nfnetlink_log NLMSG_DONE initialization. The fix changes the terminator construction to use the netfilter netlink helper that initializes the nfgenmsg payload before sending it to userspace. No exact fixed package versions were provided in the input, so use the kernel versions supplied by the relevant Linux distribution or vendor security advisory. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting CAP_NET_ADMIN and equivalent network administration privileges, avoiding untrusted workloads on shared hosts, disabling unnecessary NFLOG usage, and applying container/user-namespace hardening where applicable. Reboot into the patched kernel after installation; merely installing kernel packages without booting the fixed kernel does not remediate a running system.
How to confirm the fix worked
Confirm that the running kernel, not only the installed kernel package, is from a vendor build containing the nfnetlink_log fix. Validate with distribution tooling such as uname -r, package manager version checks, and vendor advisory mapping for the running kernel release. If source-based validation is available, verify that nfnetlink_log constructs the NLMSG_DONE terminator through the initialized netfilter netlink header path rather than leaving the nfgenmsg payload uninitialized. Operationally, review whether NFLOG is enabled or used by firewall rules, IDS/IPS integrations, or packet logging services. Exposure is reduced when untrusted local users and workloads cannot access netfilter/NFLOG functionality or obtain network administration capabilities.
Typical attack path
- Gain local execution on an affected Linux system.
- Obtain or already possess the permissions needed to configure or consume NFLOG/netfilter netlink logging, commonly associated with network administration capabilities.
- Configure or trigger NFLOG activity that produces batched messages with a queue length greater than one.
- Read the netlink NFLOG response stream from userspace.
- Inspect NLMSG_DONE terminator payloads for four bytes of stale kernel heap data.
- Repeat the trigger/read cycle to collect additional leaked fragments and use them, if useful, to support a separate local exploit chain.
How to detect it
There are no reliable, CVE-specific post-exploitation artifacts because the flaw leaks data through legitimate netlink message handling and may not produce kernel warnings or authentication logs. To investigate possible prior exploitation, review auditd, eBPF, EDR, sysmon-for-Linux, shell history, process accounting, and container runtime logs for unexpected local processes interacting with netfilter, NFLOG, iptables, nftables, or CAP_NET_ADMIN-enabled containers. Focus on sensitive multi-user or container hosts and correlate unusual NFLOG configuration changes, repeated netlink/netfilter activity, unexpected packet logging rules, and short-lived custom binaries run by non-administrative users. Useful log sources include audit logs for execution of iptables, ip6tables, nft, modprobe, insmod, rmmod, capsh, unshare, nsenter, setcap, and container launches granting NET_ADMIN; kernel logs for nfnetlink_log module loading; and container orchestrator audit logs for workloads requesting NET_ADMIN or privileged mode. Absence of these events does not prove non-exploitation, as a custom program can interact with netlink directly without invoking standard command-line tools.
What your security team should do
- Prioritize patching multi-user Linux systems, container hosts, CI/CD runners, shared compute platforms, and systems that run untrusted local workloads.
- Update affected Linux kernel packages using vendor-supported releases and reboot to ensure the fixed kernel is active.
- Inventory use of NFLOG/netfilter logging and determine where local processes have CAP_NET_ADMIN or comparable network administration privileges.
- Restrict CAP_NET_ADMIN in containers and service units unless explicitly required.
- Monitor for unusual local netfilter/NFLOG activity on sensitive hosts, especially from unexpected users, containers, or short-lived processes.
- Treat this as a lower-likelihood standalone issue but a useful hardening patch because kernel memory disclosure can increase the reliability of other local exploits.
- Track vendor advisories for exact fixed kernel versions because no per-package fixed versions were provided.
The record
In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator When batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send() appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload via nlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put() helper only zeroes alignment padding after the payload, not the payload itself, so four bytes of stale kernel heap data are leaked to userspace in the NLMSG_DONE message body. Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializes the nfgenmsg payload via nfnl_fill_hdr(), consistent with how __build_packet_message() already constructs NFULNL_MSG_PACKET headers.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|