In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
tcp: fix AO info use-after-free in tcp_ao_connect_init()<\/p>\n
tcp_v4_connect() adds a SYN-SENT socket to the ehash before calling
\ntcp_connect(). If TCP-AO is configured, tcp_connect() first verifies that
\na key matches the peer and the bound device’s current L3 master.
\ntcp_ao_connect_init() later resolves the L3 master again and removes keys
\nwhich do not match it.<\/p>\n
The socket lock does not stabilize the bound device’s VRF membership.
\nDetaching the device from its VRF between the initial validation and the
\nL3-master calculation in tcp_ao_connect_init() can therefore make the
\nvalidation succeed while initialization observes the default L3 domain and
\nremoves the only key. The subsequent AO lookup then fails, so the no-key
\npath clears tp->ao_info and frees it directly.<\/p>\n
The receive path can find the socket in the ehash and load tp->ao_info
\nunder RCU before acquiring the socket lock. A reader which loaded the old
\npointer can thus continue into tcp_inbound_ao_hash() after the direct free.<\/p>\n
The issue was found during a static audit of TCP-AO object lifetime. An
\nunprivileged reproducer in self-created user and network namespaces raced
\nconnect() with detaching a veth from its VRF while sending TCP-AO segments.
\nIt triggered the same KASAN report on two fresh boots:<\/p>\n
BUG: KASAN: slab-use-after-free in tcp_inbound_ao_hash+0x585\/0x19f0
\n Write of size 8 at addr ffff88800bf88128 by task tcp_ao_vrf_race\/232<\/p>\n
Call Trace:
\n tcp_inbound_ao_hash+0x585\/0x19f0
\n tcp_inbound_hash+0x677\/0xa80
\n tcp_v4_rcv+0x1c3e\/0x3ab0<\/p>\n
Allocated by task 235:
\n tcp_ao_alloc_info+0x43\/0xf0
\n tcp_ao_add_cmd+0xdf7\/0x13b0
\n do_tcp_setsockopt+0x168c\/0x2640<\/p>\n
Freed by task 235:
\n kfree+0x1b8\/0x550
\n tcp_connect+0x252\/0x4f00
\n tcp_v4_connect+0x1114\/0x1720<\/p>\n
The bad address is 40 bytes inside the freed 128-byte object, matching the
\ntcp_ao_info counters.key_not_found field. The two runs used 1000 attempts
\neach, reached the no-key path 366 and 411 times, and produced one and two
\nKASAN reports respectively. With this change, the same reproducer reached
\nthe no-key path 366 times in 1000 attempts without a KASAN report or oops.<\/p>\n
Use tcp_ao_destroy_sock() for the no-key path. It unpublishes the AO info,
\nupdates the socket memory and static-key accounting, and defers the free
\nuntil after an RCU grace period.<\/p>\n
Also drop the WARN_ON_ONCE() and its stale comment. The VRF detach race
\nmakes the no-key state reachable during normal operation, so it is a
\nhandled condition rather than an impossible assertion. On panic_on_warn
\nkernels the WARN would turn this handled race into a kernel panic.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
tcp: fix AO info use-after-free in tcp_ao_connect_init()<\/p>\n
tcp_v4_connect() adds a SYN-SENT socket to the ehash before calling
\ntcp_c<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-17354","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/17354","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln"}],"about":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/types\/vuln"}],"wp:attachment":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=17354"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=17354"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=17354"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}