CVE-2026-53336

What it actually does

This is a Linux kernel denial-of-service flaw in the ONIE TLV NVMEM layout parser. When the parser encounters an unknown or vendor-specific TLV entry type, it can fail to advance its parsing offset and enter an endless loop. Systems that parse affected EEPROM/NVMEM data may hang during device initialization, hardware probing, boot, or runtime access to the relevant NVMEM layout. The issue requires the system to process malformed or unexpected ONIE TLV EEPROM contents; it is not generally a remote code execution vulnerability.

Why it matters to the business

Affected systems may become unavailable or fail to boot if they process EEPROM data containing an unknown TLV type. The practical risk is highest for appliances, switches, embedded Linux platforms, white-box networking devices, and hardware-management environments that rely on ONIE-formatted EEPROM data. EPSS is very low and there is no known KEV listing or ransomware association, so broad exploitation is not currently indicated, but the impact can still be operationally serious where affected hardware must remain continuously available.

How an attack unfolds

An attacker would need a way to influence the ONIE TLV EEPROM/NVMEM contents seen by the Linux kernel, such as supply-chain manipulation, malicious or faulty hardware, privileged local access capable of writing EEPROM data, compromised firmware tooling, or a virtualized/emulated hardware path that presents crafted NVMEM contents. The attacker adds an unknown vendor-specific TLV entry type. When the affected kernel driver parses the ONIE TLV layout, it encounters the unknown type and fails to move to the next entry, causing an infinite loop. This can hang the kernel path responsible for probing or reading the NVMEM layout, potentially stalling boot, locking up a device, or making the platform unavailable until the malformed data is removed or the kernel is updated.

How to fix it

Update to a Linux kernel build that includes the ONIE TLV NVMEM parser fix, where unknown TLV entries are skipped by advancing the parsing offset. If using a distribution or appliance vendor kernel, apply the vendor-provided kernel security or stability update when available. If building kernels directly, incorporate the upstream fix for the nvmem layouts onie-tlv parser. As mitigations, restrict write access to EEPROM/NVMEM contents, validate ONIE TLV EEPROM data before deployment, avoid untrusted hardware images or emulator-provided EEPROM data, and replace or reprogram EEPROM contents that contain malformed entries causing hangs.

How to confirm the fix worked

Confirm that the running kernel package or source tree includes the fix that advances the ONIE TLV parsing offset for unknown entry types. Validate by reviewing vendor kernel advisories, package changelogs, or the relevant nvmem/layouts/onie-tlv driver code. On representative hardware, verify that systems with vendor-specific ONIE TLV entries boot normally and that reading the NVMEM layout no longer causes hangs. For exposure checks, identify Linux systems using ONIE TLV EEPROM/NVMEM parsing, especially embedded, appliance, and network-platform kernels, and compare their kernel versions against fixed vendor releases.

Typical attack path

1. Gain the ability to modify, emulate, or supply ONIE TLV EEPROM/NVMEM data to a Linux system.
2. Insert a vendor-specific or otherwise unknown TLV entry type into the EEPROM data.
3. Cause the affected Linux kernel to parse the ONIE TLV layout, commonly during boot, device probing, or NVMEM access.
4. Trigger the parser logic that does not advance the offset when the unknown type is encountered.
5. Induce an endless loop that can hang the kernel path and result in device unavailability or boot failure.

How to detect it

Evidence of exploitation is likely to be sparse because the primary symptom is a kernel hang rather than a clean application-level event. Review kernel logs, boot logs, serial console captures, BMC/IPMI event logs, crash dumps, pstore/ramoops records, and hardware provisioning logs for hangs or watchdog resets that occur while probing NVMEM, EEPROM, ONIE, or platform identity data. Look for repeated boot loops, soft lockups, RCU stalls, or watchdog resets following hardware replacement, EEPROM reprogramming, firmware updates, or use of virtual/emulated hardware. If EEPROM dumps are available, inspect ONIE TLV data for unknown or vendor-specific entry types, especially entries observed immediately before a hang. Differentiate malicious exploitation from benign faulty EEPROM data, as accidental vendor-specific TLV entries can trigger the same behavior.

• onie-tlv
• nvmem
• EEPROM
• ONIE TLV
• watchdog: BUG: soft lockup
• BUG: soft lockup
• rcu_sched detected stalls
• rcu_preempt detected stalls
• INFO: rcu detected stalls
• NMI watchdog: Watchdog detected hard LOCKUP
• hard LOCKUP
• soft lockup
• type 0x41

What your security team should do

• Prioritize patching Linux-based appliances, embedded platforms, and network devices that use ONIE TLV EEPROM/NVMEM data.
• Ask hardware, appliance, and OS vendors for the kernel build or advisory that contains the ONIE TLV unknown-type parsing fix.
• Restrict EEPROM/NVMEM write capabilities to trusted maintenance workflows and privileged administrators only.
• Validate EEPROM contents during provisioning and RMA processes, especially for devices sourced from third parties or repaired hardware pools.
• Monitor boot failures, kernel soft lockups, and hangs on systems that recently received new hardware, firmware, or EEPROM updates.
• Because there is no KEV listing, no known ransomware use, and very low EPSS, treat this as targeted operational-risk remediation rather than an internet-wide emergency unless affected platforms are business-critical.