CVE-2026-80905

  • Автор темы Автор темы Support
  • Дата начала Дата начала

Support

Moderator
Команда форума
MODERATOR
User RTM
Регистрация
30 Мар 2024
Сообщения
132,865
Реакции
4
Баллы
0
☑ ДЕПОЗИТ
0$
🚨 CVE-2026-80905
In the Linux kernel, the following vulnerability has been resolved:

net: tap: fix wrong transport_header when sending VLAN-tagged frame

In tap_get_user_xdp(), when processing a VLAN-tagged frame (e.g.
ETH_P_8021Q), skb_set_network_header() is called first to advance
network_header past the VLAN tag to the inner protocol header.
skb_probe_transport_header() is then called with skb->protocol still
set to ETH_P_8021Q, while nhoff (derived from skb_network_offset())
already points past the VLAN tag to the inner protocol header.

In __skb_flow_dissect(), proto is initialized to ETH_P_8021Q and nhoff
points past the VLAN tag. When the dissector hits case ETH_P_8021Q, it
reads a struct vlan_hdr at the current nhoff via __skb_header_pointer(),
but that offset contains the inner protocol header (e.g. an IP header).
The bytes are misinterpreted as a VLAN header, yielding a garbage
encapsulated EtherType that matches no known protocol. The dissector
returns false, so skb_probe_transport_header() never calls
skb_set_transport_header(), leaving transport_header at its uninitialized
sentinel value (~0U).

Move skb_set_network_header() to after skb_probe_transport_header(). At
the time skb_probe_transport_header() is called, network_header still
points to the VLAN header (offset ETH_HLEN), so nhoff is correct and the
flow dissector can parse the VLAN header, extract the inner EtherType,
and advance nhoff to the inner protocol header, allowing transport_header
to be set correctly.

 
Автоматический гарант это финансовая безопасность: Покупатель может быть уверен, что его деньги не попадут к продавцу до того, как он получит и проверит товар или услугу. Продавец, в свою очередь, защищен от не оплаты, так как гарант подтверждает наличие средств у покупателя до начала выполнения обязательств.
Назад
Сверху