OPENAFS-SA-2024-002: acl: Do not parse beyond end of ACL 31/15931/2
authorAndrew Deason <adeason@sinenomine.net>
Tue, 19 Sep 2023 20:44:08 +0000 (15:44 -0500)
committerBenjamin Kaduk <kaduk@mit.edu>
Tue, 12 Nov 2024 18:05:32 +0000 (13:05 -0500)
commit1e6e813188ecce62eb7af19385d911f63469bdb6
treeb45c0c2524c9d450a07a0a2ddfcd4ec7b35a6688
parenta07e50726df09c49dfe7b953c3e49eb98f310c09
OPENAFS-SA-2024-002: acl: Do not parse beyond end of ACL

CVE-2024-10396

The early parsing code in acl_Internalize_pr() tries to advance
'nextc' to go beyond the first two newlines in the given ACL string.
But if the given ACL string has no newlines, or only 1 newline, then
'nextc' will point beyond the end of the ACL string, potentially
pointing to garbage.

Intuitively, it may look like the ACL string must contain at least 2
newlines because we have sscanf()'d the string with "%d\n%\d".
However, whitespace characters in sscanf() are not matched exactly
like non-whitespace characters are; a sequence of whitespace
characters matches any amount of whitespace (including none). So, a
string like "1 2" will be parsed by "%d\n%d\n", but will not contain
any newline characters.

Usually this should result in a parse error from acl_Internalize_pr(),
but if the garbage happens to parse successfully, this could result in
unrelated memory getting stored to the ACL.

To fix this, don't advance 'nextc' if we're already at the end of the
ACL string.

FIXES 135445

Reviewed-on: https://gerrit.openafs.org/15910
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
(cherry picked from commit 35d218c1d17973c1412ea5dff1e23d9aae50c4c7)

Change-Id: I7a7d136676e548adba5fa8d0003b5f8342332a86
Reviewed-on: https://gerrit.openafs.org/15931
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
src/libacl/aclprocs.c