In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
ipv6: seg6: clear IPv4 control block on IPIP decapsulation<\/p>\n
End.DX4 and End.DT4 decapsulate an IPv4 packet through
\ndecap_and_validate() and send it directly to IPv4 routing. The inner
\npacket therefore bypasses ip_rcv_core(), which normally clears IPCB
\nbefore IPv4 interprets skb->cb.<\/p>\n
The skb instead retains IP6CB data from the outer packet. IP6CB and
\nIPCB use the same skb->cb storage, so IP6CB(skb)->lastopt overlaps
\nIPCB(skb)->opt.optlen and srr, while IP6CB(skb)->nhoff overlaps rr and
\nts.<\/p>\n
The sender can make the stale optlen byte nonzero with a valid outer
\nextension-header chain. The reproducers put an eight-byte Destination
\nOptions header immediately after the 40-byte IPv6 header and before the
\nSegment Routing Header. ipv6_destopt_rcv() records the sender-controlled
\nDestination Options offset in both lastopt and nhoff, setting them to
\n40. On the reproduced little-endian x86-64 kernel, IPv4 therefore sees
\noptlen = 40 and rr = 40.<\/p>\n
Both tcp_v4_save_options() and __ip_options_echo() skip option copying
\nwhen optlen is zero. Here optlen is 40, so the TCP SYN path allocates
\nroom for 40 bytes of option data and calls __ip_options_echo(). The
\nstale rr value makes that function read inner packet byte 41 as the
\nRecord Route option length. The reproducers set that sender-controlled
\nbyte to 255, so __ip_options_echo() copies 255 bytes into the 40-byte
\noption-data area.<\/p>\n
Separate End.DX4 and End.DT4 reproducers on the unpatched v7.2-rc5
\nkernel both produced:<\/p>\n
BUG: KASAN: slab-out-of-bounds in __ip_options_echo()
\n Write of size 255<\/p>\n
The relevant End.DX4 call path is:<\/p>\n
__ip_options_echo
\n tcp_v4_route_req
\n tcp_conn_request
\n tcp_v4_conn_request
\n tcp_rcv_state_process
\n tcp_v4_do_rcv
\n tcp_v4_rcv
\n ip_protocol_deliver_rcu
\n ip_local_deliver_finish
\n ip_local_deliver
\n input_action_end_dx4_finish
\n input_action_end_dx4<\/p>\n
The relevant End.DT4 call path is:<\/p>\n
__ip_options_echo
\n tcp_v4_route_req
\n tcp_conn_request
\n tcp_v4_conn_request
\n tcp_rcv_state_process
\n tcp_v4_do_rcv
\n tcp_v4_rcv
\n ip_protocol_deliver_rcu
\n ip_local_deliver_finish
\n ip_local_deliver
\n input_action_end_dt4<\/p>\n
tcp_v4_save_options() is inlined into the tcp_v4_route_req() path, so
\nit does not appear as a separate frame.<\/p>\n
When decap_and_validate() handles IPPROTO_IPIP, save the ingress
\ninterface from IP6CB, clear IPCB, and restore the saved value. Doing
\nthis in the common decapsulation path covers End.DX4, End.DT4, and
\nEnd.DT46’s IPv4 arm.<\/p>\n
Use IP6CB(skb)->iif rather than skb->skb_iif. These actions run after
\nl3mdev processing, which can replace skb_iif with the L3 master;
\nIP6CB iif still records the receiving interface set at IPv6 ingress.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
ipv6: seg6: clear IPv4 control block on IPIP decapsulation<\/p>\n
End.DX4 and End.DT4 decapsulate an IPv4 packet through
\ndecap_and_valida<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-17344","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/17344","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=17344"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=17344"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=17344"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}