Odebrany

CVE-2026-90083

opublikowano: 17.09.2026, 19:16

modyfikacja: 17.09.2026, 19:16

Ocena CVSS

n/a

Brak oceny

Oficjalne źródła

>_ Opis

Tłumaczenie automatyczne – może zawierać nieścisłości.

W jądrze Linuksa usunięto następującą lukę:

net/sched: act_ife: Działa tylko na ramkach Ethernet

act_ife hermetyzuje/dekapsuluje oryginalny nagłówek Ethernet i używa
skb->dev->hard_header_len jako długość tego nagłówka. To jest tylko
poprawne dla urządzeń Ethernet: na urządzeniu, na którym hard_header_len tego nie robi
pasuje do faktycznie pobranego nagłówka L2 (raporty PPP PPP_HDRLEN
podczas gdy nic nie jest usuwane podczas ingresu), ingres skb_push()/skb_pull()
użyj niewłaściwej długości i możesz trafić skb_under_panic, gdy jest mało miejsca nad głową.

IFE z założenia jest przeznaczony wyłącznie dla Ethernetu - buduje zewnętrzny ethdr, przepisuje
h_source/h_dest/h_proto i wywołuje funkcję eth_type_trans() przy dekodowaniu - więc
zamiast próbować sprawić, by przesunięcia działały dla dowolnych typów łączy,
po prostu upuść pakiety, które nie zawierają nagłówka Ethernet.

Samo sprawdzenie skb->dev->type nie wystarczy. Musimy zaspokoić potrzeby A
obudowa narożna, w której mirred może przekierować skb z urządzenia innego niż Ethernet
do Ethernetu, a skb->dev nie mówi nic o kadrowaniu pliku
skb faktycznie ma: skb przekierowany z ppp0 dociera do celu
hook z mac_len 0 i bez nagłówka Ethernet. Podobnie przy wejściu
wymagaj, aby mac_len miał wartość ETH_HLEN. Na wyjściu mac_len nie jest utrzymywany, więc
typ urządzenia to wszystko, co mamy; fałszywe przekierowanie tam powoduje zniekształcenie
ramkę zamiast pchnięcia poza boisko i zostałaby zniekształcona za pomocą przycisku lub
bez IFE.

Ten przypadek narożny nie jest teoretyczny - przekierowanie z ppp0 do veth
który ma akcję ife encode na haku wejściowym, wpada w panikę bez tego
poprawka:

skbuff: skb_under_panic: len:98 put:14 head:ffff88800e410000
dane:ffff88800e40fff5 ogon: 0x57 koniec: 0x640 programista:veth3
BŁĄD jądra w net/core/skbuff.c:214!
Zadzwoń do śledzenia:
skb_push (net/core/skbuff.c:224 net/core/skbuff.c:2657)
tcf_ife_act (net/sched/act_ife.c:829 net/sched/act_ife.c:874)
tc_run (net/core/dev.c:4463)
netif_receive_skb (net/core/dev.c:6463 net/core/dev.c:6522)
tcf_mirred_to_dev (net/sched/act_mirred.c:248 net/sched/act_mirred.c:328)
tcf_mirred_act (net/sched/act_mirred.c:489)
tc_run (net/core/dev.c:4463)
proces_backlog (net/core/dev.c:6728)

Z gwarantowanym ramkowaniem Ethernet, użyj ETH_HLEN zamiast
hard_header_len.

In the Linux kernel, the following vulnerability has been resolved:

net/sched: act_ife: Only operate on Ethernet frames

act_ife encapsulates/decapsulates the original Ethernet header and uses
skb->dev->hard_header_len as the length of that header. That is only
correct for Ethernet devices: on a device where hard_header_len does not
match the L2 header that was actually pulled (PPP reports PPP_HDRLEN
while nothing is stripped on ingress), the ingress skb_push()/skb_pull()
use the wrong length and can hit skb_under_panic when headroom is tight.

IFE is Ethernet-only by design - it builds an outer ethhdr, rewrites
h_source/h_dest/h_proto, and calls eth_type_trans() on decode - so
instead of trying to make the offsets work for arbitrary link types,
simply drop packets that do not carry an Ethernet header.

Checking skb->dev->type alone is not enough. We have to cater for a
corner case where mirred can redirect an skb from a non-Ethernet device
to an Ethernet one, and skb->dev then says nothing about the framing the
skb actually has: an skb redirected from ppp0 reaches the target's ingress
hook with mac_len 0 and no Ethernet header at all. So at ingress also
require mac_len to be ETH_HLEN. On egress mac_len is not maintained, so
the device type is all we have; a bogus redirect there yields a malformed
frame rather than an out-of-bounds push, and it would be malformed with or
without IFE.

That corner case is not theoretical - redirecting from ppp0 into a veth
that has an ife encode action on its ingress hook panics without this
patch:

skbuff: skb_under_panic: len:98 put:14 head:ffff88800e410000
data:ffff88800e40fff5 tail:0x57 end:0x640 dev:veth3
kernel BUG at net/core/skbuff.c:214!
Call Trace:
skb_push (net/core/skbuff.c:224 net/core/skbuff.c:2657)
tcf_ife_act (net/sched/act_ife.c:829 net/sched/act_ife.c:874)
tc_run (net/core/dev.c:4463)
netif_receive_skb (net/core/dev.c:6463 net/core/dev.c:6522)
tcf_mirred_to_dev (net/sched/act_mirred.c:248 net/sched/act_mirred.c:328)
tcf_mirred_act (net/sched/act_mirred.c:489)
tc_run (net/core/dev.c:4463)
process_backlog (net/core/dev.c:6728)

With Ethernet framing guaranteed, use ETH_HLEN instead of
hard_header_len.

>_ Referencje

Dane podatności pochodzą z oficjalnych źródeł (CVE® List / NVD). Opisy po polsku są tłumaczone automatycznie i mogą zawierać nieścisłości – na stronie rekordu można wyświetlić wersję angielską.

This product uses the NVD API but is not endorsed or certified by the NVD.

CVE Usage: MITRE hereby grants you a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Common Vulnerabilities and Exposures (CVE®). Any copy you make for such purposes is authorized provided that you reproduce MITRE's copyright designation and this license in any such copy. ALL DOCUMENTS AND THE INFORMATION CONTAINED THEREIN PROVIDED BY MITRE ARE PROVIDED ON AN "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND.

NVD Terms of Use / CVE® Terms of Use / nvd.nist.gov / cve.org

<< baza_cve