Merging debian version 6.1.82-1.

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

9 files changed, 465 insertions, 0 deletions

diff --git a/debian/patches/bugfix/all/Bluetooth-rfcomm-Fix-null-ptr-deref-in-rfcomm_check_.patch b/debian/patches/bugfix/all/Bluetooth-rfcomm-Fix-null-ptr-deref-in-rfcomm_check_.patch
new file mode 100644
index 000000000..258ab6ea4
--- /dev/null
+++ b/debian/patches/bugfix/all/Bluetooth-rfcomm-Fix-null-ptr-deref-in-rfcomm_check_.patch
@@ -0,0 +1,57 @@
+From: Yuxuan Hu <20373622@buaa.edu.cn>
+Date: Wed, 3 Jan 2024 17:10:43 +0800
+Subject: Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security
+Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit?id=567c0411dc3b424fc7bd1e6109726d7ba32d4f73
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-22099
+
+[ Upstream commit 2535b848fa0f42ddff3e5255cf5e742c9b77bb26 ]
+
+During our fuzz testing of the connection and disconnection process at the
+RFCOMM layer, we discovered this bug. By comparing the packets from a
+normal connection and disconnection process with the testcase that
+triggered a KASAN report. We analyzed the cause of this bug as follows:
+
+1. In the packets captured during a normal connection, the host sends a
+`Read Encryption Key Size` type of `HCI_CMD` packet
+(Command Opcode: 0x1408) to the controller to inquire the length of
+encryption key.After receiving this packet, the controller immediately
+replies with a Command Completepacket (Event Code: 0x0e) to return the
+Encryption Key Size.
+
+2. In our fuzz test case, the timing of the controller's response to this
+packet was delayed to an unexpected point: after the RFCOMM and L2CAP
+layers had disconnected but before the HCI layer had disconnected.
+
+3. After receiving the Encryption Key Size Response at the time described
+in point 2, the host still called the rfcomm_check_security function.
+However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)->chan->conn;`
+had already been released, and when the function executed
+`return hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`,
+specifically when accessing `conn->hcon`, a null-ptr-deref error occurred.
+
+To fix this bug, check if `sk->sk_state` is BT_CLOSED before calling
+rfcomm_recv_frame in rfcomm_process_rx.
+
+Signed-off-by: Yuxuan Hu <20373622@buaa.edu.cn>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/bluetooth/rfcomm/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
+index 8d6fce9005bd..4f54c7df3a94 100644
+--- a/net/bluetooth/rfcomm/core.c
++++ b/net/bluetooth/rfcomm/core.c
+@@ -1937,7 +1937,7 @@ static struct rfcomm_session *rfcomm_process_rx(struct rfcomm_session *s)
+ 	/* Get data directly from socket receive queue without copying it. */
+ 	while ((skb = skb_dequeue(&sk->sk_receive_queue))) {
+ 		skb_orphan(skb);
+-		if (!skb_linearize(skb)) {
++		if (!skb_linearize(skb) && sk->sk_state != BT_CLOSED) {
+ 			s = rfcomm_recv_frame(s, skb);
+ 			if (!s)
+ 				break;
+-- 
+2.43.0
+
diff --git a/debian/patches/bugfix/all/aoe-fix-the-potential-use-after-free-problem-in-aoec.patch b/debian/patches/bugfix/all/aoe-fix-the-potential-use-after-free-problem-in-aoec.patch
new file mode 100644
index 000000000..f5cc88309
--- /dev/null
+++ b/debian/patches/bugfix/all/aoe-fix-the-potential-use-after-free-problem-in-aoec.patch
@@ -0,0 +1,87 @@
+From: Chun-Yi Lee <jlee@suse.com>
+Date: Tue, 5 Mar 2024 16:20:48 +0800
+Subject: aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts
+Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit?id=74ca3ef68d2f449bc848c0a814cefc487bf755fa
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-6270
+
+[ Upstream commit f98364e926626c678fb4b9004b75cacf92ff0662 ]
+
+This patch is against CVE-2023-6270. The description of cve is:
+
+  A flaw was found in the ATA over Ethernet (AoE) driver in the Linux
+  kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on
+  `struct net_device`, and a use-after-free can be triggered by racing
+  between the free on the struct and the access through the `skbtxq`
+  global queue. This could lead to a denial of service condition or
+  potential code execution.
+
+In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial
+code is finished. But the net_device ifp will still be used in
+later tx()->dev_queue_xmit() in kthread. Which means that the
+dev_put(ifp) should NOT be called in the success path of skb
+initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into
+use-after-free because the net_device is freed.
+
+This patch removed the dev_put(ifp) in the success path in
+aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().
+
+Link: https://nvd.nist.gov/vuln/detail/CVE-2023-6270
+Fixes: 7562f876cd93 ("[NET]: Rework dev_base via list_head (v3)")
+Signed-off-by: Chun-Yi Lee <jlee@suse.com>
+Link: https://lore.kernel.org/r/20240305082048.25526-1-jlee@suse.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/block/aoe/aoecmd.c | 12 ++++++------
+ drivers/block/aoe/aoenet.c |  1 +
+ 2 files changed, 7 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
+index d7317425be51..cc9077b588d7 100644
+--- a/drivers/block/aoe/aoecmd.c
++++ b/drivers/block/aoe/aoecmd.c
+@@ -419,13 +419,16 @@ aoecmd_cfg_pkts(ushort aoemajor, unsigned char aoeminor, struct sk_buff_head *qu
+ 	rcu_read_lock();
+ 	for_each_netdev_rcu(&init_net, ifp) {
+ 		dev_hold(ifp);
+-		if (!is_aoe_netif(ifp))
+-			goto cont;
++		if (!is_aoe_netif(ifp)) {
++			dev_put(ifp);
++			continue;
++		}
+ 
+ 		skb = new_skb(sizeof *h + sizeof *ch);
+ 		if (skb == NULL) {
+ 			printk(KERN_INFO "aoe: skb alloc failure\n");
+-			goto cont;
++			dev_put(ifp);
++			continue;
+ 		}
+ 		skb_put(skb, sizeof *h + sizeof *ch);
+ 		skb->dev = ifp;
+@@ -440,9 +443,6 @@ aoecmd_cfg_pkts(ushort aoemajor, unsigned char aoeminor, struct sk_buff_head *qu
+ 		h->major = cpu_to_be16(aoemajor);
+ 		h->minor = aoeminor;
+ 		h->cmd = AOECMD_CFG;
+-
+-cont:
+-		dev_put(ifp);
+ 	}
+ 	rcu_read_unlock();
+ }
+diff --git a/drivers/block/aoe/aoenet.c b/drivers/block/aoe/aoenet.c
+index 63773a90581d..1e66c7a188a1 100644
+--- a/drivers/block/aoe/aoenet.c
++++ b/drivers/block/aoe/aoenet.c
+@@ -64,6 +64,7 @@ tx(int id) __must_hold(&txlock)
+ 			pr_warn("aoe: packet could not be sent on %s.  %s\n",
+ 				ifp ? ifp->name : "netif",
+ 				"consider increasing tx_queue_len");
++		dev_put(ifp);
+ 		spin_lock_irq(&txlock);
+ 	}
+ 	return 0;
+-- 
+2.43.0
+
diff --git a/debian/patches/bugfix/all/efi-fix-panic-in-kdump-kernel.patch b/debian/patches/bugfix/all/efi-fix-panic-in-kdump-kernel.patch
new file mode 100644
index 000000000..009af084b
--- /dev/null
+++ b/debian/patches/bugfix/all/efi-fix-panic-in-kdump-kernel.patch
@@ -0,0 +1,34 @@
+From: Oleksandr Tymoshenko <ovt@google.com>
+Date: Sat, 23 Mar 2024 06:33:33 +0000
+Subject: efi: fix panic in kdump kernel
+Origin: https://git.kernel.org/linus/62b71cd73d41ddac6b1760402bbe8c4932e23531
+
+Check if get_next_variable() is actually valid pointer before
+calling it. In kdump kernel this method is set to NULL that causes
+panic during the kexec-ed kernel boot.
+
+Tested with QEMU and OVMF firmware.
+
+Fixes: bad267f9e18f ("efi: verify that variable services are supported")
+Signed-off-by: Oleksandr Tymoshenko <ovt@google.com>
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+---
+ drivers/firmware/efi/efi.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
+index 8859fb0b006d..fdf07dd6f459 100644
+--- a/drivers/firmware/efi/efi.c
++++ b/drivers/firmware/efi/efi.c
+@@ -203,6 +203,8 @@ static bool generic_ops_supported(void)
+ 
+ 	name_size = sizeof(name);
+ 
++	if (!efi.get_next_variable)
++		return false;
+ 	status = efi.get_next_variable(&name_size, &name, &guid);
+ 	if (status == EFI_UNSUPPORTED)
+ 		return false;
+-- 
+2.43.0
+
diff --git a/debian/patches/bugfix/all/efi-libstub-Cast-away-type-warning-in-use-of-max.patch b/debian/patches/bugfix/all/efi-libstub-Cast-away-type-warning-in-use-of-max.patch
new file mode 100644
index 000000000..402582b17
--- /dev/null
+++ b/debian/patches/bugfix/all/efi-libstub-Cast-away-type-warning-in-use-of-max.patch
@@ -0,0 +1,30 @@
+From: Ard Biesheuvel <ardb@kernel.org>
+Date: Tue, 26 Mar 2024 11:15:25 +0100
+Subject: efi/libstub: Cast away type warning in use of max()
+Origin: https://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git/commit?id=07263d8a5a2cea66a3f10d930fea60ce49c7dc3b
+
+Add a missing (u64) cast to alloc_min, which is passed into
+efi_random_alloc() as unsigned long, while efi_physical_addr_t is u64.
+
+Fixes: 3cb4a4827596abc82e ("efi/libstub: fix efi_random_alloc() ...")
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+---
+ drivers/firmware/efi/libstub/randomalloc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/firmware/efi/libstub/randomalloc.c b/drivers/firmware/efi/libstub/randomalloc.c
+index 7e1852859550..fa81528150fe 100644
+--- a/drivers/firmware/efi/libstub/randomalloc.c
++++ b/drivers/firmware/efi/libstub/randomalloc.c
+@@ -120,7 +120,7 @@ efi_status_t efi_random_alloc(unsigned long size,
+ 			continue;
+ 		}
+ 
+-		target = round_up(max(md->phys_addr, alloc_min), align) + target_slot * align;
++		target = round_up(max(md->phys_addr, (u64)alloc_min), align) + target_slot * align;
+ 		pages = size / EFI_PAGE_SIZE;
+ 
+ 		status = efi_bs_call(allocate_pages, EFI_ALLOCATE_ADDRESS,
+-- 
+2.43.0
+
diff --git a/debian/patches/bugfix/all/efi-libstub-fix-efi_random_alloc-to-allocate-memory-.patch b/debian/patches/bugfix/all/efi-libstub-fix-efi_random_alloc-to-allocate-memory-.patch
new file mode 100644
index 000000000..d5590f5db
--- /dev/null
+++ b/debian/patches/bugfix/all/efi-libstub-fix-efi_random_alloc-to-allocate-memory-.patch
@@ -0,0 +1,68 @@
+From: =?UTF-8?q?KONDO=20KAZUMA=28=E8=BF=91=E8=97=A4=E3=80=80=E5=92=8C?=
+ =?UTF-8?q?=E7=9C=9F=29?= <kazuma-kondo@nec.com>
+Date: Fri, 22 Mar 2024 10:47:02 +0000
+Subject: efi/libstub: fix efi_random_alloc() to allocate memory at alloc_min
+ or higher address
+Origin: https://git.kernel.org/linus/3cb4a4827596abc82e55b80364f509d0fefc3051
+
+Following warning is sometimes observed while booting my servers:
+  [    3.594838] DMA: preallocated 4096 KiB GFP_KERNEL pool for atomic allocations
+  [    3.602918] swapper/0: page allocation failure: order:10, mode:0xcc1(GFP_KERNEL|GFP_DMA), nodemask=(null),cpuset=/,mems_allowed=0-1
+  ...
+  [    3.851862] DMA: preallocated 1024 KiB GFP_KERNEL|GFP_DMA pool for atomic allocation
+
+If 'nokaslr' boot option is set, the warning always happens.
+
+On x86, ZONE_DMA is small zone at the first 16MB of physical address
+space. When this problem happens, most of that space seems to be used by
+decompressed kernel. Thereby, there is not enough space at DMA_ZONE to
+meet the request of DMA pool allocation.
+
+The commit 2f77465b05b1 ("x86/efistub: Avoid placing the kernel below
+LOAD_PHYSICAL_ADDR") tried to fix this problem by introducing lower
+bound of allocation.
+
+But the fix is not complete.
+
+efi_random_alloc() allocates pages by following steps.
+1. Count total available slots ('total_slots')
+2. Select a slot ('target_slot') to allocate randomly
+3. Calculate a starting address ('target') to be included target_slot
+4. Allocate pages, which starting address is 'target'
+
+In step 1, 'alloc_min' is used to offset the starting address of memory
+chunk. But in step 3 'alloc_min' is not considered at all.  As the
+result, 'target' can be miscalculated and become lower than 'alloc_min'.
+
+When KASLR is disabled, 'target_slot' is always 0 and the problem
+happens everytime if the EFI memory map of the system meets the
+condition.
+
+Fix this problem by calculating 'target' considering 'alloc_min'.
+
+Cc: linux-efi@vger.kernel.org
+Cc: Tom Englund <tomenglund26@gmail.com>
+Cc: linux-kernel@vger.kernel.org
+Fixes: 2f77465b05b1 ("x86/efistub: Avoid placing the kernel below LOAD_PHYSICAL_ADDR")
+Signed-off-by: Kazuma Kondo <kazuma-kondo@nec.com>
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+---
+ drivers/firmware/efi/libstub/randomalloc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/firmware/efi/libstub/randomalloc.c b/drivers/firmware/efi/libstub/randomalloc.c
+index 4e96a855fdf4..7e1852859550 100644
+--- a/drivers/firmware/efi/libstub/randomalloc.c
++++ b/drivers/firmware/efi/libstub/randomalloc.c
+@@ -120,7 +120,7 @@ efi_status_t efi_random_alloc(unsigned long size,
+ 			continue;
+ 		}
+ 
+-		target = round_up(md->phys_addr, align) + target_slot * align;
++		target = round_up(max(md->phys_addr, alloc_min), align) + target_slot * align;
+ 		pages = size / EFI_PAGE_SIZE;
+ 
+ 		status = efi_bs_call(allocate_pages, EFI_ALLOCATE_ADDRESS,
+-- 
+2.43.0
+
diff --git a/debian/patches/bugfix/all/sr9800-Add-check-for-usbnet_get_endpoints.patch b/debian/patches/bugfix/all/sr9800-Add-check-for-usbnet_get_endpoints.patch
new file mode 100644
index 000000000..ac7fb2e3e
--- /dev/null
+++ b/debian/patches/bugfix/all/sr9800-Add-check-for-usbnet_get_endpoints.patch
@@ -0,0 +1,39 @@
+From: Chen Ni <nichen@iscas.ac.cn>
+Date: Tue, 5 Mar 2024 07:59:27 +0000
+Subject: sr9800: Add check for usbnet_get_endpoints
+Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit?id=9c402819620a842cbfe39359a3ddfaac9adc8384
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2024-26651
+
+[ Upstream commit 07161b2416f740a2cb87faa5566873f401440a61 ]
+
+Add check for usbnet_get_endpoints() and return the error if it fails
+in order to transfer the error.
+
+Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Fixes: 19a38d8e0aa3 ("USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 Device Driver Support")
+Link: https://lore.kernel.org/r/20240305075927.261284-1-nichen@iscas.ac.cn
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/usb/sr9800.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/usb/sr9800.c b/drivers/net/usb/sr9800.c
+index f5e19f3ef6cd..4de514482183 100644
+--- a/drivers/net/usb/sr9800.c
++++ b/drivers/net/usb/sr9800.c
+@@ -737,7 +737,9 @@ static int sr9800_bind(struct usbnet *dev, struct usb_interface *intf)
+ 
+ 	data->eeprom_len = SR9800_EEPROM_LEN;
+ 
+-	usbnet_get_endpoints(dev, intf);
++	ret = usbnet_get_endpoints(dev, intf);
++	if (ret)
++		goto out;
+ 
+ 	/* LED Setting Rule :
+ 	 * AABB:CCDD
+-- 
+2.43.0
+
diff --git a/debian/patches/bugfix/all/wifi-ath10k-fix-NULL-pointer-dereference-in-ath10k_w.patch b/debian/patches/bugfix/all/wifi-ath10k-fix-NULL-pointer-dereference-in-ath10k_w.patch
new file mode 100644
index 000000000..2747ec5b6
--- /dev/null
+++ b/debian/patches/bugfix/all/wifi-ath10k-fix-NULL-pointer-dereference-in-ath10k_w.patch
@@ -0,0 +1,41 @@
+From: Xingyuan Mo <hdthky0@gmail.com>
+Date: Sun, 17 Dec 2023 13:29:01 +0200
+Subject: wifi: ath10k: fix NULL pointer dereference in
+ ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev()
+Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit?id=90f089d77e38db1c48629f111f3c8c336be1bc38
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2023-7042
+
+[ Upstream commit ad25ee36f00172f7d53242dc77c69fff7ced0755 ]
+
+We should check whether the WMI_TLV_TAG_STRUCT_MGMT_TX_COMPL_EVENT tlv is
+present before accessing it, otherwise a null pointer deference error will
+occur.
+
+Fixes: dc405152bb64 ("ath10k: handle mgmt tx completion event")
+Signed-off-by: Xingyuan Mo <hdthky0@gmail.com>
+Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
+Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
+Link: https://msgid.link/20231208043433.271449-1-hdthky0@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/wireless/ath/ath10k/wmi-tlv.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+index 876410a47d1d..4d5009604eee 100644
+--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
++++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+@@ -844,6 +844,10 @@ ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev(struct ath10k *ar, struct sk_buff *skb,
+ 	}
+ 
+ 	ev = tb[WMI_TLV_TAG_STRUCT_MGMT_TX_COMPL_EVENT];
++	if (!ev) {
++		kfree(tb);
++		return -EPROTO;
++	}
+ 
+ 	arg->desc_id = ev->desc_id;
+ 	arg->status = ev->status;
+-- 
+2.43.0
+
diff --git a/debian/patches/bugfix/x86/x86-efistub-Clear-decompressor-BSS-in-native-EFI-ent.patch b/debian/patches/bugfix/x86/x86-efistub-Clear-decompressor-BSS-in-native-EFI-ent.patch
new file mode 100644
index 000000000..63c4cafae
--- /dev/null
+++ b/debian/patches/bugfix/x86/x86-efistub-Clear-decompressor-BSS-in-native-EFI-ent.patch
@@ -0,0 +1,68 @@
+From: Ard Biesheuvel <ardb@kernel.org>
+Date: Fri, 15 Mar 2024 16:26:16 +0100
+Subject: x86/efistub: Clear decompressor BSS in native EFI entrypoint
+Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit?id=9274ec2003042bf0ed847cb80ffcfab543a0a33a
+
+[ Upstream commit b3810c5a2cc4a6665f7a65bed5393c75ce3f3aa2 ]
+
+The EFI stub on x86 no longer invokes the decompressor as a subsequent
+boot stage, but calls into the decompression code directly while running
+in the context of the EFI boot services.
+
+This means that when using the native EFI entrypoint (as opposed to the
+EFI handover protocol, which clears BSS explicitly), the firmware PE
+image loader is being relied upon to ensure that BSS is zeroed before
+the EFI stub is entered from the firmware.
+
+As Radek's report proves, this is a bad idea. Not all loaders do this
+correctly, which means some global variables that should be statically
+initialized to 0x0 may have junk in them.
+
+So clear BSS explicitly when entering via efi_pe_entry(). Note that
+zeroing BSS from C code is not generally safe, but in this case, the
+following assignment and dereference of a global pointer variable
+ensures that the memset() cannot be deferred or reordered.
+
+Cc: <stable@kernel.org> # v6.1+
+Reported-by: Radek Podgorny <radek@podgorny.cz>
+Closes: https://lore.kernel.org/all/a99a831a-8ad5-4cb0-bff9-be637311f771@podgorny.cz
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/firmware/efi/libstub/x86-stub.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
+index 784e1b2ae5cc..aa07051459f5 100644
+--- a/drivers/firmware/efi/libstub/x86-stub.c
++++ b/drivers/firmware/efi/libstub/x86-stub.c
+@@ -21,6 +21,8 @@
+ #include "efistub.h"
+ #include "x86-stub.h"
+ 
++extern char _bss[], _ebss[];
++
+ const efi_system_table_t *efi_system_table;
+ const efi_dxe_services_table_t *efi_dxe_table;
+ static efi_loaded_image_t *image = NULL;
+@@ -432,6 +434,8 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
+ 	efi_status_t status;
+ 	char *cmdline_ptr;
+ 
++	memset(_bss, 0, _ebss - _bss);
++
+ 	efi_system_table = sys_table_arg;
+ 
+ 	/* Check if we were booted by the EFI firmware */
+@@ -950,8 +954,6 @@ void __noreturn efi_stub_entry(efi_handle_t handle,
+ void efi_handover_entry(efi_handle_t handle, efi_system_table_t *sys_table_arg,
+ 			struct boot_params *boot_params)
+ {
+-	extern char _bss[], _ebss[];
+-
+ 	memset(_bss, 0, _ebss - _bss);
+ 	efi_stub_entry(handle, sys_table_arg, boot_params);
+ }
+-- 
+2.43.0
+
diff --git a/debian/patches/bugfix/x86/x86-efistub-Don-t-clear-BSS-twice-in-mixed-mode.patch b/debian/patches/bugfix/x86/x86-efistub-Don-t-clear-BSS-twice-in-mixed-mode.patch
new file mode 100644
index 000000000..2624812c5
--- /dev/null
+++ b/debian/patches/bugfix/x86/x86-efistub-Don-t-clear-BSS-twice-in-mixed-mode.patch
@@ -0,0 +1,41 @@
+From: Ard Biesheuvel <ardb@kernel.org>
+Date: Fri, 22 Mar 2024 17:01:45 +0100
+Subject: x86/efistub: Don't clear BSS twice in mixed mode
+Origin: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit?id=3a2a828d252f4280e15e61e0666644f1fadcf6c4
+
+[ Upstream commit df7ecce842b846a04d087ba85fdb79a90e26a1b0 ]
+
+Clearing BSS should only be done once, at the very beginning.
+efi_pe_entry() is the entrypoint from the firmware, which may not clear
+BSS and so it is done explicitly. However, efi_pe_entry() is also used
+as an entrypoint by the mixed mode startup code, in which case BSS will
+already have been cleared, and doing it again at this point will corrupt
+global variables holding the firmware's GDT/IDT and segment selectors.
+
+So make the memset() conditional on whether the EFI stub is running in
+native mode.
+
+Fixes: b3810c5a2cc4a666 ("x86/efistub: Clear decompressor BSS in native EFI entrypoint")
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/firmware/efi/libstub/x86-stub.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
+index aa07051459f5..dc50dda40239 100644
+--- a/drivers/firmware/efi/libstub/x86-stub.c
++++ b/drivers/firmware/efi/libstub/x86-stub.c
+@@ -434,7 +434,8 @@ efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
+ 	efi_status_t status;
+ 	char *cmdline_ptr;
+ 
+-	memset(_bss, 0, _ebss - _bss);
++	if (efi_is_native())
++		memset(_bss, 0, _ebss - _bss);
+ 
+ 	efi_system_table = sys_table_arg;
+ 
+-- 
+2.43.0
+