Skip to main content

Linux Kernel CVE-2026-63942

| EUVDEUVD-2026-45715 HIGH
2026-07-19 Linux GHSA-g8r4-rq83-8vj2
7.8
CVSS 3.1 · Vendor: Linux
Share

Severity by source

Vendor (Linux) PRIMARY
7.8 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
vuln.today AI
4.1 MEDIUM

Local-only race needing module-load privileges (PR:H) and precise timing (AC:H); realistic impact is a kernel crash (A:H) with no confidentiality or integrity loss, so C:N/I:N.

3.1 AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:H/AT:N/PR:H/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
HIGH
qualitative
Red Hat
5.5 MEDIUM
qualitative

Primary rating from Vendor (Linux).

CVSS VectorVendor: Linux

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 20, 2026 - 16:28 vuln.today
CVSS changed
Jul 20, 2026 - 15:22 NVD
7.8 (HIGH)
Patch available
Jul 19, 2026 - 17:19 EUVD
CVE Published
Jul 19, 2026 - 14:55 cve.org
HIGH 7.8
CVE Published
Jul 19, 2026 - 14:55 cve.org
UNKNOWN (no severity yet)

DescriptionCVE.org

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.

AnalysisAI

Privilege-independent local crash in the Linux kernel's parport (parallel port) subsystem allows a race between port registration and client-driver attachment, where drivers such as lp bind to ports that are not yet fully initialised or are being torn down, causing a NULL/use-after-free style kernel crash. Affects systems where parport_pc and lp are built as modules and loaded concurrently during boot with PC-style parallel-port hardware present. No public exploit identified at time of analysis; EPSS is low (0.21%, 11th percentile) and it is not listed in CISA KEV, consistent with the vendor 'Denial Of Service' tag rather than code execution.

Technical ContextAI

The parport subsystem provides a generic abstraction over IEEE 1284 parallel ports, with low-level drivers like parport_pc registering physical ports and higher-level client drivers like lp (line printer) attaching to them. The root cause is a classic time-of-registration race (CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization; input lists CWE as N/A): the subsystem calls device_add() to register a port before parport_announce_port() finishes initialisation, so a client driver probing in parallel can attach to a half-initialised or partially-freed port structure. The CPE data (cpe:2.3:a:linux:linux:*) is generic and does not pin exact versions; the actual affected range is defined by the stable-tree commit boundaries in the EUVD data. The fix adds an 'announced' flag so clients only attach after the port is fully published, deferring the real structural fix (moving device_add() into parport_announce_port()) to a later cleanup.

RemediationAI

Update to a fixed stable kernel: Vendor-released patch 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, 6.18.35, 7.0.12, or 7.1 (or later on your branch), applied through your distribution's kernel update channel; the corresponding upstream commits are at https://git.kernel.org/stable/c/f3378b0d7bd4605de89b083b2900788157a181cc and the sibling links in the references. If immediate patching is not possible, the practical compensating control is to prevent the racing module load: blacklist the parport, parport_pc and lp modules (e.g. via /etc/modprobe.d) on systems that do not use a physical parallel port, which eliminates the vulnerable code path entirely with no impact on modern hardware; the trade-off is loss of legacy parallel-port printing/PLIP functionality on the rare systems that need it. Avoid concurrent boot-time loading of parport_pc and lp where the modules must remain, since serialising their load also avoids the race.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

CVE-2026-63942 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy