From e8665aea463a80d56b243af600554c4ef4bad201 Mon Sep 17 00:00:00 2001 From: omni Date: Tue, 23 Jan 2024 12:40:40 +0000 Subject: [PATCH] main/linux-lts: fix CVE-2023-46838 / XSA-448 restore secfixes order --- main/linux-lts/APKBUILD | 11 +++- main/linux-lts/xsa448-linux.patch | 98 +++++++++++++++++++++++++++++++ 2 files changed, 106 insertions(+), 3 deletions(-) create mode 100644 main/linux-lts/xsa448-linux.patch diff --git a/main/linux-lts/APKBUILD b/main/linux-lts/APKBUILD index 52c8b1dde02..9ee394324b1 100644 --- a/main/linux-lts/APKBUILD +++ b/main/linux-lts/APKBUILD @@ -7,7 +7,7 @@ case $pkgver in *.*.*) _kernver=${pkgver%.*};; *.*) _kernver=$pkgver;; esac -pkgrel=0 +pkgrel=1 pkgdesc="Linux lts kernel" url="https://www.kernel.org" depends="initramfs-generator" @@ -23,6 +23,8 @@ source="https://cdn.kernel.org/pub/linux/kernel/v${pkgver%%.*}.x/linux-$_kernver 0004-objtool-respect-AWK-setting.patch 0005-powerpc-config-defang-gcc-check-for-stack-protector-.patch + xsa448-linux.patch + lts.aarch64.config lts.armv7.config lts.x86.config @@ -58,8 +60,6 @@ arch="all !armhf !riscv64" license="GPL-2.0-only" # secfixes: -# 6.1.27-r3: -# - CVE-2023-32233 # 5.10.4-r0: # - CVE-2020-29568 # - CVE-2020-29569 @@ -69,6 +69,10 @@ license="GPL-2.0-only" # - CVE-2022-42720 # - CVE-2022-42721 # - CVE-2022-42722 +# 6.1.27-r3: +# - CVE-2023-32233 +# 6.6.13-r1: +# - CVE-46838 prepare() { if [ "$_kernver" != "$pkgver" ]; then @@ -341,6 +345,7 @@ sha512sums=" 75f232b6becee7d36d360ffaf2aaa837d13518f9ec620ca159bcb2a0e98eb18a77631406a9b44244ea0164a7ed59fad583823909681e9b894a012f9d13365b69 0003-kexec-add-kexec_load_disabled-boot-option.patch 2956050bb332411d00a285e9656618f2e34b631492bbc19bef54d83a6e91b8531f4e18830b9313cfe52fbf8a8ca6fb76cf55b3ddd146ca3b977046cf2fd10cad 0004-objtool-respect-AWK-setting.patch 4b16f15b47b5e5835b926126e39723f519290469517875cfb2d2b857a93ad1344f0d1ba4b255289e20f4da9c867647526b344f752981cee0a48c51577badac3f 0005-powerpc-config-defang-gcc-check-for-stack-protector-.patch +8ef2f4aa508fc7d741bab205f47a302bee9130ca630e1999d081c065cf2d25a039b5d0cf210d41bc71f05ed11b826f93cc4af3bfe3a229022150532321051b67 xsa448-linux.patch 9eb564f47906c375e7cf4bbc7d3b6d988c103c11eebc2c298b364c2804906e74968e652b3c6c071f9e572cfdba704f3f66cdefb894c084246a41d9c364f95909 lts.aarch64.config 6bec077be5d89334860ce6e5f2ad1f79101656ba0e8e8b9fa31365cb951c3c8c10ed82c7c92cb860e18b8d996f005e39826fde6efbe5d264edd249f6d8b4dfc9 lts.armv7.config 4d4a8f64eebdb9690bd9e9ed8e33b0f28424329448c176d0f8f4b08db4095708fc976624a11e037935bd864290e7b2b04f7bab92241d5cafacac2f78e3122a21 lts.x86.config diff --git a/main/linux-lts/xsa448-linux.patch b/main/linux-lts/xsa448-linux.patch new file mode 100644 index 00000000000..831b4a77976 --- /dev/null +++ b/main/linux-lts/xsa448-linux.patch @@ -0,0 +1,98 @@ +From: Jan Beulich +Subject: xen-netback: don't produce zero-size SKB frags + +While frontends may submit zero-size requests (wasting a precious slot), +core networking code as of at least 3ece782693c4b ("sock: skb_copy_ubufs +support for compound pages") can't deal with SKBs when they have all +zero-size fragments. Respond to empty requests right when populating +fragments; all further processing is fragment based and hence won't +encounter these empty requests anymore. + +In a way this should have been that way from the beginning: When no data +is to be transferred for a particular request, there's not even a point +in validating the respective grant ref. That's no different from e.g. +passing NULL into memcpy() when at the same time the size is 0. + +This is XSA-448 / CVE-2023-46838. + +Reported-by: Pratyush Yadav +Cc: stable@vger.kernel.org +Signed-off-by: Jan Beulich +Reviewed-by: Juergen Gross +Reviewed-by: Paul Durrant +Acked-by: Pratyush Yadav + +--- a/drivers/net/xen-netback/netback.c ++++ b/drivers/net/xen-netback/netback.c +@@ -463,12 +463,25 @@ static void xenvif_get_requests(struct x + } + + for (shinfo->nr_frags = 0; nr_slots > 0 && shinfo->nr_frags < MAX_SKB_FRAGS; +- shinfo->nr_frags++, gop++, nr_slots--) { ++ nr_slots--) { ++ if (unlikely(!txp->size)) { ++ unsigned long flags; ++ ++ spin_lock_irqsave(&queue->response_lock, flags); ++ make_tx_response(queue, txp, 0, XEN_NETIF_RSP_OKAY); ++ push_tx_responses(queue); ++ spin_unlock_irqrestore(&queue->response_lock, flags); ++ ++txp; ++ continue; ++ } ++ + index = pending_index(queue->pending_cons++); + pending_idx = queue->pending_ring[index]; + xenvif_tx_create_map_op(queue, pending_idx, txp, + txp == first ? extra_count : 0, gop); + frag_set_pending_idx(&frags[shinfo->nr_frags], pending_idx); ++ ++shinfo->nr_frags; ++ ++gop; + + if (txp == first) + txp = txfrags; +@@ -481,20 +494,39 @@ static void xenvif_get_requests(struct x + shinfo = skb_shinfo(nskb); + frags = shinfo->frags; + +- for (shinfo->nr_frags = 0; shinfo->nr_frags < nr_slots; +- shinfo->nr_frags++, txp++, gop++) { ++ for (shinfo->nr_frags = 0; shinfo->nr_frags < nr_slots; ++txp) { ++ if (unlikely(!txp->size)) { ++ unsigned long flags; ++ ++ spin_lock_irqsave(&queue->response_lock, flags); ++ make_tx_response(queue, txp, 0, ++ XEN_NETIF_RSP_OKAY); ++ push_tx_responses(queue); ++ spin_unlock_irqrestore(&queue->response_lock, ++ flags); ++ continue; ++ } ++ + index = pending_index(queue->pending_cons++); + pending_idx = queue->pending_ring[index]; + xenvif_tx_create_map_op(queue, pending_idx, txp, 0, + gop); + frag_set_pending_idx(&frags[shinfo->nr_frags], + pending_idx); ++ ++shinfo->nr_frags; ++ ++gop; + } + +- skb_shinfo(skb)->frag_list = nskb; +- } else if (nskb) { ++ if (shinfo->nr_frags) { ++ skb_shinfo(skb)->frag_list = nskb; ++ nskb = NULL; ++ } ++ } ++ ++ if (nskb) { + /* A frag_list skb was allocated but it is no longer needed +- * because enough slots were converted to copy ops above. ++ * because enough slots were converted to copy ops above or some ++ * were empty. + */ + kfree_skb(nskb); + }