В ядре Linux устранена следующая уязвимость:
netfilter: x_tables: ограничить расширения xt_check_match/xt_check_target для NFPROTO_ARP
Вэймин Ши говорит:
Структуры xt_match и xt_target, зарегистрированные с помощью NFPROTO_UNSPEC, могут быть
загружается любым семейством протоколов через nft_compat. Когда такое
match/target устанавливает .hooks, чтобы ограничить, какие хуки могут использоваться,
битовая маска использует константы NF_INET_*. Это справедливо только для семей.
чья схема подключения соответствует NF_INET_*: IPv4, IPv6, INET и мост
все используют одни и те же пять перехватчиков (PRE_ROUTING ... POST_ROUTING).
ARP имеет только три перехватчика (IN=0, OUT=1, FORWARD=2) с разными
семантика. Поскольку NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, .hooks
проверка проходит молча по неправильным причинам, позволяя совпадениям
запускаться в цепочках ARP, где предположения о перехватчиках (например, состояние->нахождение)
установить на входные крючки) не держать. Это приводит к NULL указателю
разыменования; xt_devgroup — один конкретный пример:
Упс: общая ошибка защиты, вероятно, для неканонического адреса 0xdffffc0000000044:0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref в диапазоне [0x0000000000000220-0x00000000000000227]
RIP: 0010:devgroup_mt+0xff/0x350
Отслеживание вызова:
<ЗАДАЧА>
nft_match_eval (net/netfilter/nft_compat.c:407)
nft_do_chain (net/netfilter/nf_tables_core.c:285)
nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61)
nf_hook_slow (net/netfilter/core.c:623)
arp_xmit (net/ipv4/arp.c:666)
</TASK>
Паника ядра – нет синхронизации: фатальное исключение в прерывании
Исправьте это, ограничив arptables только расширениями NFPROTO_ARP.
Обратите внимание, что arptables-legacy поддерживает только:
- арпт_КЛАССИФИКАЦИЯ
- арпт_мангл
- арпт_МАРК
которые предоставляют явные объявления соответствия/цели NFPROTO_ARP.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: netfilter: x_tables: restrict xt_check_match/xt_check_target extensions for NFPROTO_ARP Weiming Shi says: xt_match and xt_target structs registered with NFPROTO_UNSPEC can be loaded by any protocol family through nft_compat. When such a match/target sets .hooks to restrict which hooks it may run on, the bitmask uses NF_INET_* constants. This is only correct for families whose hook layout matches NF_INET_*: IPv4, IPv6, INET, and bridge all share the same five hooks (PRE_ROUTING ... POST_ROUTING). ARP only has three hooks (IN=0, OUT=1, FORWARD=2) with different semantics. Because NF_ARP_OUT == 1 == NF_INET_LOCAL_IN, the .hooks validation silently passes for the wrong reasons, allowing matches to run on ARP chains where the hook assumptions (e.g. state->in being set on input hooks) do not hold. This leads to NULL pointer dereferences; xt_devgroup is one concrete example: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000044: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000220-0x0000000000000227] RIP: 0010:devgroup_mt+0xff/0x350 Call Trace: <TASK> nft_match_eval (net/netfilter/nft_compat.c:407) nft_do_chain (net/netfilter/nf_tables_core.c:285) nft_do_chain_arp (net/netfilter/nft_chain_filter.c:61) nf_hook_slow (net/netfilter/core.c:623) arp_xmit (net/ipv4/arp.c:666) </TASK> Kernel panic - not syncing: Fatal exception in interrupt Fix it by restricting arptables to NFPROTO_ARP extensions only. Note that arptables-legacy only supports: - arpt_CLASSIFY - arpt_mangle - arpt_MARK that provide explicit NFPROTO_ARP match/target declarations.