!62 [sync] PR-60: backport upstream patches

From: @openeuler-sync-bot 
Reviewed-by: @HuaxinLuGitee 
Signed-off-by: @HuaxinLuGitee

backport-Avoid-a-deadlock-in-forked-psx-thread-exit.patch

@@ -0,0 +1,60 @@
+From 7617af6b0754da00c1094215ee7828d6592f8ade Mon Sep 17 00:00:00 2001
+From: "Andrew G. Morgan" <morgan@kernel.org>
+Date: Sun, 10 Apr 2022 15:39:14 -0700
+Subject: [PATCH] Avoid a deadlock in forked psx thread exit.
+
+go/captree was seeing lots of libcap_psx_test processes hanging around.
+It turns out that the newly added _psx_cleanup() function was deadlocking
+because inside a forked processes the psx_tracker.state was _PSX_INFORK
+and never _PSX_IDLE.
+
+This completes the fix for:
+
+  https://bugzilla.kernel.org/show_bug.cgi?id=215551
+
+Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
+---
+ psx/psx.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+diff --git a/psx/psx.c b/psx/psx.c
+index 1876978..d9c0485 100644
+--- a/psx/psx.c
++++ b/psx/psx.c
+@@ -287,7 +287,9 @@ static void psx_unlock(void)
+ }
+ 
+ /*
+- * under lock perform a state transition.
++ * under lock perform a state transition. Changing state is generally
++ * done via this function. However, there is a single exception in
++ * _psx_cleanup().
+  */
+ static void psx_new_state(psx_tracker_state_t was, psx_tracker_state_t is)
+ {
+@@ -351,7 +353,7 @@ static void _psx_forked_child(void) {
+      *
+      * We do this because the glibc man page for fork() suggests that
+      * only a subset of things will work post fork(). Specifically,
+-     * only a "async-signal-safe functions (see signal- safety(7))
++     * only a "async-signal-safe functions (see signal-safety(7))
+      * until such time as it calls execve(2)" can be relied upon. That
+      * man page suggests that you can't expect mutexes to work: "not
+      * async-signal-safe because it uses pthread_mutex_lock(3)
+@@ -733,7 +735,12 @@ static void _psx_cleanup(void) {
+      * never leave this state since this cleanup is only done at
+      * program exit.
+      */
+-    psx_new_state(_PSX_IDLE, _PSX_EXITING);
++    psx_lock();
++    while (psx_tracker.state != _PSX_IDLE && psx_tracker.state != _PSX_INFORK) {
++	pthread_cond_wait(&psx_tracker.cond, &psx_tracker.state_mu);
++    }
++    psx_tracker.state = _PSX_EXITING;
++    psx_unlock();
+ 
+     for (ref = psx_tracker.root; ref; ref = next) {
+ 	next = ref->next;
+-- 
+2.27.0
+

backport-Correct-the-check-of-pthread_create-s-return-value.patch

@@ -0,0 +1,41 @@
+From bc6b36682f188020ee4770fae1d41bde5b2c97bb Mon Sep 17 00:00:00 2001
+From: "Andrew G. Morgan" <morgan@kernel.org>
+Date: Wed, 3 May 2023 19:18:36 -0700
+Subject: [PATCH] Correct the check of pthread_create()'s return value.
+
+This function returns a positive number (errno) on error, so the code
+wasn't previously freeing some memory in this situation.
+
+Discussion:
+
+  https://stackoverflow.com/a/3581020/14760867
+
+Credit for finding this bug in libpsx goes to David Gstir of
+X41 D-Sec GmbH (https://x41-dsec.de/) who performed a security
+audit of the libcap source code in April of 2023. The audit
+was sponsored by the Open Source Technology Improvement Fund
+(https://ostif.org/).
+
+Audit ref: LCAP-CR-23-01 (CVE-2023-2602)
+
+Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
+---
+ psx/psx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/psx/psx.c b/psx/psx.c
+index d9c0485..65eb2aa 100644
+--- a/psx/psx.c
++++ b/psx/psx.c
+@@ -516,7 +516,7 @@ int __wrap_pthread_create(pthread_t *thread, const pthread_attr_t *attr,
+     pthread_sigmask(SIG_BLOCK, &sigbit, NULL);
+ 
+     int ret = __real_pthread_create(thread, attr, _psx_start_fn, starter);
+-    if (ret == -1) {
++    if (ret > 0) {
+ 	psx_new_state(_PSX_CREATE, _PSX_IDLE);
+ 	memset(starter, 0, sizeof(*starter));
+ 	free(starter);
+-- 
+2.27.0
+

backport-Large-strings-can-confuse-libcap-s-internal-strdup-c.patch

@@ -0,0 +1,55 @@
+From 422bec25ae4a1ab03fd4d6f728695ed279173b18 Mon Sep 17 00:00:00 2001
+From: "Andrew G. Morgan" <morgan@kernel.org>
+Date: Wed, 3 May 2023 19:44:22 -0700
+Subject: [PATCH] Large strings can confuse libcap's internal strdup code.
+
+Avoid something subtle with really long strings: 1073741823 should
+be enough for anybody. This is an improved fix over something attempted
+in libcap-2.55 to address some static analysis findings.
+
+Reviewing the library, cap_proc_root() and cap_launcher_set_chroot()
+are the only two calls where the library is potentially exposed to a
+user controlled string input.
+
+Credit for finding this bug in libcap goes to Richard Weinberger of
+X41 D-Sec GmbH (https://x41-dsec.de/) who performed a security audit
+of the libcap source code in April of 2023. The audit was sponsored
+by the Open Source Technology Improvement Fund (https://ostif.org/).
+
+Audit ref: LCAP-CR-23-02 (CVE-2023-2603)
+
+Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
+---
+ libcap/cap_alloc.c | 12 +++++++-----
+ 1 file changed, 7 insertions(+), 5 deletions(-)
+
+diff --git a/libcap/cap_alloc.c b/libcap/cap_alloc.c
+index 59fe503..504abd2 100644
+--- a/libcap/cap_alloc.c
++++ b/libcap/cap_alloc.c
+@@ -106,15 +106,17 @@ __attribute__((visibility ("hidden"))) char *_libcap_strdup(const char *old)
+ 	errno = EINVAL;
+ 	return NULL;
+     }
+-    len = strlen(old) + 1 + 2*sizeof(__u32);
+-    if (len < sizeof(struct _cap_alloc_s)) {
+-	len = sizeof(struct _cap_alloc_s);
+-    }
+-    if ((len & 0xffffffff) != len) {
++
++    len = strlen(old);
++    if ((len & 0x3fffffff) != len) {
+ 	_cap_debug("len is too long for libcap to manage");
+ 	errno = EINVAL;
+ 	return NULL;
+     }
++    len += 1 + 2*sizeof(__u32);
++    if (len < sizeof(struct _cap_alloc_s)) {
++	len = sizeof(struct _cap_alloc_s);
++    }
+ 
+     raw_data = calloc(1, len);
+     if (raw_data == NULL) {
+-- 
+2.27.0
+

backport-Stop-using-_pam_overwrite-in-pam_cap.c.patch

@@ -0,0 +1,45 @@
+From ee20d385ef319f8523f1debc49f375c8eff257a6 Mon Sep 17 00:00:00 2001
+From: "Andrew G. Morgan" <morgan@kernel.org>
+Date: Fri, 22 Dec 2023 06:37:02 -0800
+Subject: Stop using _pam_overwrite() in pam_cap.c.
+
+It looks like the Linux-PAM folk have deprecated this macro. Compiler optimization
+is hard to account for: apparently this explicit deletion is no longer
+guaranteed to work. This function was marked deprecated in v1.5.3 of Linux-PAM.
+
+I've replaced its use with memset(). I'm not convinced that that will be honored
+either, but remain hopeful and prefer to leave the code explicit in its intent
+without a deprecation warning messing up the build log. Should some compiler
+optimize it away and it leads to an exploit of some sort, it can be revealed as
+a compilation bug.
+
+Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
+---
+ pam_cap/pam_cap.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/pam_cap/pam_cap.c b/pam_cap/pam_cap.c
+index b9419cb..3fe3b8c 100644
+--- a/pam_cap/pam_cap.c
++++ b/pam_cap/pam_cap.c
+@@ -199,7 +199,7 @@ defer:
+     int i;
+     for (i = 0; i < groups_n; i++) {
+ 	char *g = groups[i];
+-	_pam_overwrite(g);
++	memset(g, 0, strlen(g));
+ 	_pam_drop(g);
+     }
+     if (groups != NULL) {
+@@ -440,7 +440,7 @@ int pam_sm_authenticate(pam_handle_t *pamh, int flags,
+ 	   small race associated with a redundant read of the
+ 	   config. */
+ 
+-	_pam_overwrite(conf_caps);
++	memset(conf_caps, 0, strlen(conf_caps));
+ 	_pam_drop(conf_caps);
+ 
+ 	return PAM_SUCCESS;
+-- 
+cgit 1.2.3-korg
+

backport-There-was-a-small-memory-leak-in-pam_cap.so-when-lib.patch

@@ -0,0 +1,48 @@
+From 917c8b5d3450870b4f25fd4a5a5198faa9de9aeb Mon Sep 17 00:00:00 2001
+From: "Andrew G. Morgan" <morgan@kernel.org>
+Date: Wed, 3 May 2023 20:12:52 -0700
+Subject: [PATCH] There was a small memory leak in pam_cap.so when libpam
+ returned an error.
+
+The function pam_set_data() takes ownership of a memory pointer if
+the call succeeds, but does not take that ownership if the function
+fails. Previously, the failure caused no deferred capability setting and
+a return code PAM_IGNORE. It continues to do that in this case, but no
+longer leaks the allocated iab memory.
+
+This bug was introduced with deferred IAB capability setting support in
+libcap-2.58.
+
+Credit for finding this bug in pam_cap.so goes to X41 D-Sec GmbH
+(https://x41-dsec.de/) who performed a security audit of the libcap
+source code in April of 2023. The audit was sponsored by the Open
+Source Technology Improvement Fund (https://ostif.org/).
+
+Audit ref: LCAP-CR-23-100
+
+Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
+---
+ pam_cap/pam_cap.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/pam_cap/pam_cap.c b/pam_cap/pam_cap.c
+index 7e8cade..91278dc 100644
+--- a/pam_cap/pam_cap.c
++++ b/pam_cap/pam_cap.c
+@@ -290,7 +290,12 @@ static int set_capabilities(struct pam_cap_s *cs)
+ 
+     if (cs->defer) {
+ 	D(("configured to delay applying IAB"));
+-	pam_set_data(cs->pamh, "pam_cap_iab", iab, iab_apply);
++	int ret = pam_set_data(cs->pamh, "pam_cap_iab", iab, iab_apply);
++	if (ret != PAM_SUCCESS) {
++	    D(("unable to cache capabilities for delayed setting: %d", ret));
++	    /* since ok=0, the module will return PAM_IGNORE */
++	    cap_free(iab);
++	}
+ 	iab = NULL;
+     } else if (!cap_iab_set_proc(iab)) {
+ 	D(("able to set the IAB [%s] value", conf_caps));
+-- 
+2.27.0
+

backport-getpcaps-catch-PID-parsing-errors.patch

@@ -0,0 +1,52 @@
+From fc804acc078ef03e2c5b3a233f118a537f260ccd Mon Sep 17 00:00:00 2001
+From: Jakub Wilk <jwilk@jwilk.net>
+Date: Thu, 1 Sep 2022 22:23:19 +0200
+Subject: [PATCH] getpcaps: catch PID parsing errors.
+
+Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
+Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
+---
+ progs/getpcaps.c | 19 ++++++++++++++++++-
+ 1 file changed, 18 insertions(+), 1 deletion(-)
+
+diff --git a/progs/getpcaps.c b/progs/getpcaps.c
+index 8fce0a3..1e914b2 100644
+--- a/progs/getpcaps.c
++++ b/progs/getpcaps.c
+@@ -39,7 +39,9 @@ int main(int argc, char **argv)
+     }
+ 
+     for ( ++argv; --argc > 0; ++argv ) {
++	long lpid;
+ 	int pid;
++	char *endarg;
+ 	cap_t cap_d;
+ 
+ 	if (!strcmp(argv[0], "--help") || !strcmp(argv[0], "--usage") ||
+@@ -62,7 +64,22 @@ int main(int argc, char **argv)
+ 	    continue;
+ 	}
+ 
+-	pid = atoi(argv[0]);
++	errno = 0;
++	lpid = strtol(argv[0], &endarg, 10);
++	if (*endarg != '\0') {
++	    errno = EINVAL;
++	}
++	if (errno == 0) {
++	    if (lpid < 0 || pid != (pid_t) pid)
++		errno = EOVERFLOW;
++	}
++	if (errno != 0) {
++	    fprintf(stderr, "Cannot parse pid %s (%s)\n",
++		    argv[0], strerror(errno));
++	    retval = 1;
++	    continue;
++	}
++	pid = lpid;
+ 
+ 	cap_d = cap_get_pid(pid);
+ 	if (cap_d == NULL) {
+-- 
+2.27.0
+

backport-getpcaps-fix-program-name-in-help-message.patch

@@ -0,0 +1,27 @@
+From 17c5e89521fd0455a8f18563eb37e5ddbc7d34cb Mon Sep 17 00:00:00 2001
+From: Jakub Wilk <jwilk@jwilk.net>
+Date: Mon, 29 Jan 2024 11:33:40 +0100
+Subject: getpcaps: fix program name in help message
+
+Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
+Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
+---
+ progs/getpcaps.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/progs/getpcaps.c b/progs/getpcaps.c
+index 7e14c36..b4cbda8 100644
+--- a/progs/getpcaps.c
++++ b/progs/getpcaps.c
+@@ -14,7 +14,7 @@
+ static void usage(int code)
+ {
+     fprintf(stderr,
+-"usage: getcaps <pid> [<pid> ...]\n\n"
++"usage: getpcaps <pid> [<pid> ...]\n\n"
+ "  This program displays the capabilities on the queried process(es).\n"
+ 	    "  The capabilities are displayed in the cap_from_text(3) format.\n"
+ 	    "\n"
+-- 
+cgit 1.2.3-korg
+

backport-libcap-Ensure-the-XATTR_NAME_CAPS-is-define.patch

@@ -0,0 +1,38 @@
+From 41997af6891658ab511c014e20f7846945c11742 Mon Sep 17 00:00:00 2001
+From: Roy Li <rongqing.li@windriver.com>
+Date: Mon, 9 Aug 2021 17:32:20 +0800
+Subject: [PATCH] [Backport] libcap: Ensure the XATTR_NAME_CAPS is defined when
+ it is used
+ 
+VFS_CAP_U32 can not ensure that XATTR_NAME_CAPS is defined, and failed to build
+libcap-native in old release, like CentOS release 6.7 (Final), with the blow
+error:
+     cap_file.c: In function ‘cap_get_fd’:
+     cap_file.c:199: error: ‘XATTR_NAME_CAPS’ undeclared (first use in this function)
+     cap_file.c:199: error: (Each undeclared identifier is reported only once
+Reference: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/libcap/files/0001-ensure-the-XATTR_NAME_CAPS-is-defined-when-it-is-use.patch
+ 
+Signed-off-by: Roy Li <rongqing.li@windriver.com>
+Signed-off-by: lichi <lichi7@huawei.com>
+Signed-off-by: luchangkun <luchangkun@h-partners.com>
+Signed-off-by: huangyaojun <huangyaojun@huawei.com>
+---
+ libcap/cap_file.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+ 
+diff --git a/libcap/cap_file.c b/libcap/cap_file.c
+index 4178705..1e6a28e 100644
+--- a/libcap/cap_file.c
++++ b/libcap/cap_file.c
+@@ -45,7 +45,7 @@ extern int fremovexattr(int, const char *);
+ 
+ #include "libcap.h"
+ 
+-#ifdef VFS_CAP_U32
++#if defined (VFS_CAP_U32) && defined (XATTR_NAME_CAPS)
+ 
+ #if VFS_CAP_U32 != __CAP_BLKS
+ # error VFS representation of capabilities is not the same size as kernel
+-- 
+2.27.0
+ 

backport-psx-free-allocated-memory-at-exit.patch

@@ -0,0 +1,102 @@
+From 66a8a1421e4520e9dda0a46704e25bafb989b1ae Mon Sep 17 00:00:00 2001
+From: "Andrew G. Morgan" <morgan@kernel.org>
+Date: Sat, 5 Feb 2022 17:26:05 -0800
+Subject: [PATCH] psx: free allocated memory at exit.
+
+Kalen Hall reported that Valgrind detected a memory leak associated
+with a multi-threaded program linked against libcap and libpsx.
+
+  https://bugzilla.kernel.org/show_bug.cgi?id=215551
+
+I've been unable to validate this myself with valgrind (likely holding
+it wrong), but did explore psx for allocated memory and via fprintf's
+convinced myself that this change should pair all calloc()s with a
+corresponding free().
+
+Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
+---
+ psx/psx.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
+ 1 file changed, 43 insertions(+), 1 deletion(-)
+
+diff --git a/psx/psx.c b/psx/psx.c
+index 6b669ae..1876978 100644
+--- a/psx/psx.c
++++ b/psx/psx.c
+@@ -29,6 +29,26 @@
+ 
+ #include "psx_syscall.h"
+ 
++#ifdef _PSX_DEBUG_MEMORY
++
++static void *_psx_calloc(const char *file, const int line,
++			 size_t nmemb, size_t size) {
++    void *ptr = calloc(nmemb, size);
++    fprintf(stderr, "psx:%d:%s:%d: calloc(%ld, %ld) -> %p\n", gettid(),
++	    file, line, (long int)nmemb, (long int)size, ptr);
++    return ptr;
++}
++
++static void _psx_free(const char *file, const int line, void *ptr) {
++    fprintf(stderr, "psx:%d:%s:%d: free(%p)\n", gettid(), file, line, ptr);
++    return free(ptr);
++}
++
++#define calloc(a, b)  _psx_calloc(__FILE__, __LINE__, a, b)
++#define free(a)       _psx_free(__FILE__, __LINE__, a)
++
++#endif /* def _PSX_DEBUG_MEMORY */
++
+ /*
+  * psx_load_syscalls() can be weakly defined in dependent libraries to
+  * provide a mechanism for a library to optionally leverage this psx
+@@ -177,6 +197,7 @@ static void psx_posix_syscall_actor(int signum, siginfo_t *info, void *ignore) {
+  * Some forward declarations for the initialization
+  * psx_syscall_start() routine.
+  */
++static void _psx_cleanup(void);
+ static void _psx_prepare_fork(void);
+ static void _psx_fork_completed(void);
+ static void _psx_forked_child(void);
+@@ -240,6 +261,7 @@ static void psx_syscall_start(void) {
+ 
+     psx_confirm_sigaction();
+     psx_do_registration(); /* register the main thread. */
++    atexit(_psx_cleanup);
+ 
+     psx_tracker.initialized = 1;
+ }
+@@ -420,7 +442,7 @@ static void _psx_exiting(void *node) {
+     pthread_sigmask(SIG_SETMASK, &orig_sigbits, NULL);
+ 
+     /*
+-     * Allow the rest of the psx system carry on as per normal.
++     * Allow the rest of the psx system to carry on as per normal.
+      */
+     psx_new_state(_PSX_EXITING, _PSX_IDLE);
+ }
+@@ -699,2 +721,22 @@ defer:
+     return ret;
+ }
++/*
++ * _psx_cleanup its called when the program exits. It is used to free
++ * any memory used by the thread tracker.
++ */
++static void _psx_cleanup(void) {
++    registered_thread_t *ref, *next;
++
++    /*
++     * We enter the exiting state. Unlike exiting a single thread we
++     * never leave this state since this cleanup is only done at
++     * program exit.
++     */
++    psx_new_state(_PSX_IDLE, _PSX_EXITING);
++
++    for (ref = psx_tracker.root; ref; ref = next) {
++	next = ref->next;
++	psx_do_unregister(ref);
++    }
++}
++
+-- 
+2.27.0
+

libcap.spec

@@ -1,6 +1,6 @@
 Name:     libcap
 Version:  2.61
-Release:  2
+Release:  7
 Summary:  A library for getting and setting POSIX.1e draft 15 capabilities        
 License:  GPLv2
 URL:      https://sites.google.com/site/fullycapable
@@ -8,6 +8,15 @@ Source0:  https://www.kernel.org/pub/linux/libs/security/linux-privs/libcap2/%{n
 
 Patch0:   libcap-buildflags.patch
 Patch1:   Fix-syntax-error-in-DEBUG-protected-setcap.c-code.patch
+Patch2:   backport-psx-free-allocated-memory-at-exit.patch
+Patch3:   backport-Avoid-a-deadlock-in-forked-psx-thread-exit.patch
+Patch4:   backport-getpcaps-catch-PID-parsing-errors.patch
+Patch5:   backport-Correct-the-check-of-pthread_create-s-return-value.patch
+Patch6:   backport-Large-strings-can-confuse-libcap-s-internal-strdup-c.patch
+Patch7:   backport-There-was-a-small-memory-leak-in-pam_cap.so-when-lib.patch 
+Patch8:   backport-libcap-Ensure-the-XATTR_NAME_CAPS-is-define.patch
+Patch9:   backport-getpcaps-fix-program-name-in-help-message.patch
+Patch10:  backport-Stop-using-_pam_overwrite-in-pam_cap.c.patch
 
 BuildRequires: libattr-devel pam-devel perl-interpreter gcc
 
@@ -71,6 +80,23 @@ chmod +x %{buildroot}/%{_libdir}/*.so.*
 %{_mandir}/man8/*.gz
 
 %changelog
+* Mon Mar 25 2024 yanglongkang <yanglongkang@h-partners.com> - 2.61-7
+- backport upstream patches:
+  getcpcaps: fix program name in help message
+  Stop using _pam_overwrite() in pam_cap.c
+
+* Mon Jul 3 2023 wangyunjia <yunjia.wang@huawei.com> - 2.61-6
+- VFS_CAP_U32 can not ensure that XATTR_NAME_CAPS is defined, and failed to build
+
+* Mon May 29 2023 wangyunjia <yunjia.wang@huawei.com> - 2.61-5
+- fix CVE-2023-2602/CVE-2023-2603 && fix memory leaks
+
+* Tue Nov 1 2022 yixiangzhike <yixiangzhike007@163.com> - 2.61-4
+- backport upstream patch
+
+* Wed Oct 12 2022 yixiangzhike <yixiangzhike007@163.com> - 2.61-3
+- backport upstream patches
+
 * Sat Aug 27 2022 yixiangzhike <yixiangzhike007@163.com> - 2.61-2
 - fix syntax error in DEBUG protected setcap.c code