In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
xfrm: iptfs: fix stack OOB read in iptfs_skb_reset_frag_walk()<\/p>\n
iptfs_skb_reset_frag_walk() advances to the fragment containing @offset
\nwith an unbounded loop:<\/p>\n
\twhile (offset >= walk->past + walk->frags[walk->fragi].len)
\n\t\twalk->past += walk->frags[walk->fragi++].len;<\/p>\n
walk->fragi is advanced and walk->frags[walk->fragi] is dereferenced
\nwithout ever checking fragi against walk->nr_frags. When the requested
\noffset is at or beyond the total length spanned by the walk’s fragments,
\nfragi runs past nr_frags and off the end of the fixed-size on-stack
\nfrags[MAX_SKB_FRAGS + 1] array, reading out-of-bounds stack memory.<\/p>\n
The two callers behave differently: iptfs_skb_add_frags() already guards
\nagainst this with<\/p>\n
\tif (!walk->nr_frags ||
\n\t offset >= walk->total + walk->initial_offset)
\n\t\treturn len;<\/p>\n
but iptfs_skb_can_add_frags() has no such guard and calls
\niptfs_skb_reset_frag_walk() unconditionally, so it performs the
\nout-of-range walk. Its own “fragi nr_frags” bound check runs only
\nafterwards, too late to prevent the read.<\/p>\n
This is reachable from the receive path: a crafted IP-TFS (AGGFRAG)
\npayload delivered to an IPTFS SA drives iptfs_reassem_cont() ->
\niptfs_skb_can_add_frags() with an offset past the fragment total, e.g.:<\/p>\n
BUG: KASAN: stack-out-of-bounds in iptfs_skb_reset_frag_walk+0x235\/0x250
\n Read of size 4 at addr ffff888008ad7210 by task repro\/345
\n iptfs_skb_reset_frag_walk+0x235\/0x250 net\/xfrm\/xfrm_iptfs.c:392
\n iptfs_skb_can_add_frags+0x155\/0x310 net\/xfrm\/xfrm_iptfs.c:420
\n iptfs_reassem_cont+0xcf8\/0x1140 net\/xfrm\/xfrm_iptfs.c:902
\n iptfs_input_ordered+0x552\/0x670 net\/xfrm\/xfrm_iptfs.c:1280
\n iptfs_input+0x3d6\/0xde0 net\/xfrm\/xfrm_iptfs.c:1741
\n xfrm_input+0x282f\/0x6140 net\/xfrm\/xfrm_input.c:700
\n xfrm4_esp_rcv+0x93\/0x120 net\/ipv4\/xfrm4_protocol.c:104
\n ip_rcv+0x278\/0x2d0 net\/ipv4\/ip_input.c:612<\/p>\n
Give iptfs_skb_can_add_frags() the same up-front guard that
\niptfs_skb_add_frags() already has, so the walk is never entered with an
\nout-of-range offset. When it triggers, the caller falls back to the
\nexisting linearize-and-copy path, which is safe.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the Linux kernel, the following vulnerability has been resolved:<\/p>\n
xfrm: iptfs: fix stack OOB read in iptfs_skb_reset_frag_walk()<\/p>\n
iptfs_skb_reset_frag_walk() advances to the fragment containing @of<\/p>\n","protected":false},"template":"","meta":[],"categories":[],"tags":[],"class_list":["post-33441","vuln","type-vuln","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/www.54iter.cn\/index.php?rest_route=\/wp\/v2\/vuln\/33441","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=33441"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=33441"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.54iter.cn\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=33441"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}