diff options
Diffstat (limited to 'debian/patches/bugfix')
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 + |