CVE-2026-43197

What it actually does

This is a Linux kernel out-of-bounds read in the netconsole driver. The console subsystem can pass a message buffer that is not NUL-terminated, but netconsole treats it like a C string during formatting, allowing the kernel to read beyond the allocated message buffer. The likely impacts are disclosure of adjacent kernel memory through netconsole output and kernel instability or panic when memory debugging or fault conditions are triggered. The vulnerability affects confidentiality and availability; it does not directly imply arbitrary code execution or data modification.

Why it matters to the business

Systems that use Linux netconsole for remote kernel logging could leak sensitive kernel memory into remote log streams or experience crashes when handling console output. This is operationally important for infrastructure teams because affected hosts may include production servers, appliances, hypervisors, or embedded Linux systems where kernel logging is enabled for troubleshooting or crash recovery. Although the CVSS score is high, the available exploitation signal is currently low: EPSS is approximately 0.0048 with no 30-day increase, it is not listed in CISA KEV, is not known to be used in ransomware campaigns, and no public exploit maturity is reported. Organizations should still prioritize remediation for internet-facing, high-availability, or sensitive Linux systems where netconsole is enabled.

How an attack unfolds

An attacker first needs a path to make an affected Linux system emit kernel console messages that are processed by netconsole. In exposed scenarios, this may be possible by sending traffic or inputs that cause kernel subsystems or drivers to log messages. When netconsole handles a message buffer that lacks a terminating NUL byte, it formats the message as though it were a normal string and reads past the intended buffer boundary. The extra bytes may be transmitted to the configured netconsole receiver, resulting in unintended kernel memory disclosure, or the read may trigger a kernel fault, KASAN report, panic, or service disruption. Exploitation is most relevant where netconsole is loaded and configured; systems without netconsole enabled have significantly reduced practical exposure.

How to fix it

Apply the Linux kernel update from the relevant distribution or vendor that includes the fix for netconsole handling of non-NUL-terminated console messages. No exact fixed package versions were provided in the input, so use vendor advisories, kernel changelogs, or stable kernel release notes to confirm inclusion of the patch titled or described as "netconsole: avoid OOB reads, msg is not nul-terminated." Where immediate patching is not possible, disable netconsole if it is not operationally required, unload or prevent loading of the netconsole module, remove netconsole boot parameters, and restrict egress access to configured netconsole collectors. Treat netconsole traffic as sensitive because it may contain kernel diagnostics and potentially memory-adjacent data.

How to confirm the fix worked

Confirm remediation by verifying the running kernel version and vendor package changelog include the netconsole fix. Check whether netconsole is active by reviewing loaded modules, kernel command-line parameters, and configfs/sysfs netconsole configuration. Validate that no active netconsole targets remain unless explicitly required. Review kernel logs after patching for absence of KASAN, slab-out-of-bounds, or netconsole_write stack traces under normal logging conditions. If kernel self-testing is available in a non-production environment, run relevant console/netconsole regression tests against the patched kernel and confirm no out-of-bounds read is reported.

Typical attack path

1. Identify or infer that a target Linux system has netconsole enabled or is sending remote kernel logs.
2. Find an input path that causes the kernel to emit console messages, such as malformed network traffic, driver errors, subsystem warnings, or other externally triggerable printk output.
3. Repeatedly trigger kernel log messages likely to be handled by the netconsole path.
4. Abuse the missing NUL-termination handling so netconsole reads past the end of the intended message buffer.
5. Collect leaked data from the netconsole receiver if the attacker can observe that traffic, or induce kernel instability resulting in denial of service.
6. Use any disclosed memory contents to support follow-on attacks, reconnaissance, or credential/material exposure if sensitive data is present in adjacent memory.

How to detect it

To determine whether this was already triggered, review kernel logs, system journals, crash dumps, panic reports, and netconsole receiver logs. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, pstore, kdump/vmcore artifacts, distribution crash reporting, and logs stored on remote netconsole collectors. Look for KASAN or slab-out-of-bounds reports with stack traces containing netconsole_write, scnprintf, vsnprintf, string, nbcon_emit_next_record, or nbcon_kthread_func. Also investigate unexpected host instability, kernel panics, or repeated console logging bursts that coincide with inbound network traffic or device/subsystem errors. Network detection should focus on unauthorized or unusual outbound UDP traffic from Linux hosts to netconsole collectors, commonly on configured netconsole ports, and on netconsole payloads containing data that appears unrelated to normal kernel messages. There are no known threat actors or public exploit campaigns associated with this issue in the supplied data, so detection should focus on crash artifacts, anomalous netconsole output, and exposure evidence rather than actor-specific indicators.

• BUG: KASAN: slab-out-of-bounds in string
• slab-out-of-bounds in string+0x
• Read of size 1 at addr
• netconsole_write+0x
• scnprintf+0x
• vsnprintf+0x
• nbcon_emit_next_record+0x
• nbcon_kthread_func+0x
• printk: console [netcon_ext0] enabled
• pr/netcon_ext0
• netcon_ext0
• /sys/module/netconsole
• /sys/kernel/config/netconsole
• netconsole=

What your security team should do

• Inventory Linux systems that have netconsole enabled or configured through boot parameters, modules, sysfs, or configfs.
• Prioritize patching systems where netconsole is enabled, where kernel logs are transmitted over a network, or where uptime and confidentiality requirements are high.
• If patching is delayed, disable netconsole or tightly restrict network paths between hosts and authorized netconsole collectors.
• Monitor kernel logs and crash reports for KASAN slab-out-of-bounds findings involving string, vsnprintf, scnprintf, or netconsole_write.
• Treat netconsole collectors as sensitive log repositories and review their access controls, retention, and exposure.
• Hunt for unexpected outbound UDP netconsole traffic, especially to unapproved collectors or external destinations.
• Track vendor kernel advisories because exact fixed versions vary by distribution and no universal fixed version was provided.
• Maintain urgency proportional to exposure: despite low EPSS, no KEV listing, and no known public exploit, enabled netconsole on critical systems increases practical risk.