В ядре Linux устранена следующая уязвимость:
inet: frags: отделить состояние GSO от фрагментов перед повторной сборкой
Virtio_net_hdr (tun/tap или AF_PACKET с PACKET_VNET_HDR) может отмечать
фрагмент IPv4 или IPv6 как GSO; ничто не связывает gso_type с frag_off.
inet_frag_reasm_prepare()/inet_frag_reasm_finish() сохраняет первый
skb фрагмента в качестве заголовка повторно собранной дейтаграммы, включая ее
shinfo->gso_size/gso_type/gso_segs и соедините оставшиеся фрагменты
в frag_list с любым линейным/постраничным макетом, с которым они пришли. После ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...)
пересобранный скб поэтому все еще претендует на ГСО (SKB_GSO_DODGY), и
следующая точка программной сегментации — udp_rcv_segment() на локальном компьютере.
доставка, validate_xmit_skb() или медленный ip_finish_output_gso()
путь — передает его skb_segment(). Обход frag_list с помощью skb_segment()
принимает входные данные в форме GRO и вызывает одну из своих функций BUG_ON().
Два пишут в
достаточно касания непривилегированного пользователя в его собственных пользователях:
ОШИБКА ядра в net/core/skbuff.c:4899!
К сожалению: неверный код операции: 0000 [#1] SMP KASAN NOPTI
ЦП: 0 UID: 1000 PID: 82 Связь: poc Не испорчен 7.2.0-pentest+ #2
RIP: 0010:skb_segment+0x20ca/0x48b0
Отслеживание вызова:
<ЗАДАЧА>
__udp_gso_segment+0x29a/0x27d0
udp4_ufo_fragment+0x458/0x6c0
inet_gso_segment+0x429/0x1340
skb_mac_gso_segment+0x233/0x4f0
__skb_gso_segment+0x308/0x660
udp_queue_rcv_skb+0x440/0xad0
udp_unicast_rcv_skb+0xc7/0x2c0
udp_rcv+0x16ce/0x2260
ip_protocol_deliver_rcu+0x197/0x2d0
ip_local_deliver+0x430/0x690
ip_rcv+0x16f/0x1f0
__netif_receive_skb_one_core+0x15e/0x1c0
__netif_receive_skb+0x1e/0x110
netif_receive_skb+0xf6/0x5c0
tun_rx_batched.isra.0+0x3ab/0x790
tun_get_user+0x17c3/0x3550
tun_chr_write_iter+0xba/0x1b0
vfs_write+0x646/0x1130
</TASK>
Паника ядра – нет синхронизации: фатальное исключение в прерывании
Это работает с отключенным BH, так что это скорее паника, чем упс.
то же самое можно достичь с помощью CAP_NET_RAW в сети, где есть точка дефрагментации.
предшествует точке GSO, и от гостя, чей VMM пересылает
virtio_net_hdr на кран. Проверки SKB_GSO_DODGY frag_list добавлены
commit 3dcbdb134f32 ("net: gso: Исправлено пятно skb_segment при разделении
gso_size исказил skb, имеющий frag_list с линейной головой") и
commit 9e4b7a99a03a ("net: gso: исправить панику на frag_list со смешанной головой
alloc типы") не скрывают его: заголовки с поддержкой страниц пропускают их, а kmalloc
головы пропускают их, когда gso_size == skb_headlen(head), что отправитель
элементы управления.
skb, попадающий в очередь фрагментов, по определению является IP-фрагментом и
не может законно нести состояние GSO: GRO не объединяет фрагменты и
стек сегментируется до того, как он фрагментируется, поэтому используются только ненадежные источники.
повлияло. Это стало возможным с тех пор, как
commit f43798c27684 («tun: разрешить GSO с помощью virtio_net_hdr»), первый
путь, который позволяет пользовательскому пространству прикреплять метаданные GSO к IP-фрагменту.
Сброс
поля GSO каждого фрагмента, поставленного в очередь, в
inet_frag_queue_insert(), который IPv4, IPv6, nf_conntrack_reasm и
6лапка нижнего поддона в сборе; тогда ни голова, ни frag_list
Их носят члены пересобранного скб (члены тоже имеют значение:
быстрые пути ip_do_fragment()/ip6_fragment() отправляют их по мере их
есть). Головка может оставаться CHECKSUM_PARTIAL; это уже принято
при получении и разрешении с помощью skb_checksum_help() в
ip_do_fragment()/ip6_fragment() при пересылке. Протестировано поверх net.git (dc4b95b8fee9), x86_64: воспроизводитель касаний.
выше, еще две геометрии frag_list IPv4, которые достигают
BUG_ON(i >= nfrags) и BUG_ON(!list_skb->head_frag) и IPv6.
вариант заголовка фрагмента (udp6_ufo_fragment()) каждый паникует непропатченный
ядро; с этим патчем все четыре дейтаграммы доставляются в целости и сохранности.
ничего не протоколируется.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: inet: frags: strip GSO state from fragments before reassembly A virtio_net_hdr (tun/tap, or AF_PACKET with PACKET_VNET_HDR) can mark an IPv4 or IPv6 fragment as GSO; nothing relates gso_type to frag_off. inet_frag_reasm_prepare()/inet_frag_reasm_finish() keep the first fragment's skb as the head of the reassembled datagram, including its shinfo->gso_size/gso_type/gso_segs, and chain the remaining fragments on frag_list with whatever linear/paged layout they arrived with. After ip_defrag() (ip_local_deliver(), nf_defrag_ipv4, ...) the reassembled skb therefore still claims to be GSO (SKB_GSO_DODGY), and the next software segmentation point - udp_rcv_segment() on local delivery, validate_xmit_skb(), or the ip_finish_output_gso() slow path - hands it to skb_segment(). skb_segment()'s frag_list walk assumes GRO-shaped input and hits one of its BUG_ON()s. Two writes to a tap by an unprivileged user in its own userns are enough: kernel BUG at net/core/skbuff.c:4899! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 1000 PID: 82 Comm: poc Not tainted 7.2.0-pentest+ #2 RIP: 0010:skb_segment+0x20ca/0x48b0 Call Trace: <TASK> __udp_gso_segment+0x29a/0x27d0 udp4_ufo_fragment+0x458/0x6c0 inet_gso_segment+0x429/0x1340 skb_mac_gso_segment+0x233/0x4f0 __skb_gso_segment+0x308/0x660 udp_queue_rcv_skb+0x440/0xad0 udp_unicast_rcv_skb+0xc7/0x2c0 udp_rcv+0x16ce/0x2260 ip_protocol_deliver_rcu+0x197/0x2d0 ip_local_deliver+0x430/0x690 ip_rcv+0x16f/0x1f0 __netif_receive_skb_one_core+0x15e/0x1c0 __netif_receive_skb+0x1e/0x110 netif_receive_skb+0xf6/0x5c0 tun_rx_batched.isra.0+0x3ab/0x790 tun_get_user+0x17c3/0x3550 tun_chr_write_iter+0xba/0x1b0 vfs_write+0x646/0x1130 </TASK> Kernel panic - not syncing: Fatal exception in interrupt This runs with BH disabled, so it is a panic rather than an oops. The same is reachable with CAP_NET_RAW in a netns where a defrag point precedes a GSO point, and from a guest whose VMM forwards virtio_net_hdr to a tap. The SKB_GSO_DODGY frag_list checks added by commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list") and by commit 9e4b7a99a03a ("net: gso: fix panic on frag_list with mixed head alloc types") do not cover it: page-backed heads skip them, and kmalloc heads skip them when gso_size == skb_headlen(head), which the sender controls. An skb entering a frag queue is an IP fragment by definition and cannot legitimately carry GSO state: GRO does not merge fragments and the stack segments before it fragments, so only untrusted sources are affected. This has been reachable since commit f43798c27684 ("tun: Allow GSO using virtio_net_hdr"), the first path that let userspace attach GSO metadata to an IP fragment. Reset the GSO fields of every fragment as it is queued, in inet_frag_queue_insert(), which IPv4, IPv6, nf_conntrack_reasm and 6lowpan reassembly share; then neither the head nor the frag_list members of the reassembled skb carry them (the members matter too: the ip_do_fragment()/ip6_fragment() fast paths send them out as they are). The head may remain CHECKSUM_PARTIAL; that is already accepted on receive and resolved by skb_checksum_help() in ip_do_fragment()/ip6_fragment() on forward. Tested on top of net.git (dc4b95b8fee9), x86_64: the tap reproducer above, two further IPv4 frag_list geometries that reach BUG_ON(i >= nfrags) and BUG_ON(!list_skb->head_frag), and an IPv6 fragment-header variant (udp6_ufo_fragment()) each panic the unpatched kernel; with this patch all four datagrams are delivered intact and nothing is logged.
Характеристики атаки
Последствия
Строка CVSS v3.1