Cloudanix VulnDB

CVE-2026-99211

None

CVSS

—

EPSS

0.2%

Published

Oct 28, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in how the Linux kernel handles certain internal network messages could allow a regular user to see small pieces of private system memory that should remain hidden.

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

Socket filters attached to netlink sockets can read uninitialized headroom bytes (via SKF_NET_OFF/SKF_LL_OFF) in unicast and multicast deliveries because producers such as IWPM may allocate skbs with dev_alloc_skb without resetting network and MAC header pointers.

Why it matters to the business

Local unprivileged users can leak small amounts of kernel memory on affected Linux systems; while the disclosure is limited, the issue is present in a core networking component used by many services and was published only one day ago.

How an attack unfolds

An attacker creates a netlink socket (e.g., NETLINK_RDMA), attaches a classic BPF filter that reads offsets before the message payload, triggers a netlink producer that sends a separately allocated skb (such as an IWPM HELLO reply), and observes the leaked headroom bytes returned through the filter.

How to fix it

Upgrade the Linux kernel to a version containing the upstream fix that resets skb network and MAC headers before unicast and multicast filtering in netlink.

How to confirm the fix worked

Confirm the presence of the reset logic for both unicast and broadcast paths in netlink_unicast and netlink_broadcast; test that a filter reading SKF_NET_OFF no longer returns headroom data on affected netlink families.

Typical attack path

  1. Create netlink socket with appropriate protocol
  2. Attach a classic socket filter using SKF_NET_OFF or SKF_LL_OFF reads
  3. Trigger a netlink message from a producer that reserves headroom without resetting headers (e.g., IWPM HELLO via netlink_unicast)
  4. Receive the filtered skb and extract disclosed bytes from the headroom region

How to detect it

Review process creation and netlink socket/filter attachment events in audit logs or eBPF traces for unusual use of NETLINK_RDMA or similar families; examine any user-space code that attaches classic BPF filters to netlink sockets.

What your security team should do

  • Prioritize kernel updates on any system exposing netlink sockets to untrusted local users
  • Monitor upstream stable and distribution kernel releases for the backported patch
  • Restrict unprivileged access to netlink families where feasible until patched

The record

In the Linux kernel, the following vulnerability has been resolved: netlink: reset skb headers before unicast and multicast filtering Socket filters can use SKF_NET_OFF and SKF_LL_OFF to read relative to an skb's network and MAC headers. Netlink producers may reserve headroom without resetting those headers, allowing a receiving socket's filter to read data before the initialized message. For example, IWPM HELLO replies are allocated with dev_alloc_skb(), which reserves NET_SKB_PAD bytes. An unprivileged NETLINK_RDMA user can attach a classic socket filter and disclose this headroom through the length of the delivered reply. The resets in netlink_dump() do not help because IWPM sends a separately allocated skb through netlink_unicast(). Reset both headers before running the receiver's filter in unicast and broadcast delivery, as is already done for dump skbs. This also covers other netlink producers that reserve headroom without changing their allocation or message-building code.

Affected packages

Ecosystem Package Introduced Fixed