CVE-2022-49765
published 2025-05-01CVE-2022-49765: In the Linux kernel, the following vulnerability has been resolved: net/9p: use a dedicated spinlock for trans_fd Shamelessly copying the explanation from…
PriorityP420medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.14%
3.9th percentile
In the Linux kernel, the following vulnerability has been resolved:
net/9p: use a dedicated spinlock for trans_fd
Shamelessly copying the explanation from Tetsuo Handa's suggested
patch[1] (slightly reworded):
syzbot is reporting inconsistent lock state in p9_req_put()[2],
for p9_tag_remove() from p9_req_put() from IRQ context is using
spin_lock_irqsave() on "struct p9_client"->lock but trans_fd
(not from IRQ context) is using spin_lock().
Since the locks actually protect different things in client.c and in
trans_fd.c, just replace trans_fd.c's lock by a new one specific to the
transport (client.c's protect the idr for fid/tag allocations,
while trans_fd.c's protects its own req list and request status field
that acts as the transport's state machine)
Affected
10 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.0.10-1 (bookworm) | linux 6.0.10-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 673d62cdaac6ffbce980a349d3174b3929ceb9e5 < 43bbadb7e4636dc02f6a283c2a39e6438e6173cd | 43bbadb7e4636dc02f6a283c2a39e6438e6173cd |
| linux | linux | >= 673d62cdaac6ffbce980a349d3174b3929ceb9e5 < 717b9b4f38703d7f5293059e3a242d16f76fa045 | 717b9b4f38703d7f5293059e3a242d16f76fa045 |
| linux | linux | >= 673d62cdaac6ffbce980a349d3174b3929ceb9e5 < 296ab4a813841ba1d5f40b03190fd1bd8f25aab0 | 296ab4a813841ba1d5f40b03190fd1bd8f25aab0 |
| linux | linux_kernel | < 5.15.80 | 5.15.80 |
| linux | linux_kernel | >= 0 < 6.0.10-1 | 6.0.10-1 |
| linux | linux_kernel | >= 0 < 6.0.10-1 | 6.0.10-1 |
| linux | linux_kernel | >= 0 < 6.0.10-1 | 6.0.10-1 |
| linux | linux_kernel | >= 5.16 < 6.0.10 | 6.0.10 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: net/9p: use a dedicated spinlock for trans_fd
vendor_redhat·2025-05-01·CVSS 5.5
CVE-2022-49765 [MEDIUM] CWE-413 kernel: net/9p: use a dedicated spinlock for trans_fd
kernel: net/9p: use a dedicated spinlock for trans_fd
In the Linux kernel, the following vulnerability has been resolved:
net/9p: use a dedicated spinlock for trans_fd
Shamelessly copying the explanation from Tetsuo Handa's suggested
patch[1] (slightly reworded):
syzbot is reporting inconsistent lock state in p9_req_put()[2],
for p9_tag_remove() from p9_req_put() from IRQ context is using
spin_lock_irqsave() on "struct p9_client"->lock but trans_fd
(not from IRQ context) is using spin_lock().
Since the locks actually protect different things in client.c and in
trans_fd.c, just replace trans_fd.c's lock by a new one specific to the
transport (client.c's protect the idr for fid/tag allocations,
while trans_fd.c's protects its own req list and request status field
that acts as the transport'
Debian
CVE-2022-49765: linux - In the Linux kernel, the following vulnerability has been resolved: net/9p: use...
vendor_debian·2022·CVSS 5.5
CVE-2022-49765 [MEDIUM] CVE-2022-49765: linux - In the Linux kernel, the following vulnerability has been resolved: net/9p: use...
In the Linux kernel, the following vulnerability has been resolved: net/9p: use a dedicated spinlock for trans_fd Shamelessly copying the explanation from Tetsuo Handa's suggested patch[1] (slightly reworded): syzbot is reporting inconsistent lock state in p9_req_put()[2], for p9_tag_remove() from p9_req_put() from IRQ context is using spin_lock_irqsave() on "struct p9_client"->lock but trans_fd (not from IRQ context) is using spin_lock(). Since the locks actually protect different things in client.c and in trans_fd.c, just replace trans_fd.c's lock by a new one specific to the transport (client.c's protect the idr for fid/tag allocations, while trans_fd.c's protects its own req list and request status field that acts as the transport's state machine)
Scope: local
bookworm: resolved (fixed
OSV
CVE-2022-49765: In the Linux kernel, the following vulnerability has been resolved: net/9p: use a dedicated spinlock for trans_fd Shamelessly copying the explanation
osv·2025-05-01·CVSS 5.5
CVE-2022-49765 [MEDIUM] CVE-2022-49765: In the Linux kernel, the following vulnerability has been resolved: net/9p: use a dedicated spinlock for trans_fd Shamelessly copying the explanation
In the Linux kernel, the following vulnerability has been resolved: net/9p: use a dedicated spinlock for trans_fd Shamelessly copying the explanation from Tetsuo Handa's suggested patch[1] (slightly reworded): syzbot is reporting inconsistent lock state in p9_req_put()[2], for p9_tag_remove() from p9_req_put() from IRQ context is using spin_lock_irqsave() on "struct p9_client"->lock but trans_fd (not from IRQ context) is using spin_lock(). Since the locks actually protect different things in client.c and in trans_fd.c, just replace trans_fd.c's lock by a new one specific to the transport (client.c's protect the idr for fid/tag allocations, while trans_fd.c's protects its own req list and request status field that acts as the transport's state machine)
GHSA
GHSA-5rmr-vqfv-62q6: In the Linux kernel, the following vulnerability has been resolved:
net/9p: use a dedicated spinlock for trans_fd
Shamelessly copying the explanatio
ghsa_unreviewed·2025-05-01
CVE-2022-49765 [MEDIUM] CWE-667 GHSA-5rmr-vqfv-62q6: In the Linux kernel, the following vulnerability has been resolved:
net/9p: use a dedicated spinlock for trans_fd
Shamelessly copying the explanatio
In the Linux kernel, the following vulnerability has been resolved:
net/9p: use a dedicated spinlock for trans_fd
Shamelessly copying the explanation from Tetsuo Handa's suggested
patch[1] (slightly reworded):
syzbot is reporting inconsistent lock state in p9_req_put()[2],
for p9_tag_remove() from p9_req_put() from IRQ context is using
spin_lock_irqsave() on "struct p9_client"->lock but trans_fd
(not from IRQ context) is using spin_lock().
Since the locks actually protect different things in client.c and in
trans_fd.c, just replace trans_fd.c's lock by a new one specific to the
transport (client.c's protect the idr for fid/tag allocations,
while trans_fd.c's protects its own req list and request status field
that acts as the transport's state machine)
No detection rules found.
No public exploits indexed.
2025-05-01
Published