snlavaise/pmaports-rtwo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

linux-pine64-pinetab2: upgrade to 7.1.8

Browse Source 
Typical kernel roundup, no noticeable changes.

Also removed the UAF patch as it's already upstreamed.

Signed-off-by: Dang Huynh <dang.huynh@mainlining.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/9366>
This commit is contained in:
Dang Huynh
2026-08-19 15:42:29 +00:00
committed by The Friendly Meow (merge) Bot
parent 9c0a5583a2
commit bafefef832
3 changed files with 8 additions and 170 deletions
Download Patch File Download Diff File Expand all files Collapse all files
device/testing/linux-pine64-pinetab2/APKBUILD
+4 -6
View File
@@ -3,7 +3,7 @@
# Co-Maintainer: Stefan Hansson <newbyte@postmarketos.org>
maintainer="Dang Huynh <dang.huynh@mainlining.org>"
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
"
device/testing/linux-pine64-pinetab2/config-pine64-pinetab2.aarch64
+4 -3
View File
@@ -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
device/testing/linux-pine64-pinetab2/libbpf-Fix-UAF-in-strset__add_str.patch
-161
View File
@@ -1,161 +0,0 @@
From b23705e6afb6ac4ae6d220dcb35975698667dd76 Mon Sep 17 00:00:00 2001
From: Carlos Llamas <cmllamas@google.com>
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 <andrii@kernel.org>
Suggested-by: Mykyta Yatsenko <yatsenko@meta.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
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