From: Greg Kroah-Hartman Date: Mon, 7 Nov 2022 09:00:16 +0000 (+0100) Subject: 5.15-stable patches X-Git-Tag: v4.9.333~62 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=d988c48e1ed597056a3469e71f20e3e77b9b5d49;p=thirdparty%2Fkernel%2Fstable-queue.git 5.15-stable patches added patches: af_unix-fix-memory-leaks-of-the-whole-sk-due-to-oob-skb.patch block-bfq-protect-bfqd-queued-by-bfqd-lock.patch bluetooth-l2cap-fix-accepting-connection-request-for-invalid-spsm.patch bluetooth-l2cap-fix-attempting-to-access-uninitialized-memory.patch --- diff --git a/queue-5.15/af_unix-fix-memory-leaks-of-the-whole-sk-due-to-oob-skb.patch b/queue-5.15/af_unix-fix-memory-leaks-of-the-whole-sk-due-to-oob-skb.patch new file mode 100644 index 00000000000..3019ff90e7f --- /dev/null +++ b/queue-5.15/af_unix-fix-memory-leaks-of-the-whole-sk-due-to-oob-skb.patch @@ -0,0 +1,98 @@ +From 7a62ed61367b8fd01bae1e18e30602c25060d824 Mon Sep 17 00:00:00 2001 +From: Kuniyuki Iwashima +Date: Thu, 29 Sep 2022 08:52:04 -0700 +Subject: af_unix: Fix memory leaks of the whole sk due to OOB skb. + +From: Kuniyuki Iwashima + +commit 7a62ed61367b8fd01bae1e18e30602c25060d824 upstream. + +syzbot reported a sequence of memory leaks, and one of them indicated we +failed to free a whole sk: + + unreferenced object 0xffff8880126e0000 (size 1088): + comm "syz-executor419", pid 326, jiffies 4294773607 (age 12.609s) + hex dump (first 32 bytes): + 00 00 00 00 00 00 00 00 7d 00 00 00 00 00 00 00 ........}....... + 01 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ + backtrace: + [<000000006fefe750>] sk_prot_alloc+0x64/0x2a0 net/core/sock.c:1970 + [<0000000074006db5>] sk_alloc+0x3b/0x800 net/core/sock.c:2029 + [<00000000728cd434>] unix_create1+0xaf/0x920 net/unix/af_unix.c:928 + [<00000000a279a139>] unix_create+0x113/0x1d0 net/unix/af_unix.c:997 + [<0000000068259812>] __sock_create+0x2ab/0x550 net/socket.c:1516 + [<00000000da1521e1>] sock_create net/socket.c:1566 [inline] + [<00000000da1521e1>] __sys_socketpair+0x1a8/0x550 net/socket.c:1698 + [<000000007ab259e1>] __do_sys_socketpair net/socket.c:1751 [inline] + [<000000007ab259e1>] __se_sys_socketpair net/socket.c:1748 [inline] + [<000000007ab259e1>] __x64_sys_socketpair+0x97/0x100 net/socket.c:1748 + [<000000007dedddc1>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] + [<000000007dedddc1>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 + [<000000009456679f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd + +We can reproduce this issue by creating two AF_UNIX SOCK_STREAM sockets, +send()ing an OOB skb to each other, and close()ing them without consuming +the OOB skbs. + + int skpair[2]; + + socketpair(AF_UNIX, SOCK_STREAM, 0, skpair); + + send(skpair[0], "x", 1, MSG_OOB); + send(skpair[1], "x", 1, MSG_OOB); + + close(skpair[0]); + close(skpair[1]); + +Currently, we free an OOB skb in unix_sock_destructor() which is called via +__sk_free(), but it's too late because the receiver's unix_sk(sk)->oob_skb +is accounted against the sender's sk->sk_wmem_alloc and __sk_free() is +called only when sk->sk_wmem_alloc is 0. + +In the repro sequences, we do not consume the OOB skb, so both two sk's +sock_put() never reach __sk_free() due to the positive sk->sk_wmem_alloc. +Then, no one can consume the OOB skb nor call __sk_free(), and we finally +leak the two whole sk. + +Thus, we must free the unconsumed OOB skb earlier when close()ing the +socket. + +Fixes: 314001f0bf92 ("af_unix: Add OOB support") +Reported-by: syzbot +Signed-off-by: Kuniyuki Iwashima +Signed-off-by: David S. Miller +Signed-off-by: Anil Altinay +Signed-off-by: Greg Kroah-Hartman +--- + net/unix/af_unix.c | 13 +++++++------ + 1 file changed, 7 insertions(+), 6 deletions(-) + +--- a/net/unix/af_unix.c ++++ b/net/unix/af_unix.c +@@ -504,12 +504,6 @@ static void unix_sock_destructor(struct + + skb_queue_purge(&sk->sk_receive_queue); + +-#if IS_ENABLED(CONFIG_AF_UNIX_OOB) +- if (u->oob_skb) { +- kfree_skb(u->oob_skb); +- u->oob_skb = NULL; +- } +-#endif + WARN_ON(refcount_read(&sk->sk_wmem_alloc)); + WARN_ON(!sk_unhashed(sk)); + WARN_ON(sk->sk_socket); +@@ -556,6 +550,13 @@ static void unix_release_sock(struct soc + + unix_state_unlock(sk); + ++#if IS_ENABLED(CONFIG_AF_UNIX_OOB) ++ if (u->oob_skb) { ++ kfree_skb(u->oob_skb); ++ u->oob_skb = NULL; ++ } ++#endif ++ + wake_up_interruptible_all(&u->peer_wait); + + if (skpair != NULL) { diff --git a/queue-5.15/block-bfq-protect-bfqd-queued-by-bfqd-lock.patch b/queue-5.15/block-bfq-protect-bfqd-queued-by-bfqd-lock.patch new file mode 100644 index 00000000000..4bb3df7d98d --- /dev/null +++ b/queue-5.15/block-bfq-protect-bfqd-queued-by-bfqd-lock.patch @@ -0,0 +1,47 @@ +From 181490d5321806e537dc5386db5ea640b826bf78 Mon Sep 17 00:00:00 2001 +From: Yu Kuai +Date: Fri, 13 May 2022 10:35:06 +0800 +Subject: block, bfq: protect 'bfqd->queued' by 'bfqd->lock' + +From: Yu Kuai + +commit 181490d5321806e537dc5386db5ea640b826bf78 upstream. + +If bfq_schedule_dispatch() is called from bfq_idle_slice_timer_body(), +then 'bfqd->queued' is read without holding 'bfqd->lock'. This is +wrong since it can be wrote concurrently. + +Fix the problem by holding 'bfqd->lock' in such case. + +Signed-off-by: Yu Kuai +Reviewed-by: Jan Kara +Reviewed-by: Chaitanya Kulkarni +Link: https://lore.kernel.org/r/20220513023507.2625717-2-yukuai3@huawei.com +Signed-off-by: Jens Axboe +Cc: Khazhy Kumykov +Signed-off-by: Greg Kroah-Hartman +--- + block/bfq-iosched.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/block/bfq-iosched.c ++++ b/block/bfq-iosched.c +@@ -461,6 +461,8 @@ static struct bfq_io_cq *bfq_bic_lookup( + */ + void bfq_schedule_dispatch(struct bfq_data *bfqd) + { ++ lockdep_assert_held(&bfqd->lock); ++ + if (bfqd->queued != 0) { + bfq_log(bfqd, "schedule dispatch"); + blk_mq_run_hw_queues(bfqd->queue, true); +@@ -6745,8 +6747,8 @@ bfq_idle_slice_timer_body(struct bfq_dat + bfq_bfqq_expire(bfqd, bfqq, true, reason); + + schedule_dispatch: +- spin_unlock_irqrestore(&bfqd->lock, flags); + bfq_schedule_dispatch(bfqd); ++ spin_unlock_irqrestore(&bfqd->lock, flags); + } + + /* diff --git a/queue-5.15/bluetooth-l2cap-fix-accepting-connection-request-for-invalid-spsm.patch b/queue-5.15/bluetooth-l2cap-fix-accepting-connection-request-for-invalid-spsm.patch new file mode 100644 index 00000000000..9c531af90e7 --- /dev/null +++ b/queue-5.15/bluetooth-l2cap-fix-accepting-connection-request-for-invalid-spsm.patch @@ -0,0 +1,70 @@ +From 711f8c3fb3db61897080468586b970c87c61d9e4 Mon Sep 17 00:00:00 2001 +From: Luiz Augusto von Dentz +Date: Mon, 31 Oct 2022 16:10:32 -0700 +Subject: Bluetooth: L2CAP: Fix accepting connection request for invalid SPSM +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Luiz Augusto von Dentz + +commit 711f8c3fb3db61897080468586b970c87c61d9e4 upstream. + +The Bluetooth spec states that the valid range for SPSM is from +0x0001-0x00ff so it is invalid to accept values outside of this range: + + BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part A + page 1059: + Table 4.15: L2CAP_LE_CREDIT_BASED_CONNECTION_REQ SPSM ranges + +CVE: CVE-2022-42896 +CC: stable@vger.kernel.org +Reported-by: Tamás Koczka +Signed-off-by: Luiz Augusto von Dentz +Reviewed-by: Tedd Ho-Jeong An +Signed-off-by: Greg Kroah-Hartman +--- + net/bluetooth/l2cap_core.c | 25 +++++++++++++++++++++++++ + 1 file changed, 25 insertions(+) + +--- a/net/bluetooth/l2cap_core.c ++++ b/net/bluetooth/l2cap_core.c +@@ -5813,6 +5813,19 @@ static int l2cap_le_connect_req(struct l + BT_DBG("psm 0x%2.2x scid 0x%4.4x mtu %u mps %u", __le16_to_cpu(psm), + scid, mtu, mps); + ++ /* BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part A ++ * page 1059: ++ * ++ * Valid range: 0x0001-0x00ff ++ * ++ * Table 4.15: L2CAP_LE_CREDIT_BASED_CONNECTION_REQ SPSM ranges ++ */ ++ if (!psm || __le16_to_cpu(psm) > L2CAP_PSM_LE_DYN_END) { ++ result = L2CAP_CR_LE_BAD_PSM; ++ chan = NULL; ++ goto response; ++ } ++ + /* Check if we have socket listening on psm */ + pchan = l2cap_global_chan_by_psm(BT_LISTEN, psm, &conn->hcon->src, + &conn->hcon->dst, LE_LINK); +@@ -6001,6 +6014,18 @@ static inline int l2cap_ecred_conn_req(s + + psm = req->psm; + ++ /* BLUETOOTH CORE SPECIFICATION Version 5.3 | Vol 3, Part A ++ * page 1059: ++ * ++ * Valid range: 0x0001-0x00ff ++ * ++ * Table 4.15: L2CAP_LE_CREDIT_BASED_CONNECTION_REQ SPSM ranges ++ */ ++ if (!psm || __le16_to_cpu(psm) > L2CAP_PSM_LE_DYN_END) { ++ result = L2CAP_CR_LE_BAD_PSM; ++ goto response; ++ } ++ + BT_DBG("psm 0x%2.2x mtu %u mps %u", __le16_to_cpu(psm), mtu, mps); + + memset(&pdu, 0, sizeof(pdu)); diff --git a/queue-5.15/bluetooth-l2cap-fix-attempting-to-access-uninitialized-memory.patch b/queue-5.15/bluetooth-l2cap-fix-attempting-to-access-uninitialized-memory.patch new file mode 100644 index 00000000000..1d0a9540333 --- /dev/null +++ b/queue-5.15/bluetooth-l2cap-fix-attempting-to-access-uninitialized-memory.patch @@ -0,0 +1,37 @@ +From b1a2cd50c0357f243b7435a732b4e62ba3157a2e Mon Sep 17 00:00:00 2001 +From: Luiz Augusto von Dentz +Date: Mon, 31 Oct 2022 16:10:52 -0700 +Subject: Bluetooth: L2CAP: Fix attempting to access uninitialized memory +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Luiz Augusto von Dentz + +commit b1a2cd50c0357f243b7435a732b4e62ba3157a2e upstream. + +On l2cap_parse_conf_req the variable efs is only initialized if +remote_efs has been set. + +CVE: CVE-2022-42895 +CC: stable@vger.kernel.org +Reported-by: Tamás Koczka +Signed-off-by: Luiz Augusto von Dentz +Reviewed-by: Tedd Ho-Jeong An +Signed-off-by: Greg Kroah-Hartman +--- + net/bluetooth/l2cap_core.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/net/bluetooth/l2cap_core.c ++++ b/net/bluetooth/l2cap_core.c +@@ -3764,7 +3764,8 @@ done: + l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC, + sizeof(rfc), (unsigned long) &rfc, endptr - ptr); + +- if (test_bit(FLAG_EFS_ENABLE, &chan->flags)) { ++ if (remote_efs && ++ test_bit(FLAG_EFS_ENABLE, &chan->flags)) { + chan->remote_id = efs.id; + chan->remote_stype = efs.stype; + chan->remote_msdu = le16_to_cpu(efs.msdu); diff --git a/queue-5.15/series b/queue-5.15/series index f89963655b7..eab25288973 100644 --- a/queue-5.15/series +++ b/queue-5.15/series @@ -95,3 +95,7 @@ firmware-arm_scmi-make-rx-chan_setup-fail-on-memory-.patch firmware-arm_scmi-fix-devres-allocation-device-in-vi.patch arm64-dts-juno-add-thermal-critical-trip-points.patch i2c-piix4-fix-adapter-not-be-removed-in-piix4_remove.patch +bluetooth-l2cap-fix-accepting-connection-request-for-invalid-spsm.patch +bluetooth-l2cap-fix-attempting-to-access-uninitialized-memory.patch +block-bfq-protect-bfqd-queued-by-bfqd-lock.patch +af_unix-fix-memory-leaks-of-the-whole-sk-due-to-oob-skb.patch