CVE-2023-52909
published 2024-08-21CVE-2023-52909: In the Linux kernel, the following vulnerability has been resolved: nfsd: fix handling of cached open files in nfsd4_open codepath Commit fb70bf124b05 ("NFSD…
PriorityP418medium4.7CVSS 3.1
AVLACHPRLUINSUCNINAH
EPSS
0.64%
47.5th percentile
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix handling of cached open files in nfsd4_open codepath
Commit fb70bf124b05 ("NFSD: Instantiate a struct file when creating a
regular NFSv4 file") added the ability to cache an open fd over a
compound. There are a couple of problems with the way this currently
works:
It's racy, as a newly-created nfsd_file can end up with its PENDING bit
cleared while the nf is hashed, and the nf_file pointer is still zeroed
out. Other tasks can find it in this state and they expect to see a
valid nf_file, and can oops if nf_file is NULL.
Also, there is no guarantee that we'll end up creating a new nfsd_file
if one is already in the hash. If an extant entry is in the hash with a
valid nf_file, nfs4_get_vfs_file will clobber its nf_file pointer with
the value of op_file and the old nf_file will leak.
Fix both issues by making a new nfsd_file_acquirei_opened variant that
takes an optional file pointer. If one is present when this is called,
we'll take a new reference to it instead of trying to open the file. If
the nfsd_file already has a valid nf_file, we'll just ignore the
optional file and pass the nfsd_file back as-is.
Also rework the tracepoints a bit to allow for an "opened" variant and
don't try to avoid counting acquisitions in the case where we already
have a cached open file.
Affected
14 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.7-1 (bookworm) | linux 6.1.7-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 106331a12b0fa5afa6995b1f9ebb03ddcaac6915 < 0b778361998d6c6356b8d2fc7ddf025fb3224654 | 0b778361998d6c6356b8d2fc7ddf025fb3224654 |
| linux | linux | >= c20097329d2c196b818c4666c7820c1378d69d61 < 45c08a752982116f3287afcd1bd9c50f4fab0c28 | 45c08a752982116f3287afcd1bd9c50f4fab0c28 |
| linux | linux | >= fb70bf124b051d4ded4ce57511dfec6d3ebf2b43 < 973acfdfe90c8a4e58ade97ff0653a498531ff2e | 973acfdfe90c8a4e58ade97ff0653a498531ff2e |
| linux | linux | >= fb70bf124b051d4ded4ce57511dfec6d3ebf2b43 < 0b3a551fa58b4da941efeb209b3770868e2eddd7 | 0b3a551fa58b4da941efeb209b3770868e2eddd7 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 5.10.221-1 | 5.10.221-1 |
| linux | linux_kernel | >= 0 < 6.1.7-1 | 6.1.7-1 |
| linux | linux_kernel | >= 0 < 6.1.7-1 | 6.1.7-1 |
| linux | linux_kernel | >= 0 < 6.1.7-1 | 6.1.7-1 |
| linux | linux_kernel | >= 5.19 < 6.1.7 | 6.1.7 |
CVSS provenance
nvdv3.14.7MEDIUMCVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
osv4.7MEDIUM
vendor_debian4.7MEDIUM
vendor_redhat4.7MEDIUM
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: nfsd: fix handling of cached open files in nfsd4_open codepath
vendor_redhat·2024-08-21·CVSS 4.7
CVE-2023-52909 [MEDIUM] CWE-476 kernel: nfsd: fix handling of cached open files in nfsd4_open codepath
kernel: nfsd: fix handling of cached open files in nfsd4_open codepath
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix handling of cached open files in nfsd4_open codepath
Commit fb70bf124b05 ("NFSD: Instantiate a struct file when creating a
regular NFSv4 file") added the ability to cache an open fd over a
compound. There are a couple of problems with the way this currently
works:
It's racy, as a newly-created nfsd_file can end up with its PENDING bit
cleared while the nf is hashed, and the nf_file pointer is still zeroed
out. Other tasks can find it in this state and they expect to see a
valid nf_file, and can oops if nf_file is NULL.
Also, there is no guarantee that we'll end up creating a new nfsd_file
if one is already in the hash. If an extant entry is i
Debian
CVE-2023-52909: linux - In the Linux kernel, the following vulnerability has been resolved: nfsd: fix h...
vendor_debian·2023·CVSS 4.7
CVE-2023-52909 [MEDIUM] CVE-2023-52909: linux - In the Linux kernel, the following vulnerability has been resolved: nfsd: fix h...
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix handling of cached open files in nfsd4_open codepath Commit fb70bf124b05 ("NFSD: Instantiate a struct file when creating a regular NFSv4 file") added the ability to cache an open fd over a compound. There are a couple of problems with the way this currently works: It's racy, as a newly-created nfsd_file can end up with its PENDING bit cleared while the nf is hashed, and the nf_file pointer is still zeroed out. Other tasks can find it in this state and they expect to see a valid nf_file, and can oops if nf_file is NULL. Also, there is no guarantee that we'll end up creating a new nfsd_file if one is already in the hash. If an extant entry is in the hash with a valid nf_file, nfs4_get_vfs_file will clobber its nf_f
GHSA
GHSA-qw5v-wmjr-8fpc: In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix handling of cached open files in nfsd4_open codepath
Commit fb70bf124b
ghsa_unreviewed·2024-08-21
CVE-2023-52909 [MEDIUM] CWE-476 GHSA-qw5v-wmjr-8fpc: In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix handling of cached open files in nfsd4_open codepath
Commit fb70bf124b
In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix handling of cached open files in nfsd4_open codepath
Commit fb70bf124b05 ("NFSD: Instantiate a struct file when creating a
regular NFSv4 file") added the ability to cache an open fd over a
compound. There are a couple of problems with the way this currently
works:
It's racy, as a newly-created nfsd_file can end up with its PENDING bit
cleared while the nf is hashed, and the nf_file pointer is still zeroed
out. Other tasks can find it in this state and they expect to see a
valid nf_file, and can oops if nf_file is NULL.
Also, there is no guarantee that we'll end up creating a new nfsd_file
if one is already in the hash. If an extant entry is in the hash with a
valid nf_file, nfs4_get_vfs_file will clobber its
OSV
CVE-2023-52909: In the Linux kernel, the following vulnerability has been resolved: nfsd: fix handling of cached open files in nfsd4_open codepath Commit fb70bf124b05
osv·2024-08-21·CVSS 4.7
CVE-2023-52909 [MEDIUM] CVE-2023-52909: In the Linux kernel, the following vulnerability has been resolved: nfsd: fix handling of cached open files in nfsd4_open codepath Commit fb70bf124b05
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix handling of cached open files in nfsd4_open codepath Commit fb70bf124b05 ("NFSD: Instantiate a struct file when creating a regular NFSv4 file") added the ability to cache an open fd over a compound. There are a couple of problems with the way this currently works: It's racy, as a newly-created nfsd_file can end up with its PENDING bit cleared while the nf is hashed, and the nf_file pointer is still zeroed out. Other tasks can find it in this state and they expect to see a valid nf_file, and can oops if nf_file is NULL. Also, there is no guarantee that we'll end up creating a new nfsd_file if one is already in the hash. If an extant entry is in the hash with a valid nf_file, nfs4_get_vfs_file will clobber its nf_f
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
2024-08-21
Published