{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2023-52909", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-08-21T06:07:11.015Z", "datePublished": "2024-08-21T06:10:50.303Z", "dateUpdated": "2025-05-04T07:45:49.273Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2025-05-04T07:45:49.273Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix handling of cached open files in nfsd4_open codepath\n\nCommit fb70bf124b05 (\"NFSD: Instantiate a struct file when creating a\nregular NFSv4 file\") added the ability to cache an open fd over a\ncompound. There are a couple of problems with the way this currently\nworks:\n\nIt's racy, as a newly-created nfsd_file can end up with its PENDING bit\ncleared while the nf is hashed, and the nf_file pointer is still zeroed\nout. Other tasks can find it in this state and they expect to see a\nvalid nf_file, and can oops if nf_file is NULL.\n\nAlso, there is no guarantee that we'll end up creating a new nfsd_file\nif one is already in the hash. If an extant entry is in the hash with a\nvalid nf_file, nfs4_get_vfs_file will clobber its nf_file pointer with\nthe value of op_file and the old nf_file will leak.\n\nFix both issues by making a new nfsd_file_acquirei_opened variant that\ntakes an optional file pointer. If one is present when this is called,\nwe'll take a new reference to it instead of trying to open the file. If\nthe nfsd_file already has a valid nf_file, we'll just ignore the\noptional file and pass the nfsd_file back as-is.\n\nAlso rework the tracepoints a bit to allow for an \"opened\" variant and\ndon't try to avoid counting acquisitions in the case where we already\nhave a cached open file."}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["fs/nfsd/filecache.c", "fs/nfsd/filecache.h", "fs/nfsd/nfs4state.c", "fs/nfsd/trace.h"], "versions": [{"version": "c20097329d2c196b818c4666c7820c1378d69d61", "lessThan": "45c08a752982116f3287afcd1bd9c50f4fab0c28", "status": "affected", "versionType": "git"}, {"version": "106331a12b0fa5afa6995b1f9ebb03ddcaac6915", "lessThan": "0b778361998d6c6356b8d2fc7ddf025fb3224654", "status": "affected", "versionType": "git"}, {"version": "fb70bf124b051d4ded4ce57511dfec6d3ebf2b43", "lessThan": "973acfdfe90c8a4e58ade97ff0653a498531ff2e", "status": "affected", "versionType": "git"}, {"version": "fb70bf124b051d4ded4ce57511dfec6d3ebf2b43", "lessThan": "0b3a551fa58b4da941efeb209b3770868e2eddd7", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["fs/nfsd/filecache.c", "fs/nfsd/filecache.h", "fs/nfsd/nfs4state.c", "fs/nfsd/trace.h"], "versions": [{"version": "5.19", "status": "affected"}, {"version": "0", "lessThan": "5.19", "status": "unaffected", "versionType": "semver"}, {"version": "6.1.7", "lessThanOrEqual": "6.1.*", "status": "unaffected", "versionType": "semver"}, {"version": "6.2", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "cpeApplicability": [{"nodes": [{"operator": "OR", "negate": false, "cpeMatch": [{"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "5.19", "versionEndExcluding": "6.1.7"}, {"vulnerable": true, "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "versionStartIncluding": "5.19", "versionEndExcluding": "6.2"}]}]}], "references": [{"url": "https://git.kernel.org/stable/c/45c08a752982116f3287afcd1bd9c50f4fab0c28"}, {"url": "https://git.kernel.org/stable/c/0b778361998d6c6356b8d2fc7ddf025fb3224654"}, {"url": "https://git.kernel.org/stable/c/973acfdfe90c8a4e58ade97ff0653a498531ff2e"}, {"url": "https://git.kernel.org/stable/c/0b3a551fa58b4da941efeb209b3770868e2eddd7"}], "title": "nfsd: fix handling of cached open files in nfsd4_open codepath", "x_generator": {"engine": "bippy-1.2.0"}}, "adp": [{"metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2023-52909", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2024-09-10T16:03:02.157963Z"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-09-12T17:33:12.921Z"}}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2023-52909", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2024-09-10T16:03:02.157963Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-09-11T12:42:17.697Z"}}], "cna": {"title": "nfsd: fix handling of cached open files in nfsd4_open codepath", "affected": [{"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "c20097329d2c", "lessThan": "45c08a752982", "versionType": "git"}, {"status": "affected", "version": "106331a12b0f", "lessThan": "0b778361998d", "versionType": "git"}, {"status": "affected", "version": "fb70bf124b05", "lessThan": "973acfdfe90c", "versionType": "git"}, {"status": "affected", "version": "fb70bf124b05", "lessThan": "0b3a551fa58b", "versionType": "git"}], "programFiles": ["fs/nfsd/filecache.c", "fs/nfsd/filecache.h", "fs/nfsd/nfs4state.c", "fs/nfsd/trace.h"], "defaultStatus": "unaffected"}, {"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "5.19"}, {"status": "unaffected", "version": "0", "lessThan": "5.19", "versionType": "custom"}, {"status": "unaffected", "version": "6.1.7", "versionType": "custom", "lessThanOrEqual": "6.1.*"}, {"status": "unaffected", "version": "6.2", "versionType": "original_commit_for_fix", "lessThanOrEqual": "*"}], "programFiles": ["fs/nfsd/filecache.c", "fs/nfsd/filecache.h", "fs/nfsd/nfs4state.c", "fs/nfsd/trace.h"], "defaultStatus": "affected"}], "references": [{"url": "https://git.kernel.org/stable/c/45c08a752982116f3287afcd1bd9c50f4fab0c28"}, {"url": "https://git.kernel.org/stable/c/0b778361998d6c6356b8d2fc7ddf025fb3224654"}, {"url": "https://git.kernel.org/stable/c/973acfdfe90c8a4e58ade97ff0653a498531ff2e"}, {"url": "https://git.kernel.org/stable/c/0b3a551fa58b4da941efeb209b3770868e2eddd7"}], "x_generator": {"engine": "bippy-c9c4e1df01b2"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix handling of cached open files in nfsd4_open codepath\n\nCommit fb70bf124b05 (\"NFSD: Instantiate a struct file when creating a\nregular NFSv4 file\") added the ability to cache an open fd over a\ncompound. There are a couple of problems with the way this currently\nworks:\n\nIt's racy, as a newly-created nfsd_file can end up with its PENDING bit\ncleared while the nf is hashed, and the nf_file pointer is still zeroed\nout. Other tasks can find it in this state and they expect to see a\nvalid nf_file, and can oops if nf_file is NULL.\n\nAlso, there is no guarantee that we'll end up creating a new nfsd_file\nif one is already in the hash. If an extant entry is in the hash with a\nvalid nf_file, nfs4_get_vfs_file will clobber its nf_file pointer with\nthe value of op_file and the old nf_file will leak.\n\nFix both issues by making a new nfsd_file_acquirei_opened variant that\ntakes an optional file pointer. If one is present when this is called,\nwe'll take a new reference to it instead of trying to open the file. If\nthe nfsd_file already has a valid nf_file, we'll just ignore the\noptional file and pass the nfsd_file back as-is.\n\nAlso rework the tracepoints a bit to allow for an \"opened\" variant and\ndon't try to avoid counting acquisitions in the case where we already\nhave a cached open file."}], "providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-08-21T06:10:50.303Z"}}}, "cveMetadata": {"cveId": "CVE-2023-52909", "state": "PUBLISHED", "dateUpdated": "2024-09-12T17:33:12.921Z", "dateReserved": "2024-08-21T06:07:11.015Z", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "datePublished": "2024-08-21T06:10:50.303Z", "assignerShortName": "Linux"}, "dataVersion": "5.1"}

{"configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "matchCriteriaId": "A3B4D9E4-9005-47B1-B0C1-FFC9874D6FF6", "versionEndExcluding": "6.1.7", "versionStartIncluding": "5.19", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc1:*:*:*:*:*:*", "matchCriteriaId": "FF501633-2F44-4913-A8EE-B021929F49F6", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc2:*:*:*:*:*:*", "matchCriteriaId": "2BDA597B-CAC1-4DF0-86F0-42E142C654E9", "vulnerable": true}, {"criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc3:*:*:*:*:*:*", "matchCriteriaId": "725C78C9-12CE-406F-ABE8-0813A01D66E8", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix handling of cached open files in nfsd4_open codepath\n\nCommit fb70bf124b05 (\"NFSD: Instantiate a struct file when creating a\nregular NFSv4 file\") added the ability to cache an open fd over a\ncompound. There are a couple of problems with the way this currently\nworks:\n\nIt's racy, as a newly-created nfsd_file can end up with its PENDING bit\ncleared while the nf is hashed, and the nf_file pointer is still zeroed\nout. Other tasks can find it in this state and they expect to see a\nvalid nf_file, and can oops if nf_file is NULL.\n\nAlso, there is no guarantee that we'll end up creating a new nfsd_file\nif one is already in the hash. If an extant entry is in the hash with a\nvalid nf_file, nfs4_get_vfs_file will clobber its nf_file pointer with\nthe value of op_file and the old nf_file will leak.\n\nFix both issues by making a new nfsd_file_acquirei_opened variant that\ntakes an optional file pointer. If one is present when this is called,\nwe'll take a new reference to it instead of trying to open the file. If\nthe nfsd_file already has a valid nf_file, we'll just ignore the\noptional file and pass the nfsd_file back as-is.\n\nAlso rework the tracepoints a bit to allow for an \"opened\" variant and\ndon't try to avoid counting acquisitions in the case where we already\nhave a cached open file."}, {"lang": "es", "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: corrige el manejo de archivos abiertos almacenados en cach\u00e9 en la ruta de c\u00f3digo nfsd4_open el commit fb70bf124b05 (\"NFSD: crear una instancia de un archivo de estructura al crear un archivo NFSv4 normal\") agreg\u00f3 la capacidad de almacenar en cach\u00e9 un fd abierto sobre un compuesto. Hay un par de problemas con la forma en que esto funciona actualmente: Es picante, ya que un nfsd_file reci\u00e9n creado puede terminar con su bit PENDIENTE borrado mientras el nf tiene hash, y el puntero nf_file todav\u00eda est\u00e1 puesto a cero. Otras tareas pueden encontrarlo en este estado y esperan ver un nf_file v\u00e1lido, y pueden ir si nf_file es NULL. Adem\u00e1s, no hay garant\u00eda de que terminemos creando un nuevo nfsd_file si ya hay uno en el hash. Si una entrada existente est\u00e1 en el hash con un nf_file v\u00e1lido, nfs4_get_vfs_file golpear\u00e1 su puntero nf_file con el valor de op_file y el antiguo nf_file se filtrar\u00e1. Solucione ambos problemas creando una nueva variante nfsd_file_acquirei_opened que toma un puntero de archivo opcional. Si hay uno presente cuando se llama, tomaremos una nueva referencia en lugar de intentar abrir el archivo. Si el nfsd_file ya tiene un nf_file v\u00e1lido, simplemente ignoraremos el archivo opcional y devolveremos el nfsd_file tal como est\u00e1. Tambi\u00e9n vuelva a trabajar un poco los puntos de seguimiento para permitir una variante \"abierta\" y no intente evitar contar adquisiciones en el caso de que ya tengamos un archivo abierto en cach\u00e9."}], "id": "CVE-2023-52909", "lastModified": "2024-09-12T14:52:54.573", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "HIGH", "attackVector": "LOCAL", "availabilityImpact": "HIGH", "baseScore": 4.7, "baseSeverity": "MEDIUM", "confidentialityImpact": "NONE", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H", "version": "3.1"}, "exploitabilityScore": 1.0, "impactScore": 3.6, "source": "nvd@nist.gov", "type": "Primary"}]}, "published": "2024-08-21T07:15:06.857", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/0b3a551fa58b4da941efeb209b3770868e2eddd7"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/0b778361998d6c6356b8d2fc7ddf025fb3224654"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/45c08a752982116f3287afcd1bd9c50f4fab0c28"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "tags": ["Patch"], "url": "https://git.kernel.org/stable/c/973acfdfe90c8a4e58ade97ff0653a498531ff2e"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Analyzed", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-476"}], "source": "nvd@nist.gov", "type": "Primary"}]}

{"bugzilla": {"description": "kernel: nfsd: fix handling of cached open files in nfsd4_open codepath", "id": "2306437", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2306437"}, "csaw": false, "cvss3": {"cvss3_base_score": "4.7", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "cwe": "CWE-476", "details": ["In the Linux kernel, the following vulnerability has been resolved:\nnfsd: fix handling of cached open files in nfsd4_open codepath\nCommit fb70bf124b05 (\"NFSD: Instantiate a struct file when creating a\nregular NFSv4 file\") added the ability to cache an open fd over a\ncompound. There are a couple of problems with the way this currently\nworks:\nIt's racy, as a newly-created nfsd_file can end up with its PENDING bit\ncleared while the nf is hashed, and the nf_file pointer is still zeroed\nout. Other tasks can find it in this state and they expect to see a\nvalid nf_file, and can oops if nf_file is NULL.\nAlso, there is no guarantee that we'll end up creating a new nfsd_file\nif one is already in the hash. If an extant entry is in the hash with a\nvalid nf_file, nfs4_get_vfs_file will clobber its nf_file pointer with\nthe value of op_file and the old nf_file will leak.\nFix both issues by making a new nfsd_file_acquirei_opened variant that\ntakes an optional file pointer. If one is present when this is called,\nwe'll take a new reference to it instead of trying to open the file. If\nthe nfsd_file already has a valid nf_file, we'll just ignore the\noptional file and pass the nfsd_file back as-is.\nAlso rework the tracepoints a bit to allow for an \"opened\" variant and\ndon't try to avoid counting acquisitions in the case where we already\nhave a cached open file.", "A NULL pointer dereference flaw was found in the Linux kernel's NFS server support functionality. This issue could allow a local user to crash the system."], "mitigation": {"lang": "en:us", "value": "To mitigate this issue, prevent module nfsd from being loaded. Please see https://access.redhat.com/solutions/41278 for how to blacklist a kernel module to prevent it from loading automatically."}, "name": "CVE-2023-52909", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-08-21T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2023-52909\nhttps://nvd.nist.gov/vuln/detail/CVE-2023-52909\nhttps://lore.kernel.org/linux-cve-announce/2024082114-CVE-2023-52909-f80d@gregkh/T"], "statement": "This issue only affects Red Hat Enterprise Linux 9.", "threat_severity": "Moderate"}

{}