summaryrefslogtreecommitdiffstats
path: root/debian/patches/bugfix/all
diff options
context:
space:
mode:
Diffstat (limited to 'debian/patches/bugfix/all')
-rw-r--r--debian/patches/bugfix/all/Bluetooth-rfcomm-Fix-null-ptr-deref-in-rfcomm_check_.patch57
-rw-r--r--debian/patches/bugfix/all/aoe-fix-the-potential-use-after-free-problem-in-aoec.patch87
-rw-r--r--debian/patches/bugfix/all/efi-fix-panic-in-kdump-kernel.patch34
-rw-r--r--debian/patches/bugfix/all/efi-libstub-Cast-away-type-warning-in-use-of-max.patch30
-rw-r--r--debian/patches/bugfix/all/efi-libstub-fix-efi_random_alloc-to-allocate-memory-.patch68
-rw-r--r--debian/patches/bugfix/all/sr9800-Add-check-for-usbnet_get_endpoints.patch39
-rw-r--r--debian/patches/bugfix/all/wifi-ath10k-fix-NULL-pointer-dereference-in-ath10k_w.patch41
7 files changed, 356 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
+