--- /dev/null
+From 7a62ed61367b8fd01bae1e18e30602c25060d824 Mon Sep 17 00:00:00 2001
+From: Kuniyuki Iwashima <kuniyu@amazon.com>
+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 <kuniyu@amazon.com>
+
+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 <syzkaller@googlegroups.com>
+Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Anil Altinay <aaltinay@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) {
--- /dev/null
+From 181490d5321806e537dc5386db5ea640b826bf78 Mon Sep 17 00:00:00 2001
+From: Yu Kuai <yukuai3@huawei.com>
+Date: Fri, 13 May 2022 10:35:06 +0800
+Subject: block, bfq: protect 'bfqd->queued' by 'bfqd->lock'
+
+From: Yu Kuai <yukuai3@huawei.com>
+
+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 <yukuai3@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com>
+Link: https://lore.kernel.org/r/20220513023507.2625717-2-yukuai3@huawei.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Cc: Khazhy Kumykov <khazhy@chromium.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
+
+ /*
--- /dev/null
+From 711f8c3fb3db61897080468586b970c87c61d9e4 Mon Sep 17 00:00:00 2001
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+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 <luiz.von.dentz@intel.com>
+
+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 <poprdi@google.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Reviewed-by: Tedd Ho-Jeong An <tedd.an@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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));
--- /dev/null
+From b1a2cd50c0357f243b7435a732b4e62ba3157a2e Mon Sep 17 00:00:00 2001
+From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+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 <luiz.von.dentz@intel.com>
+
+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 <poprdi@google.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Reviewed-by: Tedd Ho-Jeong An <tedd.an@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
