cve/published/2024/CVE-2024-50154.mbox - pub/scm/linux/security/vulns - Git at Google

 From bippy-1.1.0 Mon Sep 17 00:00:00 2001
 From: Greg Kroah-Hartman <gregkh@kernel.org>
 To: <linux-cve-announce@vger.kernel.org>
 Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
 Subject: CVE-2024-50154: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().

 Description
 ===========

 In the Linux kernel, the following vulnerability has been resolved:

 tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().

 Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().

   """
   We are seeing a use-after-free from a bpf prog attached to
   trace_tcp_retransmit_synack. The program passes the req->sk to the
   bpf_sk_storage_get_tracing kernel helper which does check for null
   before using it.
   """

 The commit 83fccfc3940c ("inet: fix potential deadlock in
 reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not
 to call del_timer_sync() from reqsk_timer_handler(), but it introduced a
 small race window.

 Before the timer is called, expire_timers() calls detach_timer(timer, true)
 to clear timer->entry.pprev and marks it as not pending.

 If reqsk_queue_unlink() checks timer_pending() just after expire_timers()
 calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will
 continue running and send multiple SYN+ACKs until it expires.

 The reported UAF could happen if req->sk is close()d earlier than the timer
 expiration, which is 63s by default.

 The scenario would be

   1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),
      but del_timer_sync() is missed

   2. reqsk timer is executed and scheduled again

   3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but
      reqsk timer still has another one, and inet_csk_accept() does not
      clear req->sk for non-TFO sockets

   4. sk is close()d

   5. reqsk timer is executed again, and BPF touches req->sk

 Let's not use timer_pending() by passing the caller context to
 __inet_csk_reqsk_queue_drop().

 Note that reqsk timer is pinned, so the issue does not happen in most
 use cases. [1]

 [0]
 BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0

 Use-after-free read at 0x00000000a891fb3a (in kfence-#1):
 bpf_sk_storage_get_tracing+0x2e/0x1b0
 bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda
 bpf_trace_run2+0x4c/0xc0
 tcp_rtx_synack+0xf9/0x100
 reqsk_timer_handler+0xda/0x3d0
 run_timer_softirq+0x292/0x8a0
 irq_exit_rcu+0xf5/0x320
 sysvec_apic_timer_interrupt+0x6d/0x80
 asm_sysvec_apic_timer_interrupt+0x16/0x20
 intel_idle_irq+0x5a/0xa0
 cpuidle_enter_state+0x94/0x273
 cpu_startup_entry+0x15e/0x260
 start_secondary+0x8a/0x90
 secondary_startup_64_no_verify+0xfa/0xfb

 kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6

 allocated by task 0 on cpu 9 at 260507.901592s:
 sk_prot_alloc+0x35/0x140
 sk_clone_lock+0x1f/0x3f0
 inet_csk_clone_lock+0x15/0x160
 tcp_create_openreq_child+0x1f/0x410
 tcp_v6_syn_recv_sock+0x1da/0x700
 tcp_check_req+0x1fb/0x510
 tcp_v6_rcv+0x98b/0x1420
 ipv6_list_rcv+0x2258/0x26e0
 napi_complete_done+0x5b1/0x2990
 mlx5e_napi_poll+0x2ae/0x8d0
 net_rx_action+0x13e/0x590
 irq_exit_rcu+0xf5/0x320
 common_interrupt+0x80/0x90
 asm_common_interrupt+0x22/0x40
 cpuidle_enter_state+0xfb/0x273
 cpu_startup_entry+0x15e/0x260
 start_secondary+0x8a/0x90
 secondary_startup_64_no_verify+0xfa/0xfb

 freed by task 0 on cpu 9 at 260507.927527s:
 rcu_core_si+0x4ff/0xf10
 irq_exit_rcu+0xf5/0x320
 sysvec_apic_timer_interrupt+0x6d/0x80
 asm_sysvec_apic_timer_interrupt+0x16/0x20
 cpuidle_enter_state+0xfb/0x273
 cpu_startup_entry+0x15e/0x260
 start_secondary+0x8a/0x90
 secondary_startup_64_no_verify+0xfa/0xfb

 The Linux kernel CVE team has assigned CVE-2024-50154 to this issue.


 Affected and fixed versions
 ===========================

 	Issue introduced in 4.2 with commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af and fixed in 5.4.293 with commit 106e457953315e476b3642ef24be25ed862aaba3
 	Issue introduced in 4.2 with commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af and fixed in 5.10.237 with commit c964bf65f80a14288d767023a1b300b30f5b9cd0
 	Issue introduced in 4.2 with commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af and fixed in 5.15.170 with commit 8459d61fbf24967839a70235165673148c7c7f17
 	Issue introduced in 4.2 with commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af and fixed in 6.1.115 with commit 5071beb59ee416e8ab456ac8647a4dabcda823b1
 	Issue introduced in 4.2 with commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af and fixed in 6.6.59 with commit 997ae8da14f1639ce6fb66a063dab54031cd61b3
 	Issue introduced in 4.2 with commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af and fixed in 6.11.6 with commit 51e34db64f4e43c7b055ccf881b7f3e0c31bb26d
 	Issue introduced in 4.2 with commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af and fixed in 6.12 with commit e8c526f2bdf1845bedaf6a478816a3d06fa78b8f
 	Issue introduced in 4.1.11 with commit d3a1196bfc462943694623412d8e03aaf172bdc1

 Please see https://www.kernel.org for a full list of currently supported
 kernel versions by the kernel community.

 Unaffected versions might change over time as fixes are backported to
 older supported kernel versions.  The official CVE entry at
 	https://cve.org/CVERecord/?id=CVE-2024-50154
 will be updated if fixes are backported, please check that for the most
 up to date information about this issue.


 Affected files
 ==============

 The file(s) affected by this issue are:
 	net/ipv4/inet_connection_sock.c


 Mitigation
 ==========

 The Linux kernel CVE team recommends that you update to the latest
 stable kernel version for this, and many other bugfixes.  Individual
 changes are never tested alone, but rather are part of a larger kernel
 release.  Cherry-picking individual commits is not recommended or
 supported by the Linux kernel community at all.  If however, updating to
 the latest release is impossible, the individual changes to resolve this
 issue can be found at these commits:
 	https://git.kernel.org/stable/c/106e457953315e476b3642ef24be25ed862aaba3
 	https://git.kernel.org/stable/c/c964bf65f80a14288d767023a1b300b30f5b9cd0
 	https://git.kernel.org/stable/c/8459d61fbf24967839a70235165673148c7c7f17
 	https://git.kernel.org/stable/c/5071beb59ee416e8ab456ac8647a4dabcda823b1
 	https://git.kernel.org/stable/c/997ae8da14f1639ce6fb66a063dab54031cd61b3
 	https://git.kernel.org/stable/c/51e34db64f4e43c7b055ccf881b7f3e0c31bb26d
 	https://git.kernel.org/stable/c/e8c526f2bdf1845bedaf6a478816a3d06fa78b8f
	From bippy-1.1.0 Mon Sep 17 00:00:00 2001
	From: Greg Kroah-Hartman <gregkh@kernel.org>
	To: <linux-cve-announce@vger.kernel.org>
	Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
	Subject: CVE-2024-50154: tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().

	Description
	===========

	In the Linux kernel, the following vulnerability has been resolved:

	tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().

	Martin KaFai Lau reported use-after-free [0] in reqsk_timer_handler().

	"""
	We are seeing a use-after-free from a bpf prog attached to
	trace_tcp_retransmit_synack. The program passes the req->sk to the
	bpf_sk_storage_get_tracing kernel helper which does check for null
	before using it.
	"""

	The commit 83fccfc3940c ("inet: fix potential deadlock in
	reqsk_queue_unlink()") added timer_pending() in reqsk_queue_unlink() not
	to call del_timer_sync() from reqsk_timer_handler(), but it introduced a
	small race window.

	Before the timer is called, expire_timers() calls detach_timer(timer, true)
	to clear timer->entry.pprev and marks it as not pending.

	If reqsk_queue_unlink() checks timer_pending() just after expire_timers()
	calls detach_timer(), TCP will miss del_timer_sync(); the reqsk timer will
	continue running and send multiple SYN+ACKs until it expires.

	The reported UAF could happen if req->sk is close()d earlier than the timer
	expiration, which is 63s by default.

	The scenario would be

	1. inet_csk_complete_hashdance() calls inet_csk_reqsk_queue_drop(),
	but del_timer_sync() is missed

	2. reqsk timer is executed and scheduled again

	3. req->sk is accept()ed and reqsk_put() decrements rsk_refcnt, but
	reqsk timer still has another one, and inet_csk_accept() does not
	clear req->sk for non-TFO sockets

	4. sk is close()d

	5. reqsk timer is executed again, and BPF touches req->sk

	Let's not use timer_pending() by passing the caller context to
	__inet_csk_reqsk_queue_drop().

	Note that reqsk timer is pinned, so the issue does not happen in most
	use cases. [1]

	[0]
	BUG: KFENCE: use-after-free read in bpf_sk_storage_get_tracing+0x2e/0x1b0

	Use-after-free read at 0x00000000a891fb3a (in kfence-#1):
	bpf_sk_storage_get_tracing+0x2e/0x1b0
	bpf_prog_5ea3e95db6da0438_tcp_retransmit_synack+0x1d20/0x1dda
	bpf_trace_run2+0x4c/0xc0
	tcp_rtx_synack+0xf9/0x100
	reqsk_timer_handler+0xda/0x3d0
	run_timer_softirq+0x292/0x8a0
	irq_exit_rcu+0xf5/0x320
	sysvec_apic_timer_interrupt+0x6d/0x80
	asm_sysvec_apic_timer_interrupt+0x16/0x20
	intel_idle_irq+0x5a/0xa0
	cpuidle_enter_state+0x94/0x273
	cpu_startup_entry+0x15e/0x260
	start_secondary+0x8a/0x90
	secondary_startup_64_no_verify+0xfa/0xfb

	kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6

	allocated by task 0 on cpu 9 at 260507.901592s:
	sk_prot_alloc+0x35/0x140
	sk_clone_lock+0x1f/0x3f0
	inet_csk_clone_lock+0x15/0x160
	tcp_create_openreq_child+0x1f/0x410
	tcp_v6_syn_recv_sock+0x1da/0x700
	tcp_check_req+0x1fb/0x510
	tcp_v6_rcv+0x98b/0x1420
	ipv6_list_rcv+0x2258/0x26e0
	napi_complete_done+0x5b1/0x2990
	mlx5e_napi_poll+0x2ae/0x8d0
	net_rx_action+0x13e/0x590
	irq_exit_rcu+0xf5/0x320
	common_interrupt+0x80/0x90
	asm_common_interrupt+0x22/0x40
	cpuidle_enter_state+0xfb/0x273
	cpu_startup_entry+0x15e/0x260
	start_secondary+0x8a/0x90
	secondary_startup_64_no_verify+0xfa/0xfb

	freed by task 0 on cpu 9 at 260507.927527s:
	rcu_core_si+0x4ff/0xf10
	irq_exit_rcu+0xf5/0x320
	sysvec_apic_timer_interrupt+0x6d/0x80
	asm_sysvec_apic_timer_interrupt+0x16/0x20
	cpuidle_enter_state+0xfb/0x273
	cpu_startup_entry+0x15e/0x260
	start_secondary+0x8a/0x90
	secondary_startup_64_no_verify+0xfa/0xfb

	The Linux kernel CVE team has assigned CVE-2024-50154 to this issue.


	Affected and fixed versions
	===========================

	Issue introduced in 4.2 with commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af and fixed in 5.4.293 with commit 106e457953315e476b3642ef24be25ed862aaba3
	Issue introduced in 4.2 with commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af and fixed in 5.10.237 with commit c964bf65f80a14288d767023a1b300b30f5b9cd0
	Issue introduced in 4.2 with commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af and fixed in 5.15.170 with commit 8459d61fbf24967839a70235165673148c7c7f17
	Issue introduced in 4.2 with commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af and fixed in 6.1.115 with commit 5071beb59ee416e8ab456ac8647a4dabcda823b1
	Issue introduced in 4.2 with commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af and fixed in 6.6.59 with commit 997ae8da14f1639ce6fb66a063dab54031cd61b3
	Issue introduced in 4.2 with commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af and fixed in 6.11.6 with commit 51e34db64f4e43c7b055ccf881b7f3e0c31bb26d
	Issue introduced in 4.2 with commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af and fixed in 6.12 with commit e8c526f2bdf1845bedaf6a478816a3d06fa78b8f
	Issue introduced in 4.1.11 with commit d3a1196bfc462943694623412d8e03aaf172bdc1

	Please see https://www.kernel.org for a full list of currently supported
	kernel versions by the kernel community.

	Unaffected versions might change over time as fixes are backported to
	older supported kernel versions. The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2024-50154
	will be updated if fixes are backported, please check that for the most
	up to date information about this issue.


	Affected files
	==============

	The file(s) affected by this issue are:
	net/ipv4/inet_connection_sock.c


	Mitigation
	==========

	The Linux kernel CVE team recommends that you update to the latest
	stable kernel version for this, and many other bugfixes. Individual
	changes are never tested alone, but rather are part of a larger kernel
	release. Cherry-picking individual commits is not recommended or
	supported by the Linux kernel community at all. If however, updating to
	the latest release is impossible, the individual changes to resolve this
	issue can be found at these commits:
	https://git.kernel.org/stable/c/106e457953315e476b3642ef24be25ed862aaba3
	https://git.kernel.org/stable/c/c964bf65f80a14288d767023a1b300b30f5b9cd0
	https://git.kernel.org/stable/c/8459d61fbf24967839a70235165673148c7c7f17
	https://git.kernel.org/stable/c/5071beb59ee416e8ab456ac8647a4dabcda823b1
	https://git.kernel.org/stable/c/997ae8da14f1639ce6fb66a063dab54031cd61b3
	https://git.kernel.org/stable/c/51e34db64f4e43c7b055ccf881b7f3e0c31bb26d
	https://git.kernel.org/stable/c/e8c526f2bdf1845bedaf6a478816a3d06fa78b8f