--- /dev/null
+From kuniyu@amazon.com Mon Aug 21 20:35:34 2023
+From: Kuniyuki Iwashima <kuniyu@amazon.com>
+Date: Mon, 21 Aug 2023 10:55:05 -0700
+Subject: af_unix: Fix null-ptr-deref in unix_stream_sendpage().
+To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>, Kuniyuki Iwashima <kuniyu@amazon.com>, Kuniyuki Iwashima <kuni1840@gmail.com>, <stable@vger.kernel.org>, <netdev@vger.kernel.org>, Bing-Jhong Billy Jheng <billy@starlabs.sg>, Linus Torvalds <torvalds@linux-foundation.org>
+Message-ID: <20230821175505.23107-1-kuniyu@amazon.com>
+
+From: Kuniyuki Iwashima <kuniyu@amazon.com>
+
+Bing-Jhong Billy Jheng reported null-ptr-deref in unix_stream_sendpage()
+with detailed analysis and a nice repro.
+
+unix_stream_sendpage() tries to add data to the last skb in the peer's
+recv queue without locking the queue.
+
+If the peer's FD is passed to another socket and the socket's FD is
+passed to the peer, there is a loop between them. If we close both
+sockets without receiving FD, the sockets will be cleaned up by garbage
+collection.
+
+The garbage collection iterates such sockets and unlinks skb with
+FD from the socket's receive queue under the queue's lock.
+
+So, there is a race where unix_stream_sendpage() could access an skb
+locklessly that is being released by garbage collection, resulting in
+use-after-free.
+
+To avoid the issue, unix_stream_sendpage() must lock the peer's recv
+queue.
+
+Note the issue does not exist in 6.5+ thanks to the recent sendpage()
+refactoring.
+
+This patch is originally written by Linus Torvalds.
+
+BUG: unable to handle page fault for address: ffff988004dd6870
+PF: supervisor read access in kernel mode
+PF: error_code(0x0000) - not-present page
+PGD 0 P4D 0
+PREEMPT SMP PTI
+CPU: 4 PID: 297 Comm: garbage_uaf Not tainted 6.1.46 #1
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
+RIP: 0010:kmem_cache_alloc_node+0xa2/0x1e0
+Code: c0 0f 84 32 01 00 00 41 83 fd ff 74 10 48 8b 00 48 c1 e8 3a 41 39 c5 0f 85 1c 01 00 00 41 8b 44 24 28 49 8b 3c 24 48 8d 4a 40 <49> 8b 1c 06 4c 89 f0 65 48 0f c7 0f 0f 94 c0 84 c0 74 a1 41 8b 44
+RSP: 0018:ffffc9000079fac0 EFLAGS: 00000246
+RAX: 0000000000000070 RBX: 0000000000000005 RCX: 000000000001a284
+RDX: 000000000001a244 RSI: 0000000000400cc0 RDI: 000000000002eee0
+RBP: 0000000000400cc0 R08: 0000000000400cc0 R09: 0000000000000003
+R10: 0000000000000001 R11: 0000000000000000 R12: ffff888003970f00
+R13: 00000000ffffffff R14: ffff988004dd6800 R15: 00000000000000e8
+FS: 00007f174d6f3600(0000) GS:ffff88807db00000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: ffff988004dd6870 CR3: 00000000092be000 CR4: 00000000007506e0
+PKRU: 55555554
+Call Trace:
+ <TASK>
+ ? __die_body.cold+0x1a/0x1f
+ ? page_fault_oops+0xa9/0x1e0
+ ? fixup_exception+0x1d/0x310
+ ? exc_page_fault+0xa8/0x150
+ ? asm_exc_page_fault+0x22/0x30
+ ? kmem_cache_alloc_node+0xa2/0x1e0
+ ? __alloc_skb+0x16c/0x1e0
+ __alloc_skb+0x16c/0x1e0
+ alloc_skb_with_frags+0x48/0x1e0
+ sock_alloc_send_pskb+0x234/0x270
+ unix_stream_sendmsg+0x1f5/0x690
+ sock_sendmsg+0x5d/0x60
+ ____sys_sendmsg+0x210/0x260
+ ___sys_sendmsg+0x83/0xd0
+ ? kmem_cache_alloc+0xc6/0x1c0
+ ? avc_disable+0x20/0x20
+ ? percpu_counter_add_batch+0x53/0xc0
+ ? alloc_empty_file+0x5d/0xb0
+ ? alloc_file+0x91/0x170
+ ? alloc_file_pseudo+0x94/0x100
+ ? __fget_light+0x9f/0x120
+ __sys_sendmsg+0x54/0xa0
+ do_syscall_64+0x3b/0x90
+ entry_SYSCALL_64_after_hwframe+0x69/0xd3
+RIP: 0033:0x7f174d639a7d
+Code: 28 89 54 24 1c 48 89 74 24 10 89 7c 24 08 e8 8a c1 f4 ff 8b 54 24 1c 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 33 44 89 c7 48 89 44 24 08 e8 de c1 f4 ff 48
+RSP: 002b:00007ffcb563ea50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e
+RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f174d639a7d
+RDX: 0000000000000000 RSI: 00007ffcb563eab0 RDI: 0000000000000007
+RBP: 00007ffcb563eb10 R08: 0000000000000000 R09: 00000000ffffffff
+R10: 00000000004040a0 R11: 0000000000000293 R12: 00007ffcb563ec28
+R13: 0000000000401398 R14: 0000000000403e00 R15: 00007f174d72c000
+ </TASK>
+
+Fixes: 869e7c62486e ("net: af_unix: implement stream sendpage support")
+Reported-by: Bing-Jhong Billy Jheng <billy@starlabs.sg>
+Reviewed-by: Bing-Jhong Billy Jheng <billy@starlabs.sg>
+Co-developed-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/unix/af_unix.c | 9 ++++-----
+ 1 file changed, 4 insertions(+), 5 deletions(-)
+
+--- a/net/unix/af_unix.c
++++ b/net/unix/af_unix.c
+@@ -2290,6 +2290,7 @@ static ssize_t unix_stream_sendpage(stru
+
+ if (false) {
+ alloc_skb:
++ spin_unlock(&other->sk_receive_queue.lock);
+ unix_state_unlock(other);
+ mutex_unlock(&unix_sk(other)->iolock);
+ newskb = sock_alloc_send_pskb(sk, 0, 0, flags & MSG_DONTWAIT,
+@@ -2329,6 +2330,7 @@ alloc_skb:
+ init_scm = false;
+ }
+
++ spin_lock(&other->sk_receive_queue.lock);
+ skb = skb_peek_tail(&other->sk_receive_queue);
+ if (tail && tail == skb) {
+ skb = newskb;
+@@ -2359,14 +2361,11 @@ alloc_skb:
+ refcount_add(size, &sk->sk_wmem_alloc);
+
+ if (newskb) {
+- err = unix_scm_to_skb(&scm, skb, false);
+- if (err)
+- goto err_state_unlock;
+- spin_lock(&other->sk_receive_queue.lock);
++ unix_scm_to_skb(&scm, skb, false);
+ __skb_queue_tail(&other->sk_receive_queue, newskb);
+- spin_unlock(&other->sk_receive_queue.lock);
+ }
+
++ spin_unlock(&other->sk_receive_queue.lock);
+ unix_state_unlock(other);
+ mutex_unlock(&unix_sk(other)->iolock);
+
--- /dev/null
+From 1b254b791d7b7dea6e8adc887fbbd51746d8bb27 Mon Sep 17 00:00:00 2001
+From: Karol Herbst <kherbst@redhat.com>
+Date: Mon, 14 Aug 2023 16:49:32 +0200
+Subject: drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create
+
+From: Karol Herbst <kherbst@redhat.com>
+
+commit 1b254b791d7b7dea6e8adc887fbbd51746d8bb27 upstream.
+
+We can't simply free the connector after calling drm_connector_init on it.
+We need to clean up the drm side first.
+
+It might not fix all regressions from commit 2b5d1c29f6c4
+("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts"),
+but at least it fixes a memory corruption in error handling related to
+that commit.
+
+Link: https://lore.kernel.org/lkml/20230806213107.GFZNARG6moWpFuSJ9W@fat_crate.local/
+Fixes: 95983aea8003 ("drm/nouveau/disp: add connector class")
+Signed-off-by: Karol Herbst <kherbst@redhat.com>
+Reviewed-by: Lyude Paul <lyude@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230814144933.3956959-1-kherbst@redhat.com
+Signed-off-by: Karol Herbst <kherbst@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/nouveau/nouveau_connector.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
++++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
+@@ -1407,8 +1407,7 @@ nouveau_connector_create(struct drm_devi
+ ret = nvif_conn_ctor(&disp->disp, nv_connector->base.name, nv_connector->index,
+ &nv_connector->conn);
+ if (ret) {
+- kfree(nv_connector);
+- return ERR_PTR(ret);
++ goto drm_conn_err;
+ }
+ }
+
+@@ -1470,4 +1469,9 @@ nouveau_connector_create(struct drm_devi
+
+ drm_connector_register(connector);
+ return connector;
++
++drm_conn_err:
++ drm_connector_cleanup(connector);
++ kfree(nv_connector);
++ return ERR_PTR(ret);
+ }
--- /dev/null
+From e4dd0d3a2f64b8bd8029ec70f52bdbebd0644408 Mon Sep 17 00:00:00 2001
+From: Jason Xing <kernelxing@tencent.com>
+Date: Fri, 11 Aug 2023 10:37:47 +0800
+Subject: net: fix the RTO timer retransmitting skb every 1ms if linear option is enabled
+
+From: Jason Xing <kernelxing@tencent.com>
+
+commit e4dd0d3a2f64b8bd8029ec70f52bdbebd0644408 upstream.
+
+In the real workload, I encountered an issue which could cause the RTO
+timer to retransmit the skb per 1ms with linear option enabled. The amount
+of lost-retransmitted skbs can go up to 1000+ instantly.
+
+The root cause is that if the icsk_rto happens to be zero in the 6th round
+(which is the TCP_THIN_LINEAR_RETRIES value), then it will always be zero
+due to the changed calculation method in tcp_retransmit_timer() as follows:
+
+icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX);
+
+Above line could be converted to
+icsk->icsk_rto = min(0 << 1, TCP_RTO_MAX) = 0
+
+Therefore, the timer expires so quickly without any doubt.
+
+I read through the RFC 6298 and found that the RTO value can be rounded
+up to a certain value, in Linux, say TCP_RTO_MIN as default, which is
+regarded as the lower bound in this patch as suggested by Eric.
+
+Fixes: 36e31b0af587 ("net: TCP thin linear timeouts")
+Suggested-by: Eric Dumazet <edumazet@google.com>
+Signed-off-by: Jason Xing <kernelxing@tencent.com>
+Reviewed-by: Eric Dumazet <edumazet@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/tcp_timer.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/net/ipv4/tcp_timer.c
++++ b/net/ipv4/tcp_timer.c
+@@ -586,7 +586,9 @@ out_reset_timer:
+ tcp_stream_is_thin(tp) &&
+ icsk->icsk_retransmits <= TCP_THIN_LINEAR_RETRIES) {
+ icsk->icsk_backoff = 0;
+- icsk->icsk_rto = min(__tcp_set_rto(tp), TCP_RTO_MAX);
++ icsk->icsk_rto = clamp(__tcp_set_rto(tp),
++ tcp_rto_min(sk),
++ TCP_RTO_MAX);
+ } else {
+ /* Use normal (exponential) backoff */
+ icsk->icsk_rto = min(icsk->icsk_rto << 1, TCP_RTO_MAX);
projects / thirdparty / kernel / stable-queue.git / commitdiff
