In the Linux kernel, the following vulnerability has been resolved: parport: Fix race between port and client registration The parport subsystem… (CVE-2026-63942)
In the Linux kernel, the following vulnerability has been resolved: parport: Fix race between port and client registration The parport subsystem registers port devices before they are fully initialised, resulting in a race condition where client drivers such as lp can attach to ports that are not completely initialised or even being torn down. When the port and client drivers are built as modules and loaded around the same time during boot, this occasionally results in a crash. I was able to make this happen reliably in a VM with a PC-style parallel port by patching parport_pc to fail probing: > --- a/drivers/parport/parport_pc.c > +++ b/drivers/parport/parport_pc.c > @@ -2069,7 +2069,7 @@ static struct parport *__parport_pc_probe_port(unsigned long int base, > if (!p) > goto out3; > > - base_res = request_region(base, 3, p->name); > + base_res = NULL; > if (!base_res) > goto out4; > and then running: while true; do modprobe lp & modprobe parport_pc wait rmmod lp parport_pc done for a few seconds. In the long term I think port registration should be changed to put the call to device_add() inside parport_announce_port(), but since the latter currently cannot fail this will require changing all port drivers. For now, add a flag to indicate whether a port has been "announced" and only try to attach client drivers to ports when the flag is set.
AI Analysis
Technical Summary
The Linux kernel parport subsystem had a race condition where port devices were registered before being fully initialized. This allowed client drivers, such as lp, to attach to ports that were not completely ready or were being torn down, causing occasional crashes when these drivers were loaded as modules concurrently during boot. The vulnerability was demonstrated by forcing a failure in the parport_pc probe and repeatedly loading and unloading the lp and parport_pc modules, reliably causing a crash. The long-term fix involves changing port registration to call device_add() only after ports are announced, but the immediate mitigation added a flag to indicate when a port is announced, preventing client attachment before full initialization.
Potential Impact
The vulnerability can cause system instability or crashes due to a race condition in the parport subsystem when client drivers attach to incompletely initialized or torn down ports. There is no indication of code execution or privilege escalation, but the crash can affect system availability.
Mitigation Recommendations
A fix has been implemented in the Linux kernel by adding a flag to ensure client drivers only attach to ports after they have been fully announced. Users should update to the kernel version that includes this fix. Since this is a kernel subsystem issue, applying the official kernel patch or updating to a fixed kernel release is the recommended remediation. Patch status is not explicitly stated; check the vendor or kernel mailing lists for the specific fixed version.
In the Linux kernel, the following vulnerability has been resolved: parport: Fix race between port and client registration The parport subsystem… (CVE-2026-63942)
Description
In the Linux kernel, the following vulnerability has been resolved: parport: Fix race between port and client registration The parport subsystem registers port devices before they are fully initialised, resulting in a race condition where client drivers such as lp can attach to ports that are not completely initialised or even being torn down. When the port and client drivers are built as modules and loaded around the same time during boot, this occasionally results in a crash. I was able to make this happen reliably in a VM with a PC-style parallel port by patching parport_pc to fail probing: > --- a/drivers/parport/parport_pc.c > +++ b/drivers/parport/parport_pc.c > @@ -2069,7 +2069,7 @@ static struct parport *__parport_pc_probe_port(unsigned long int base, > if (!p) > goto out3; > > - base_res = request_region(base, 3, p->name); > + base_res = NULL; > if (!base_res) > goto out4; > and then running: while true; do modprobe lp & modprobe parport_pc wait rmmod lp parport_pc done for a few seconds. In the long term I think port registration should be changed to put the call to device_add() inside parport_announce_port(), but since the latter currently cannot fail this will require changing all port drivers. For now, add a flag to indicate whether a port has been "announced" and only try to attach client drivers to ports when the flag is set.
CVSS v3.1
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The Linux kernel parport subsystem had a race condition where port devices were registered before being fully initialized. This allowed client drivers, such as lp, to attach to ports that were not completely ready or were being torn down, causing occasional crashes when these drivers were loaded as modules concurrently during boot. The vulnerability was demonstrated by forcing a failure in the parport_pc probe and repeatedly loading and unloading the lp and parport_pc modules, reliably causing a crash. The long-term fix involves changing port registration to call device_add() only after ports are announced, but the immediate mitigation added a flag to indicate when a port is announced, preventing client attachment before full initialization.
Potential Impact
The vulnerability can cause system instability or crashes due to a race condition in the parport subsystem when client drivers attach to incompletely initialized or torn down ports. There is no indication of code execution or privilege escalation, but the crash can affect system availability.
Mitigation Recommendations
A fix has been implemented in the Linux kernel by adding a flag to ensure client drivers only attach to ports after they have been fully announced. Users should update to the kernel version that includes this fix. Since this is a kernel subsystem issue, applying the official kernel patch or updating to a fixed kernel release is the recommended remediation. Patch status is not explicitly stated; check the vendor or kernel mailing lists for the specific fixed version.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-g8r4-rq83-8vj2
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-63942"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a5d27aa2a4a8d598912e8b7
Added to database: 07/19/2026, 19:38:18 UTC
Last enriched: 07/19/2026, 20:05:02 UTC
Last updated: 07/20/2026, 21:52:11 UTC
Views: 12
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.