GHSA-MPC7-4W3V-V47R
Vulnerability from github – Published: 2026-07-19 12:30 – Updated: 2026-07-20 15:31In the Linux kernel, the following vulnerability has been resolved:
nfsd: fix posix_acl leak on SETACL decode failure
nfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each call nfs_stream_decode_acl() twice, first for NFS_ACL and then for NFS_DFACL. Each successful call transfers ownership of a freshly allocated posix_acl into argp->acl_access or argp->acl_default. If the first call succeeds but the second fails, the decoder returns false and argp->acl_access is left dangling.
ACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and ACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle. Both only call fh_put() and have no knowledge of the ACL fields on argp. The posix_acl_release() pairs sat at the out: labels inside nfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process() skips pc_func when pc_decode returns false, so that cleanup is unreachable on decode failure:
svc_process_common()
pc_decode() /* decode_setaclargs: false */
/* pc_func skipped */
pc_release() /* fh_put only -- ACLs leaked */
The orphaned posix_acl is leaked for the lifetime of the server.
Fix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(), which release both argp->acl_access and argp->acl_default in addition to fh_put(), and wiring them as pc_release for their respective SETACL procedures. pc_release runs on every path svc_process() takes after decode, including decode failure, so the posix_acl_release() pairs are removed from the proc functions' out: labels to keep ownership in one place. This matches the existing release_getacl() pattern used by the sibling GETACL procedures.
{
"affected": [],
"aliases": [
"CVE-2026-53397"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-19T12:16:50Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix posix_acl leak on SETACL decode failure\n\nnfsaclsvc_decode_setaclargs() and nfs3svc_decode_setaclargs() each\ncall nfs_stream_decode_acl() twice, first for NFS_ACL and then for\nNFS_DFACL. Each successful call transfers ownership of a freshly\nallocated posix_acl into argp-\u003eacl_access or argp-\u003eacl_default. If\nthe first call succeeds but the second fails, the decoder returns\nfalse and argp-\u003eacl_access is left dangling.\n\nACLPROC2_SETACL.pc_release was wired to nfssvc_release_attrstat and\nACLPROC3_SETACL.pc_release was wired to nfs3svc_release_fhandle.\nBoth only call fh_put() and have no knowledge of the ACL fields on\nargp. The posix_acl_release() pairs sat at the out: labels inside\nnfsacld_proc_setacl() and nfsd3_proc_setacl(), but svc_process()\nskips pc_func when pc_decode returns false, so that cleanup is\nunreachable on decode failure:\n\n svc_process_common()\n pc_decode() /* decode_setaclargs: false */\n /* pc_func skipped */\n pc_release() /* fh_put only -- ACLs leaked */\n\nThe orphaned posix_acl is leaked for the lifetime of the server.\n\nFix by adding nfsaclsvc_release_setacl() and nfs3svc_release_setacl(),\nwhich release both argp-\u003eacl_access and argp-\u003eacl_default in addition\nto fh_put(), and wiring them as pc_release for their respective SETACL\nprocedures. pc_release runs on every path svc_process() takes after\ndecode, including decode failure, so the posix_acl_release() pairs are\nremoved from the proc functions\u0027 out: labels to keep ownership in one\nplace. This matches the existing release_getacl() pattern used by\nthe sibling GETACL procedures.",
"id": "GHSA-mpc7-4w3v-v47r",
"modified": "2026-07-20T15:31:45Z",
"published": "2026-07-19T12:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53397"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0853ac544c590880d797b04daa33fcb72b6be0e1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/136b416593f1349cf6f72c8e3d18f0f204ee8545"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1e96239fddcefacf6afe6c498357be68eacbcabc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/887f92ceccf3eacd5f2402db21254d66372fae00"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5b42c1e4ff2befaa6b96f7cbf32174751eba083"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b2eb1ffd511d1b3c3e21122f97cbbccea411e277"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b94c4be77682aab06d65ca7296149e3bcfb37353"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bd69a825485168ef74e815ecb286754b570fdcc7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.