parport: Fix race between port and client registration
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
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.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Linux Linux
From 6fa45a22689722dac9f0e90c0931d4b34b334ede · fixed in f3378b0d7bd4605de89b083b2900788157a181cc; From 6fa45a22689722dac9f0e90c0931d4b34b334ede · fixed in 290f515c5e3b3900bc2fe24f179999fd08d23bfa; From 6fa45a22689722dac9f0e90c0931d4b34b334ede · fixed in d16548be2ea5058227d79799e81dab61c9bca8ec; From 6fa45a22689722dac9f0e90c0931d4b34b334ede · fixed in 15b1723c1472e802f9f7e69ae4e64f7dbf588848; From 6fa45a22689722dac9f0e90c0931d4b34b334ede · fixed in 51026cff1f4f3b762a0b5a07c727bd59cef45320; From 6fa45a22689722dac9f0e90c0931d4b34b334ede · fixed in 74d6aae1df45d3414178986be743f946988fddf6; From 6fa45a22689722dac9f0e90c0931d4b34b334ede · fixed in a1e81b58da0179531bedf0b9f2811f5f992d5c4b; From 6fa45a22689722dac9f0e90c0931d4b34b334ede · fixed in ef15ccbb3e8640a723c42ad90eaf81d66ae02017
- Linux Linux
4.2
- KernelLinux
From 4.2.0 · fixed in 5.10.259; From 5.11.0 · fixed in 5.15.210; From 5.16.0 · fixed in 6.1.176; From 6.2.0 · fixed in 6.6.143; From 6.7.0 · fixed in 6.12.93; From 6.13.0 · fixed in 6.18.35; From 6.19.0 · fixed in 7.0.12
References 8
git.kernel.org
- stable/c/f3378b0d7bd4605de89b083b2900788157a181cc
- stable/c/290f515c5e3b3900bc2fe24f179999fd08d23bfa
- stable/c/d16548be2ea5058227d79799e81dab61c9bca8ec
- stable/c/15b1723c1472e802f9f7e69ae4e64f7dbf588848
- stable/c/51026cff1f4f3b762a0b5a07c727bd59cef45320
- stable/c/74d6aae1df45d3414178986be743f946988fddf6
- stable/c/a1e81b58da0179531bedf0b9f2811f5f992d5c4b
- stable/c/ef15ccbb3e8640a723c42ad90eaf81d66ae02017