CVE-2026-63942

What it actually does

This is a race condition in the Linux kernel parport subsystem. Parallel port devices can be registered before they are fully initialized, allowing client drivers such as lp to attach to a port while initialization is incomplete or while teardown is occurring. Under the right timing, especially when parport-related drivers are loaded or unloaded concurrently, the kernel can dereference inconsistent or partially initialized state and crash. The CVSS rating indicates potential high confidentiality, integrity, and availability impact, but the public description primarily demonstrates reliable local kernel crash behavior rather than a confirmed remote exploitation path.

Why it matters to the business

Systems running affected Linux kernels may experience unexpected crashes or instability if parport and related client modules are loaded during a vulnerable timing window. For organizations using Linux servers, appliances, virtual machines, or embedded systems where parallel port support is present, the main operational risk is local denial of service and service interruption. Because exploitation requires local access or the ability to influence kernel module loading, this is most urgent for multi-user systems, shared compute environments, developer workstations, and hosts where untrusted users can trigger hardware driver autoloading. The issue is not currently listed in CISA KEV, has no known ransomware association, and has a low EPSS score, so broad internet-scale exploitation is unlikely based on currently available data.

How an attack unfolds

An attacker first needs local access to a Linux system running an affected kernel and a configuration where parport-related modules are available, such as parport_pc and lp. The attacker then attempts to create a timing race by causing the parallel port driver and a client driver to load or unload around the same time. If the client driver attaches while the port object is not fully initialized, or while it is being torn down after a failed probe, the kernel may access invalid or incomplete state. Successful exploitation is expected to manifest as a kernel oops, panic, or system crash. In the public proof scenario, the race was triggered by repeatedly running concurrent modprobe operations for lp and parport_pc followed by rmmod operations.

How to fix it

Upgrade to a Linux kernel version that includes the parport fix introducing safe registration behavior so client drivers only attach to ports after they have been fully announced. Because no exact fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor advisory once available. Where immediate patching is not possible, reduce exposure by disabling or blacklisting unused parport-related modules such as lp, parport, and parport_pc, especially on systems that do not require parallel port functionality. Restrict local shell access and administrative capabilities that allow loading or unloading kernel modules. Ensure kernel module loading is controlled through standard privilege boundaries and that untrusted users cannot trigger unnecessary hardware-driver autoloading.

How to confirm the fix worked

Confirm the running kernel version includes the vendor fix for the parport registration race. Validate that the installed kernel package matches the distribution's patched release, then reboot into the patched kernel and verify with uname and package manager metadata. If parallel port support is not required, confirm parport-related modules are not loaded and are blocked from autoloading. On test systems only, administrators can validate mitigation by attempting repeated concurrent load and unload cycles of lp and parport_pc and confirming the system remains stable; this should not be performed on production systems because the vulnerable behavior can crash the host.

Typical attack path

1. Gain local access to a Linux system running an affected kernel.
2. Confirm parport-related kernel modules are present, such as lp, parport, or parport_pc.
3. Trigger concurrent or repeated loading of parport client and port drivers.
4. Race client driver attachment against incomplete port initialization or teardown.
5. Cause a kernel oops, panic, or crash, resulting in denial of service and possible reboot.

How to detect it

Look for evidence of local attempts to repeatedly load or unload parport-related modules and for kernel crash artifacts referencing parport, parport_pc, or lp. Useful sources include systemd journal logs, /var/log/kern.log, /var/log/messages, auditd logs, sudo logs, shell history where available, kernel crash dumps, kdump/vmcore artifacts, and EDR telemetry for modprobe or rmmod execution. Investigate kernel oops or panic events that occur near module load/unload activity. Pay particular attention to repeated or scripted sequences involving concurrent modprobe lp and modprobe parport_pc commands followed by rmmod. Because exploitation may leave only crash evidence, absence of a persistent file artifact does not rule out attempted exploitation.

• modprobe lp
• modprobe parport_pc
• rmmod lp parport_pc
• rmmod parport_pc
• rmmod lp
• parport_pc
• parport
• lp
• kernel: Oops
• kernel: panic
• kernel panic
• BUG: unable to handle kernel
• Unable to handle kernel NULL pointer dereference
• parport_pc: probe
• parport: Fix race between port and client registration
• /var/crash
• /var/lib/systemd/coredump
• /proc/modules

What your security team should do

• Prioritize patching Linux systems where untrusted local users have shell access or where workloads can influence kernel module loading.
• Inventory systems with parport-related modules loaded or available, especially lp, parport, and parport_pc.
• Disable or blacklist parallel port modules on servers and virtual machines that do not need them.
• Monitor for kernel oops, panic, or crash events mentioning parport, parport_pc, or lp.
• Review sudoers, container runtime, and workload policies to ensure untrusted users cannot load or unload kernel modules.
• Track distribution advisories for the exact fixed kernel package versions and ensure systems reboot into the patched kernel after upgrade.