From bafefef8321619097761646172dcfd464b1127d2 Mon Sep 17 00:00:00 2001 From: Dang Huynh Date: Tue, 11 Aug 2026 01:24:22 +0700 Subject: [PATCH] linux-pine64-pinetab2: upgrade to 7.1.8 Typical kernel roundup, no noticeable changes. Also removed the UAF patch as it's already upstreamed. Signed-off-by: Dang Huynh Part-of: --- device/testing/linux-pine64-pinetab2/APKBUILD | 10 +- .../config-pine64-pinetab2.aarch64 | 7 +- .../libbpf-Fix-UAF-in-strset__add_str.patch | 161 ------------------ 3 files changed, 8 insertions(+), 170 deletions(-) delete mode 100644 device/testing/linux-pine64-pinetab2/libbpf-Fix-UAF-in-strset__add_str.patch diff --git a/device/testing/linux-pine64-pinetab2/APKBUILD b/device/testing/linux-pine64-pinetab2/APKBUILD index fddb9e5c3..5590353ab 100644 --- a/device/testing/linux-pine64-pinetab2/APKBUILD +++ b/device/testing/linux-pine64-pinetab2/APKBUILD @@ -3,7 +3,7 @@ # Co-Maintainer: Stefan Hansson maintainer="Dang Huynh " pkgname=linux-pine64-pinetab2 -pkgver=7.1.3 +pkgver=7.1.8 pkgrel=0 _danctnix_kernel_rel=1 pkgdesc="Pine64 PineTab 2 mainline" @@ -39,7 +39,6 @@ source=" linux-$pkgver.tar.xz::https://cdn.kernel.org/pub/linux/kernel/v${pkgver%%.*}.x/linux-$pkgver.tar.xz $_tags.patch.zst::https://codeberg.org/DanctNIX/linux-pinetab2/releases/download/$_tags/$_tags.patch.zst $_config - libbpf-Fix-UAF-in-strset__add_str.patch " builddir="$srcdir/linux-$pkgver" _outdir="out" @@ -75,8 +74,7 @@ package() { } sha512sums=" -1c5e7e16c73f4942dcdc1783987e65351259d1f2d4ff39c91182529e2f9e689b62b3df3ec89b61514c473eb13ecb004a3825716b9c583fc41e25fc01fe569b30 linux-7.1.3.tar.xz -fdc3de811e281ea448088ca3d8ff879fe6955e9ee7c9b1afdcf8ad0637b56ea3e7e6183d3443e8c25968805320cd41a50f7a4bc82b50a4c6e6f13343075e6d81 v7.1.3-danctnix1.patch.zst -94c5355e00e97ccc4f0ef52541bbd51dc64615ea6c1379dc07066d4524ca57c3a15956d1f8d66870cfb453489446e287e0cf7438b873bced4974637f3deca289 config-pine64-pinetab2.aarch64 -e2555390d48cbbdc32a7d3f0c27599ff88f2fe3e786d1d0086caaa5b092cc3edcb6e95e2fb07034edb3793f6dc954da0662c723202eb7e2c4956c99b50919b12 libbpf-Fix-UAF-in-strset__add_str.patch +e17057478fd498fd4d83c4b6d3712fdfc3c6ae1d077114ea74ee41186cbd75add292f5e5f810fdf41242fd506a476d34447392b1c8194b5e8a6af1a59ac48a74 linux-7.1.8.tar.xz +d005aece060c6209e4a4ad7a518cc1a1bf6695f3752fbb9b497f97bf763f5c1428d85686c5160de5ed3a0042cc8c04e31f6ffbbcf129c2b6ec01a1314a36d0ea v7.1.8-danctnix1.patch.zst +52eab368c89b21a8b178c9f2b4956d6907fa921592415ba967191440e93de3768ebeb8bd720ea57cb7d721147604bfd03ce2e483f35b2e3898c26681df437ab2 config-pine64-pinetab2.aarch64 " diff --git a/device/testing/linux-pine64-pinetab2/config-pine64-pinetab2.aarch64 b/device/testing/linux-pine64-pinetab2/config-pine64-pinetab2.aarch64 index c778303e6..e4b8ace46 100644 --- a/device/testing/linux-pine64-pinetab2/config-pine64-pinetab2.aarch64 +++ b/device/testing/linux-pine64-pinetab2/config-pine64-pinetab2.aarch64 @@ -1,6 +1,6 @@ # # Automatically generated file; DO NOT EDIT. -# Linux/arm64 7.1.3-danctnix1 Kernel Configuration +# Linux/arm64 7.1.8-danctnix1 Kernel Configuration # CONFIG_CC_VERSION_TEXT="Alpine clang version 22.1.8" CONFIG_GCC_VERSION=0 @@ -7878,12 +7878,13 @@ CONFIG_EROFS_FS_SECURITY=y CONFIG_EROFS_FS_BACKED_BY_FILE=y CONFIG_EROFS_FS_ZIP=y CONFIG_EROFS_FS_ZIP_LZMA=y +CONFIG_EROFS_FS_ZIP_LZMA_DEFAULT_MAX_STREAMS=4 # CONFIG_EROFS_FS_ZIP_DEFLATE is not set # CONFIG_EROFS_FS_ZIP_ZSTD is not set # CONFIG_EROFS_FS_ZIP_ACCEL is not set -CONFIG_EROFS_FS_ONDEMAND=y CONFIG_EROFS_FS_PCPU_KTHREAD=y CONFIG_EROFS_FS_PCPU_KTHREAD_HIPRI=y +# CONFIG_EROFS_FS_PAGE_CACHE_SHARE is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V2=m @@ -8402,7 +8403,7 @@ CONFIG_CRYPTO_HASH_INFO=y CONFIG_CRYPTO_LIB_UTILS=y CONFIG_CRYPTO_LIB_AES=y CONFIG_CRYPTO_LIB_AES_ARCH=y -CONFIG_CRYPTO_LIB_AES_CBC_MACS=m +CONFIG_CRYPTO_LIB_AES_CBC_MACS=y CONFIG_CRYPTO_LIB_ARC4=m CONFIG_CRYPTO_LIB_GF128MUL=m CONFIG_CRYPTO_LIB_BLAKE2B=m diff --git a/device/testing/linux-pine64-pinetab2/libbpf-Fix-UAF-in-strset__add_str.patch b/device/testing/linux-pine64-pinetab2/libbpf-Fix-UAF-in-strset__add_str.patch deleted file mode 100644 index 1fc18c672..000000000 --- a/device/testing/linux-pine64-pinetab2/libbpf-Fix-UAF-in-strset__add_str.patch +++ /dev/null @@ -1,161 +0,0 @@ -From b23705e6afb6ac4ae6d220dcb35975698667dd76 Mon Sep 17 00:00:00 2001 -From: Carlos Llamas -Date: Sat, 23 May 2026 16:27:21 +0000 -Subject: [PATCH] libbpf: Fix UAF in strset__add_str() - -strset_add_str_mem() might reallocate the strset data buffer in order to -accommodate the provided string 's'. However, if 's' points to a string -already present in the buffer, it becomes dangling after the realloc. -This leads to a use-after-free when attempting to memcpy() the string -into the new buffer. - -One scenario that triggers this problematic path is when resolve_btfids -attempts to patch kfunc prototypes using existing BTF parameter names: - - | resolve_btfids: function bpf_list_push_back_impl already exists in BTF - | Segmentation fault (core dumped) - -Compiling resolve_btfids with fsanitize=address generates a detailed -report of the UAF: - - | ================================================================= - | ERROR: AddressSanitizer: heap-use-after-free on address 0x7f4c4a500bd4 - | ==1507892==ERROR: AddressSanitizer: heap-use-after-free on address 0x7f4c4a500bd4 at pc 0x55d25155a2a8 bp 0x7ffcef879060 sp 0x7ffcef878818 - | READ of size 5 at 0x7f4c4a500bd4 thread T0 - | #0 0x55d25155a2a7 in memcpy (tools/bpf/resolve_btfids/resolve_btfids+0xcf2a7) - | #1 0x55d2515d708e in strset__add_str tools/lib/bpf/strset.c:162:2 - | #2 0x55d2515c730b in btf__add_str tools/lib/bpf/btf.c:2109:8 - | #3 0x55d2515c9020 in btf__add_func_param tools/lib/bpf/btf.c:3108:14 - | #4 0x55d25159f0b5 in process_kfunc_with_implicit_args tools/bpf/resolve_btfids/main.c:1196:9 - | #5 0x55d25159e004 in btf2btf tools/bpf/resolve_btfids/main.c:1229:9 - | #6 0x55d25159cee7 in main tools/bpf/resolve_btfids/main.c:1535:6 - | #7 0x7f4c78e29f76 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16 - | #8 0x7f4c78e2a026 in __libc_start_main csu/../csu/libc-start.c:360:3 - | #9 0x55d2514bb860 in _start (tools/bpf/resolve_btfids/resolve_btfids+0x30860) - | - | 0x7f4c4a500bd4 is located 13268 bytes inside of 2829000-byte region [0x7f4c4a4fd800,0x7f4c4a7b02c8) - | freed by thread T0 here: - | #0 0x55d25155b700 in realloc (tools/bpf/resolve_btfids/resolve_btfids+0xd0700) - | #1 0x55d2515c426c in libbpf_reallocarray tools/lib/bpf/./libbpf_internal.h:220:9 - | #2 0x55d2515c426c in libbpf_add_mem tools/lib/bpf/btf.c:224:13 - | - | previously allocated by thread T0 here: - | #0 0x55d25155b2e3 in malloc (tools/bpf/resolve_btfids/resolve_btfids+0xd02e3) - | #1 0x55d2515d6e7d in strset__new tools/lib/bpf/strset.c:58:20 - -While resolve_btfids could be refactored to avoid this call path, let's -instead fix this issue at the source in strset__add_str() and avoid -similar scenarios. - -Let's check if set->strs_data was reallocated and whether 's' points to -an internal string within the old strset buffer. In such case, 's' is -reconstructed to point to the new buffer. - -While already here, also fix strset__find_str() which suffers from the -same problem by factoring out the common operations into a new helper -function strset_str_append(). - -Fixes: 90d76d3ececc ("libbpf: Extract internal set-of-strings datastructure APIs") -Suggested-by: Andrii Nakryiko -Suggested-by: Mykyta Yatsenko -Signed-off-by: Carlos Llamas -Signed-off-by: Andrii Nakryiko -Link: https://lore.kernel.org/bpf/20260523162722.2718940-1-cmllamas@google.com ---- - tools/lib/bpf/strset.c | 62 ++++++++++++++++++++++++++++-------------- - 1 file changed, 41 insertions(+), 21 deletions(-) - -diff --git a/tools/lib/bpf/strset.c b/tools/lib/bpf/strset.c -index 2464bcbd04e037..ace73c6b3d62b4 100644 ---- a/tools/lib/bpf/strset.c -+++ b/tools/lib/bpf/strset.c -@@ -107,6 +107,41 @@ static void *strset_add_str_mem(struct strset *set, size_t add_sz) - set->strs_data_len, set->strs_data_max_len, add_sz); - } - -+static long strset_str_append(struct strset *set, const char *s) -+{ -+ uintptr_t old_data = (uintptr_t)set->strs_data; -+ size_t old_data_len = set->strs_data_len; -+ uintptr_t old_s = (uintptr_t)s; -+ long len = strlen(s) + 1; -+ void *p; -+ -+ /* -+ * Hashmap keys are always offsets within set->strs_data, so to even -+ * look up some string from the "outside", we need to first append it -+ * at the end, so that it can be addressed with an offset. Luckily, -+ * until set->strs_data_len is incremented, that string is just a piece -+ * of garbage for the rest of the code, so no harm, no foul. On the -+ * other hand, if the string is unique, it's already appended and -+ * ready to be used, only a simple set->strs_data_len increment away. -+ */ -+ p = strset_add_str_mem(set, len); -+ if (!p) -+ return -ENOMEM; -+ -+ /* -+ * The set->strs_data might have reallocated and if 's' pointed -+ * to an internal string within the old buffer, then it became -+ * dangling and needs to be reconstructed before the copy. -+ */ -+ if (old_data && old_data != (uintptr_t)set->strs_data && -+ old_s >= old_data && old_s < old_data + old_data_len) -+ s = set->strs_data + (old_s - old_data); -+ -+ memcpy(p, s, len); -+ -+ return len; -+} -+ - /* Find string offset that corresponds to a given string *s*. - * Returns: - * - >0 offset into string data, if string is found; -@@ -116,16 +151,12 @@ static void *strset_add_str_mem(struct strset *set, size_t add_sz) - int strset__find_str(struct strset *set, const char *s) - { - long old_off, new_off, len; -- void *p; - -- /* see strset__add_str() for why we do this */ -- len = strlen(s) + 1; -- p = strset_add_str_mem(set, len); -- if (!p) -- return -ENOMEM; -+ len = strset_str_append(set, s); -+ if (len < 0) -+ return len; - - new_off = set->strs_data_len; -- memcpy(p, s, len); - - if (hashmap__find(set->strs_hash, new_off, &old_off)) - return old_off; -@@ -142,24 +173,13 @@ int strset__find_str(struct strset *set, const char *s) - int strset__add_str(struct strset *set, const char *s) - { - long old_off, new_off, len; -- void *p; - int err; - -- /* Hashmap keys are always offsets within set->strs_data, so to even -- * look up some string from the "outside", we need to first append it -- * at the end, so that it can be addressed with an offset. Luckily, -- * until set->strs_data_len is incremented, that string is just a piece -- * of garbage for the rest of the code, so no harm, no foul. On the -- * other hand, if the string is unique, it's already appended and -- * ready to be used, only a simple set->strs_data_len increment away. -- */ -- len = strlen(s) + 1; -- p = strset_add_str_mem(set, len); -- if (!p) -- return -ENOMEM; -+ len = strset_str_append(set, s); -+ if (len < 0) -+ return len; - - new_off = set->strs_data_len; -- memcpy(p, s, len); - - /* Now attempt to add the string, but only if the string with the same - * contents doesn't exist already (HASHMAP_ADD strategy). If such