Hello Anil

from what I can tell, this CVE was fixed in master but not in wrynose
please submit a patch for wrynose then ping this thread so we can apply
to scarthgap


thanks a lot
Jeremy


On Mon Jun 1, 2026 at 3:42 PM CEST, Anil Dongare -X (adongare - E INFOCHIPS 
PRIVATE LIMITED at Cisco) via lists.openembedded.org wrote:
> From: Anil Dongare <[email protected]>
>
> Pick the upstream patch [1] as mentioned in [2].
>
> [1] 
> https://git.kernel.org/pub/scm/libs/libcap/libcap.git/patch/?id=286ace1259992bd0c5d9016715833f2e148ac596
> [2] https://security-tracker.debian.org/tracker/CVE-2026-4878
>
> Signed-off-by: Anil Dongare <[email protected]>
> ---
>  .../libcap/files/CVE-2026-4878.patch          | 162 ++++++++++++++++++
>  meta/recipes-support/libcap/libcap_2.69.bb    |   1 +
>  2 files changed, 163 insertions(+)
>  create mode 100644 meta/recipes-support/libcap/files/CVE-2026-4878.patch
>
> diff --git a/meta/recipes-support/libcap/files/CVE-2026-4878.patch 
> b/meta/recipes-support/libcap/files/CVE-2026-4878.patch
> new file mode 100644
> index 0000000000..827e41b8a0
> --- /dev/null
> +++ b/meta/recipes-support/libcap/files/CVE-2026-4878.patch
> @@ -0,0 +1,162 @@
> +From 286ace1259992bd0c5d9016715833f2e148ac596 Mon Sep 17 00:00:00 2001
> +From: "Andrew G. Morgan" <[email protected]>
> +Date: Thu, 12 Mar 2026 07:38:05 -0700
> +Subject: [PATCH] Address a potential TOCTOU race condition in cap_set_file().
> +
> +This issue was researched and reported by Ali Raza (@locus-x64). It
> +has been assigned CVE-2026-4878.
> +
> +The finding is that while cap_set_file() checks if a file is a regular
> +file before applying or removing a capability attribute, a small
> +window existed after that check when the filepath could be overwritten
> +either with new content or a symlink to some other file. To do this
> +would imply that the caller of cap_set_file() was directing it to a
> +directory over which a local attacker has write access, and performed
> +the operation frequently enough that an attacker had a non-negligible
> +chance of exploiting the race condition. The code now locks onto the
> +intended file, eliminating the race condition.
> +
> +CVE: CVE-2026-4878
> +Upstream-Status: Backport 
> [https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=286ace1259992bd0c5d9016715833f2e148ac596]
> +
> +Signed-off-by: Andrew G. Morgan <[email protected]>
> +(cherry picked from commit 286ace1259992bd0c5d9016715833f2e148ac596)
> +Signed-off-by: Anil Dongare <[email protected]>
> +---
> + libcap/cap_file.c  | 69 +++++++++++++++++++++++++++++++++++++++-------
> + progs/quicktest.sh | 14 +++++++++-
> + 2 files changed, 72 insertions(+), 11 deletions(-)
> +
> +diff --git a/libcap/cap_file.c b/libcap/cap_file.c
> +index 0bc07f7..f02bf9f 100644
> +--- a/libcap/cap_file.c
> ++++ b/libcap/cap_file.c
> +@@ -8,8 +8,13 @@
> + #define _DEFAULT_SOURCE
> + #endif
> + 
> ++#ifndef _GNU_SOURCE
> ++#define _GNU_SOURCE
> ++#endif
> ++
> + #include <sys/types.h>
> + #include <byteswap.h>
> ++#include <fcntl.h>
> + #include <sys/stat.h>
> + #include <unistd.h>
> + 
> +@@ -322,26 +327,70 @@ int cap_set_file(const char *filename, cap_t cap_d)
> +     struct vfs_ns_cap_data rawvfscap;
> +     int sizeofcaps;
> +     struct stat buf;
> ++    char fdpath[64];
> ++    int fd, ret;
> ++
> ++    _cap_debug("setting filename capabilities");
> ++    fd = open(filename, O_RDONLY|O_NOFOLLOW);
> ++    if (fd >= 0) {
> ++    ret = cap_set_fd(fd, cap_d);
> ++    close(fd);
> ++    return ret;
> ++    }
> + 
> +-    if (lstat(filename, &buf) != 0) {
> +-    _cap_debug("unable to stat file [%s]", filename);
> ++    /*
> ++     * Attempting to set a file capability on a file the process can't
> ++     * read the content of. This is considered a non-standard use case
> ++     * and the following (slower) code is complicated because it is
> ++     * trying to avoid a TOCTOU race condition.
> ++     */
> ++
> ++    fd = open(filename, O_PATH|O_NOFOLLOW);
> ++    if (fd < 0) {
> ++    _cap_debug("cannot find file at path [%s]", filename);
> ++    return -1;
> ++    }
> ++    if (fstat(fd, &buf) != 0) {
> ++    _cap_debug("unable to stat file [%s] descriptor %d",
> ++               filename, fd);
> ++    close(fd);
> +     return -1;
> +     }
> +     if (S_ISLNK(buf.st_mode) || !S_ISREG(buf.st_mode)) {
> +-    _cap_debug("file [%s] is not a regular file", filename);
> ++    _cap_debug("file [%s] descriptor %d for non-regular file",
> ++               filename, fd);
> ++    close(fd);
> +     errno = EINVAL;
> +     return -1;
> +     }
> + 
> +-    if (cap_d == NULL) {
> +-    _cap_debug("removing filename capabilities");
> +-    return removexattr(filename, XATTR_NAME_CAPS);
> ++    /*
> ++     * While the fd remains open, this named file is locked to the
> ++     * origin regular file. The size of the fdpath variable is
> ++     * sufficient to support a 160+ bit number.
> ++     */
> ++    if (snprintf(fdpath, sizeof(fdpath), "/proc/self/fd/%d", fd)
> ++    >= sizeof(fdpath)) {
> ++    _cap_debug("file descriptor too large %d", fd);
> ++    errno = EINVAL;
> ++    ret = -1;
> ++
> ++    } else if (cap_d == NULL) {
> ++    _cap_debug("dropping file caps on [%s] via [%s]",
> ++               filename, fdpath);
> ++    ret = removexattr(fdpath, XATTR_NAME_CAPS);
> ++
> +     } else if (_fcaps_save(&rawvfscap, cap_d, &sizeofcaps) != 0) {
> +-    return -1;
> +-    }
> ++    _cap_debug("problem converting cap_d to vfscap format");
> ++    ret = -1;
> + 
> +-    _cap_debug("setting filename capabilities");
> +-    return setxattr(filename, XATTR_NAME_CAPS, &rawvfscap, sizeofcaps, 0);
> ++    } else {
> ++    _cap_debug("setting filename capabilities");
> ++    ret = setxattr(fdpath, XATTR_NAME_CAPS, &rawvfscap,
> ++                   sizeofcaps, 0);
> ++    }
> ++    close(fd);
> ++    return ret;
> + }
> + 
> + /*
> +diff --git a/progs/quicktest.sh b/progs/quicktest.sh
> +index e6c48e6..5dc72f9 100755
> +--- a/progs/quicktest.sh
> ++++ b/progs/quicktest.sh
> +@@ -148,7 +148,19 @@ pass_capsh --caps="cap_setpcap=p" --inh=cap_chown 
> --current
> + pass_capsh --strict --caps="cap_chown=p" --inh=cap_chown --current
> + 
> + # change the way the capability is obtained (make it inheritable)
> ++chmod 0000 ./privileged
> + ./setcap cap_setuid,cap_setgid=ei ./privileged
> ++if [ $? -ne 0 ]; then
> ++    echo "FAILED to set file capability"
> ++    exit 1
> ++fi
> ++chmod 0755 ./privileged
> ++ln -s privileged unprivileged
> ++./setcap -r ./unprivileged
> ++if [ $? -eq 0 ]; then
> ++    echo "FAILED by removing a capability from a symlinked file"
> ++    exit 1
> ++fi
> + 
> + # Note, the bounding set (edited with --drop) only limits p
> + # capabilities, not i's.
> +@@ -246,7 +258,7 @@ EOF
> +     pass_capsh --iab='!%cap_chown,^cap_setpcap,cap_setuid'
> +     fail_capsh --mode=PURE1E --iab='!%cap_chown,^cap_setuid'
> + fi
> +-/bin/rm -f ./privileged
> ++/bin/rm -f ./privileged ./unprivileged
> + 
> + echo "testing namespaced file caps"
> + 
> +-- 
> diff --git a/meta/recipes-support/libcap/libcap_2.69.bb 
> b/meta/recipes-support/libcap/libcap_2.69.bb
> index 03975b44a0..43185f027e 100644
> --- a/meta/recipes-support/libcap/libcap_2.69.bb
> +++ b/meta/recipes-support/libcap/libcap_2.69.bb
> @@ -16,6 +16,7 @@ SRC_URI = 
> "${KERNELORG_MIRROR}/linux/libs/security/linux-privs/${BPN}2/${BPN}-${
>             
> file://0001-ensure-the-XATTR_NAME_CAPS-is-defined-when-it-is-use.patch \
>             file://0002-tests-do-not-run-target-executables.patch \
>             file://CVE-2025-1390.patch \
> +           file://CVE-2026-4878.patch \
>             "
>  SRC_URI:append:class-nativesdk = " \
>             
> file://0001-nativesdk-libcap-Raise-the-size-of-arrays-containing.patch \

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#238248): 
https://lists.openembedded.org/g/openembedded-core/message/238248
Mute This Topic: https://lists.openembedded.org/mt/119590711/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

  • ... Anil Dongare -X (adongare - E INFOCHIPS PRIVATE LIMITED at Cisco) via lists.openembedded.org
    • ... J?r?my Rosen via lists.openembedded.org

Reply via email to