CVE-2026-63942: Linux kernel · parport: Fix race between port and client registration
Affects Linux kernelSource CVE Database V5
Not known to be exploited · CVSS 7.8 High · fixed in f3378b0d7bd4605de89b083b2900788157a181cc : patch Linux kernel soon.
Data as of 26 Oct 2026, 17:30 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 2% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- CISA SSVC
- Exploitation
- No evidence of active exploitation and no public proof of concept
- Automatable
- Attackers cannot reliably automate steps 1–4 of the kill chain
- Technical impact
- Total control over the software or total information disclosure
CISA SSVC assessment, 2026-10-16.
- Patch
- Available – fixed in f3378b0d7bd4605de89b083b2900788157a181cc, ef15ccbb3e8640a723c42ad90eaf81d66ae02017, d16548be2ea5058227d79799e81dab61c9bca8ec +5
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:HExploitation evidence
Disclosed: evidence found.
CVE published 19 Jul 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade to a fixed release listed under Affected software.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
| LinuxLinux | Affected
| Fixed in
|
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.
References
- git.kernel.org/stable/c/f3378b0d7bd4605de89b083b2900788157a181cc (opens in a new tab)
- git.kernel.org/stable/c/290f515c5e3b3900bc2fe24f179999fd08d23bfa (opens in a new tab)
- git.kernel.org/stable/c/d16548be2ea5058227d79799e81dab61c9bca8ec (opens in a new tab)
- git.kernel.org/stable/c/15b1723c1472e802f9f7e69ae4e64f7dbf588848 (opens in a new tab)
- git.kernel.org/stable/c/51026cff1f4f3b762a0b5a07c727bd59cef45320 (opens in a new tab)
- git.kernel.org/stable/c/74d6aae1df45d3414178986be743f946988fddf6 (opens in a new tab)
- git.kernel.org/stable/c/a1e81b58da0179531bedf0b9f2811f5f992d5c4b (opens in a new tab)
- git.kernel.org/stable/c/ef15ccbb3e8640a723c42ad90eaf81d66ae02017 (opens in a new tab)