CVE-2026-68288
NoneCVSS
—
EPSS
0.2%
Published
Aug 10, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel's network monitoring feature can accidentally send small pieces of internal memory to programs running on the same computer.
- Exploitation
- Local Privilege
- Attacker needs
- Low Privilege
- Complexity
- Low
- Impact
- Data Exposure
- Component
- OS kernel
- Class
- Information Disclosure
- Remediation
- Upgrade
- Effort
- Medium
- Patch risk
- Low
What it actually does
Uninitialized padding bytes (1-3) after skb payload in net_dm_packet_report_fill and net_dm_hw_packet_report_fill are leaked into NET_DM_ATTR_PAYLOAD netlink attributes when payload length is not 4-byte aligned.
Why it matters to the business
Unprivileged local users may obtain fragments of kernel memory containing sensitive data such as pointers or packet contents, increasing risk of further attacks on kernel subsystems.
How an attack unfolds
An attacker on the system crafts or triggers network traffic that causes drop_monitor to generate reports with non-4-byte-aligned payloads; the resulting netlink messages returned to user space contain uninitialized padding bytes that can be read from the received buffer.
How to fix it
Upgrade the Linux kernel to a version containing the commit that replaces open-coded attribute construction with __nla_reserve to ensure padding is zeroed.
How to confirm the fix worked
Confirm the presence of the fix by inspecting the net_dm_packet_report_fill and net_dm_hw_packet_report_fill functions for use of __nla_reserve, or run KMSAN on workloads that generate non-aligned payloads and verify no info-leak reports occur.
Typical attack path
- Obtain local unprivileged access on a Linux system using the vulnerable drop_monitor code path
- Trigger software or hardware packet drop events that invoke net_dm_packet_work or equivalent
- Receive netlink messages containing NET_DM_ATTR_PAYLOAD with non-aligned lengths
- Parse the received buffer to extract the 1-3 uninitialized padding bytes
How to detect it
Review netlink recvmsg logs or packet capture for drop_monitor messages; look for KMSAN reports mentioning kernel-infoleak in _copy_to_iter originating from net_dm_packet_work when payload lengths are not multiples of 4.
What your security team should do
- Prioritize kernel updates on all systems exposing drop_monitor netlink interfaces to untrusted local users
- Restrict access to NET_DM netlink sockets via LSM or capabilities where possible until patched
- Monitor EPSS and KEV status for any future increase in exploit maturity
The record
In the Linux kernel, the following vulnerability has been resolved: net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|