CVE-2026-53238

What it actually does

This is an improper input validation flaw in the Linux kernel NetLabel Generic Netlink interface. The vulnerable code validates the length of the supplied unlabeled IPv4 or IPv6 address attribute, but does not independently require the corresponding mask attribute to be exactly the size of a struct in_addr or struct in6_addr. A crafted Generic Netlink message can therefore pass policy validation with a valid address attribute and an undersized mask attribute, causing the kernel to read beyond the provided mask attribute data. The most likely technical outcomes are kernel out-of-bounds read, kernel warning/oops, denial of service, or potentially use of unintended adjacent data during NetLabel configuration handling. Exploitation generally requires local access with permission to issue the relevant NetLabel Generic Netlink operation, typically CAP_NET_ADMIN or equivalent administrative network capability.

Why it matters to the business

Successful exploitation could destabilize Linux systems that expose NetLabel management functionality to local users, containers, or services with elevated network administration privileges. The main operational risk is system crash or service disruption on affected hosts. Because EPSS is very low, the issue is not in CISA KEV, and no mature public exploitation is indicated, this is currently a lower-urgency kernel-hardening issue unless untrusted users or containers are granted CAP_NET_ADMIN or similar privileges. Organizations with multi-tenant Linux workloads, container platforms, SELinux/MLS deployments, or environments using NetLabel should prioritize remediation more highly.

How an attack unfolds

An attacker first needs a local execution context capable of sending the affected NetLabel Generic Netlink request, commonly through CAP_NET_ADMIN or another path that permits NetLabel configuration. The attacker crafts a Netlink message for unlabeled NetLabel address handling where the IPv4 or IPv6 address attribute has a valid length, but the paired mask attribute is shorter than the kernel later assumes. On vulnerable kernels, the Netlink attribute policy treats binary lengths as maximum lengths rather than exact lengths, so the malformed mask may pass validation. When netlbl_unlabel_addrinfo_get() processes the request, it reads the mask as a full IPv4 or IPv6 address-sized structure, producing an out-of-bounds read from adjacent Netlink message memory. Depending on memory layout and kernel configuration, this may cause a kernel diagnostic, oops, panic, denial of service, or incorrect NetLabel rule processing.

How to fix it

Upgrade to a kernel version or vendor backport that includes the NetLabel fix enforcing exact lengths for unlabeled IPv4/IPv6 address and mask attributes using exact-length Netlink attribute policy validation. No specific fixed package versions were provided in the input, so use the applicable Linux distribution, appliance, cloud image, or kernel vendor advisory for the precise patched version. Where immediate patching is not possible, reduce exposure by limiting CAP_NET_ADMIN and similar network-administration capabilities, especially in containers and multi-user systems; avoid granting privileged containers access to host network administration; restrict local shell access to trusted administrators; and monitor for kernel warnings or oopses involving NetLabel or netlbl_unlabel_addrinfo_get(). Mitigations should be treated as risk reduction, not a substitute for applying the kernel fix.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package contains the NetLabel patch that changes the unlabeled IPv4/IPv6 address and mask Netlink policies to exact-length validation. Validate against the vendor advisory or source tree rather than relying only on upstream version numbers, because distributions often backport kernel fixes. On source-based validation, look for NLA_POLICY_EXACT_LEN() or equivalent exact-length checks for the unlabeled IPv4/IPv6 address and mask attributes in the NetLabel policy. Operationally, a malformed Generic Netlink request with a short mask attribute should be rejected during policy validation and must not produce a kernel warning, KASAN report, oops, panic, or NetLabel rule change. Also confirm that untrusted workloads do not retain CAP_NET_ADMIN unless explicitly required.

Typical attack path

1. Gain local code execution on a Linux host or inside a container with sufficient network administration capability, typically CAP_NET_ADMIN.
2. Open a Generic Netlink socket and resolve or target the NetLabel family and unlabeled address-management operation.
3. Build a malformed NetLabel unlabeled address request with a correctly sized IPv4 or IPv6 address attribute and an intentionally undersized mask attribute.
4. Send the crafted Generic Netlink request to the kernel.
5. Trigger netlbl_unlabel_addrinfo_get() to read the short mask attribute as a full IPv4 or IPv6 mask structure.
6. Observe the result, such as request failure, kernel warning, kernel oops, panic, host instability, or unexpected NetLabel configuration behavior.

How to detect it

To determine whether exploitation may already have occurred, review kernel and system logs for crashes or memory-safety diagnostics involving NetLabel, Generic Netlink, or netlbl_unlabel_addrinfo_get(). Useful sources include journalctl, /var/log/kern.log, /var/log/messages, dmesg output, crash dumps, kdump/vmcore artifacts, auditd logs for processes with CAP_NET_ADMIN, container runtime logs for privileged or NET_ADMIN-enabled containers, and EDR telemetry showing local processes opening NETLINK_GENERIC sockets shortly before a kernel warning or crash. Because this vulnerability is triggered through crafted Netlink messages rather than a remote network packet, network IDS is unlikely to provide reliable visibility. Stronger detection requires host telemetry: audit suspicious use of CAP_NET_ADMIN, unexpected NetLabel management activity, and kernel oops/panic events. There are no public threat actors or ransomware campaigns associated with this issue in the provided data.

• netlbl_unlabel_addrinfo_get
• NetLabel
• netlabel
• NETLINK_GENERIC
• Generic Netlink
• BUG: KASAN
• BUG: KASAN: slab-out-of-bounds
• BUG: KASAN: out-of-bounds
• kernel BUG
• Oops:
• general protection fault
• panic: Fatal exception
• NET_ADMIN
• CAP_NET_ADMIN

What your security team should do

• Inventory Linux kernels in use and identify systems running kernels without the NetLabel exact-length attribute validation fix.
• Prioritize patching hosts that run untrusted local workloads, containers, CI jobs, shared-user environments, SELinux/MLS configurations, or services granted CAP_NET_ADMIN.
• Remove CAP_NET_ADMIN and privileged-container permissions from workloads that do not strictly require them.
• Review container runtime, Kubernetes, systemd, and sudo policies for unnecessary network-administration capability delegation.
• Monitor kernel logs for NetLabel-related warnings, oopses, KASAN findings, or panics involving netlbl_unlabel_addrinfo_get().
• If suspicious crashes are observed, preserve kernel logs, audit records, container metadata, and recent process execution history before reboot cleanup or log rotation.
• Treat this as lower urgent than actively exploited KEV items, but include it in normal kernel patch cycles because local kernel bugs can become useful in chained attacks.