SUSE-SU-2026:23726-1: important: Security update for acl, attr
SLE-SECURITY-UPDATES
null at suse.de
Wed Sep 16 16:32:50 UTC 2026
# Security update for acl, attr
Announcement ID: SUSE-SU-2026:23726-1
Release Date: 2026-09-11T11:56:09Z
Rating: important
References:
* bsc#1268867
* jsc#PED-16501
Cross-References:
* CVE-2026-54369
* CVE-2026-54370
* CVE-2026-54371
CVSS scores:
* CVE-2026-54369 ( SUSE ): 8.8
CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
* CVE-2026-54369 ( SUSE ): 7.4 CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
* CVE-2026-54369 ( NVD ): 8.4
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
* CVE-2026-54369 ( NVD ): 7.1 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
* CVE-2026-54369 ( NVD ): 7.1 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
* CVE-2026-54370 ( SUSE ): 8.8
CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
* CVE-2026-54370 ( SUSE ): 7.4 CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
* CVE-2026-54370 ( NVD ): 7.2
CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
* CVE-2026-54370 ( NVD ): 6.3 CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
* CVE-2026-54371 ( SUSE ): 8.8
CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
* CVE-2026-54371 ( SUSE ): 7.4 CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
* CVE-2026-54371 ( NVD ): 8.4
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
* CVE-2026-54371 ( NVD ): 7.1 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
* CVE-2026-54371 ( NVD ): 6.3 CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
Affected Products:
* SUSE Linux Enterprise Server 16.0
* SUSE Linux Enterprise Server for SAP applications 16.0
An update that solves three vulnerabilities and contains one feature can now be
installed.
## Description:
This update for acl, attr fixes the following issue:
* CVE-2026-54369,CVE-2026-54370,CVE-2026-54371: Symlink Traversal Privilege
Escalation via getfattr/setfattr, getfacl/setfacl/chacl, libacl
(bsc#1268867).
Changes for acl:
* Update to 2.4.0 (jsc#PED-16501): Major Issues Fixed:
* The libacl library functions acl_get_file(), acl_set_file(),
acl_extended_file(), and acl_delete_def_file() take a pathname argument and
follow symbolic links. When a privileged user calls one of those functions,
an attacker that controls a pathname component can replace a file or
directory with a symbolic link and redirect the operation to a different
file. This can lead to local privilege escalation. (CVE-2026-54369,
bsc#1268867) The library functions cannot be fixed without breaking
compatibility; the described behaviour is by design. Instead, version 2.4.0
of the acl package introduces the additional functions acl_get_file_at(),
acl_set_file_at(), acl_extended_file_at(), and acl_delete_def_file_at().
These functions each take a dirfd file descriptor argument and an at_flags
argument and accept the AT_SYMLINK_NOFOLLOW and AT_EMPTY_PATH flags. Use
these functions to control when to follow symbolic links. (CVE-2026-54370,
bsc#1268867) In addition, the libacl functions acl_get_fd(), acl_set_fd(),
and acl_extended_fd() functions always operate on the access ACL; the
library previously did not offer a way to operate on the default ACL of a
directory file descriptor. The new functions remove that restriction. It
will be up to each individual program to start using these new library
functions where appropriate.
* When walking directory trees, the getfacl, setfacl, chacl, and getfattr
utilities constructed the full pathname of each file in the tree and use
that pathname to access the file. When a privileged user used those
utilities, an attacker that controlled a pathname component could replace a
directory with a symbolic link and redirect the operation to a different
file, leading to a local privilege escalation. (CVE-2026-54371, bsc#1268867)
This is fixed by using directory file descriptors and operating relative to
those directory file descriptors.
* When resolving the final pathname component, the getfacl, setfacl, chacl,
getfattr, and setfattr utilities in some cases used functions that resolve
symbolic links. This includes the above mentioned libacl functions, but also
stat(), chmod(), and chown(). This is fixed by using symlink-safe functions
throughout the code.
* When restoring a backup, the setfacl and setfattr utilities read the full
pathnames of files from the backup. When those pathnames were resolved,
pathname components that are symbolic links were traversed. An attacker that
controlled a pathname component could replace it with a symbolic link,
causing a privileged user to operate on a file other than the one intended.
This could lead to the same kind of local privilege escalation as discussed
before. This is fixed by using openat2(RESOLVE_NO_SYMLINKS) to resolve the
directory components of a pathname, but see Compatibility Notes below for
the details. Minor Issues Fixed:
* When a symbolic link was specified on the command line but symbolic link
traversal was disabled using option -P (--physical), the getfacl and setfacl
utilities previously silently ignored the symlink. Now, an ELOOP ("Too many
levels of symbolic links") error will result instead.
* acl_delete_entry() now verifies that the specified entry belongs to the
specified acl.
* Numeric uids and gids that cannot be represented in types uid_t and gid_t
are checked more carefully and invalid numbers are rejected.
* Functions acl_get_file(), acl_get_file_at(), and acl_get_fd() will retry
several times when the size of an ACL grows unexpectedly; previously, they
only grew the allocated buffer once before giving up.
* When passed a directory file descriptor, function perm_copy_fd() didn't copy
the default ACL from one directory to the other. It now does.
* setfacl --restore accidentally ignored leading whitespace in filenames. It
no longer does.
* setfacl --restore accidentally called chmod() when in --test mode. It no
longer does.
* When the setfattr --restore option was used multiple times, a buffer was
accessed after being freed. This no longer happens.
* When the setfattr -h (--no-dereference) option was given after --restore, it
was ignored. Now, the options can be passed in any order.
* The -h (--no-dereference) option of getfattr prevented getfattr from
recursing into "symbolic link directories". This is wrong. When dirlink is a
symbolic link that refers to a directory, "getfattr -Rh dirlink" will now
visit that directory. The -P (--physical) option can be used to prevent
that.
* Similarly, when a symbolic link referring to a directory was specified on
the getfacl or setfacl command line, the -R option did not cause that
directory to be visited. This has been fixed so that those directories will
now be visited. The -P (--physical) option can be used to prevent
Changes for attr:
* Update to 2.6.0 (jsc#PED-16501): Major Issues Fixed:
* The libacl library functions acl_get_file(), acl_set_file(),
acl_extended_file(), and acl_delete_def_file() take a pathname argument and
follow symbolic links. When a privileged user calls one of those functions,
an attacker that controls a pathname component can replace a file or
directory with a symbolic link and redirect the operation to a different
file. This can lead to local privilege escalation. (CVE-2026-54369,
bsc#1268867) The library functions cannot be fixed without breaking
compatibility; the described behaviour is by design. Instead, version 2.4.0
of the acl package introduces the additional functions acl_get_file_at(),
acl_set_file_at(), acl_extended_file_at(), and acl_delete_def_file_at().
These functions each take a dirfd file descriptor argument and an at_flags
argument and accept the AT_SYMLINK_NOFOLLOW and AT_EMPTY_PATH flags. Use
these functions to control when to follow symbolic links. (CVE-2026-54370,
bsc#1268867) In addition, the libacl functions acl_get_fd(), acl_set_fd(),
and acl_extended_fd() functions always operate on the access ACL; the
library previously did not offer a way to operate on the default ACL of a
directory file descriptor. The new functions remove that restriction. It
will be up to each individual program to start using these new library
functions where appropriate.
* When walking directory trees, the getfacl, setfacl, chacl, and getfattr
utilities constructed the full pathname of each file in the tree and use
that pathname to access the file. When a privileged user used those
utilities, an attacker that controlled a pathname component could replace a
directory with a symbolic link and redirect the operation to a different
file, leading to a local privilege escalation. (CVE-2026-54371, bsc#1268867)
This is fixed by using directory file descriptors and operating relative to
those directory file descriptors.
* When resolving the final pathname component, the getfacl, setfacl, chacl,
getfattr, and setfattr utilities in some cases used functions that resolve
symbolic links. This includes the above mentioned libacl functions, but also
stat(), chmod(), and chown(). This is fixed by using symlink-safe functions
throughout the code.
* When restoring a backup, the setfacl and setfattr utilities read the full
pathnames of files from the backup. When those pathnames were resolved,
pathname components that are symbolic links were traversed. An attacker that
controlled a pathname component could replace it with a symbolic link,
causing a privileged user to operate on a file other than the one intended.
This could lead to the same kind of local privilege escalation as discussed
before. This is fixed by using openat2(RESOLVE_NO_SYMLINKS) to resolve the
directory components of a pathname, but see Compatibility Notes below for
the details. Minor Issues Fixed:
* When a symbolic link was specified on the command line but symbolic link
traversal was disabled using option -P (--physical), the getfacl and setfacl
utilities previously silently ignored the symlink. Now, an ELOOP ("Too many
levels of symbolic links") error will result instead.
* acl_delete_entry() now verifies that the specified entry belongs to the
specified acl.
* Numeric uids and gids that cannot be represented in types uid_t and gid_t
are checked more carefully and invalid numbers are rejected.
* Functions acl_get_file(), acl_get_file_at(), and acl_get_fd() will retry
several times when the size of an ACL grows unexpectedly; previously, they
only grew the allocated buffer once before giving up.
* When passed a directory file descriptor, function perm_copy_fd() didn't copy
the default ACL from one directory to the other. It now does.
* setfacl --restore accidentally ignored leading whitespace in filenames. It
no longer does.
* setfacl --restore accidentally called chmod() when in --test mode. It no
longer does.
* When the setfattr --restore option was used multiple times, a buffer was
accessed after being freed. This no longer happens.
* When the setfattr -h (--no-dereference) option was given after --restore, it
was ignored. Now, the options can be passed in any order.
* The -h (--no-dereference) option of getfattr prevented getfattr from
recursing into "symbolic link directories". This is wrong. When dirlink is a
symbolic link that refers to a directory, "getfattr -Rh dirlink" will now
visit that directory. The -P (--physical) option can be used to prevent
that.
* Similarly, when a symbolic link referring to a directory was specified on
the getfacl or setfacl command line, the -R option did not cause that
directory to be visited. This has been fixed so that those directories will
now be visited. The -P (--physical) option can be used to prevent
## Patch Instructions:
To install this SUSE update use the SUSE recommended installation methods like
YaST online_update or "zypper patch".
Alternatively you can run the command listed for your product:
* SUSE Linux Enterprise Server for SAP applications 16.0
zypper in -t patch SUSE-SLES-16.0-1661
* SUSE Linux Enterprise Server 16.0
zypper in -t patch SUSE-SLES-16.0-1661
## Package List:
* SUSE Linux Enterprise Server for SAP applications 16.0 (ppc64le x86_64)
* libacl1-2.4.0-160000.1.1
* libattr-devel-static-2.6.0-160000.1.1
* libacl-devel-2.4.0-160000.1.1
* libattr-devel-2.6.0-160000.1.1
* attr-2.6.0-160000.1.1
* acl-debugsource-2.4.0-160000.1.1
* libattr1-debuginfo-2.6.0-160000.1.1
* acl-debuginfo-2.4.0-160000.1.1
* attr-debugsource-2.6.0-160000.1.1
* libacl1-debuginfo-2.4.0-160000.1.1
* libattr1-2.6.0-160000.1.1
* acl-2.4.0-160000.1.1
* attr-debuginfo-2.6.0-160000.1.1
* SUSE Linux Enterprise Server 16.0 (aarch64 ppc64le s390x x86_64)
* libacl1-2.4.0-160000.1.1
* libattr-devel-static-2.6.0-160000.1.1
* libacl-devel-2.4.0-160000.1.1
* libattr-devel-2.6.0-160000.1.1
* attr-2.6.0-160000.1.1
* acl-debugsource-2.4.0-160000.1.1
* libattr1-debuginfo-2.6.0-160000.1.1
* acl-debuginfo-2.4.0-160000.1.1
* attr-debugsource-2.6.0-160000.1.1
* libacl1-debuginfo-2.4.0-160000.1.1
* libattr1-2.6.0-160000.1.1
* acl-2.4.0-160000.1.1
* attr-debuginfo-2.6.0-160000.1.1
## References:
* https://www.suse.com/security/cve/CVE-2026-54369.html
* https://www.suse.com/security/cve/CVE-2026-54370.html
* https://www.suse.com/security/cve/CVE-2026-54371.html
* https://bugzilla.suse.com/show_bug.cgi?id=1268867
* https://jira.suse.com/browse/PED-16501
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.suse.com/pipermail/sle-security-updates/attachments/20260916/8d4faf38/attachment.htm>
More information about the sle-security-updates
mailing list