В ядре Linux устранена следующая уязвимость:
ipv6: исправлено разыменование нулевого указателя в ip6_rt_get_dev_rcu().
l3mdev_master_dev_rcu() может возвращать NULL, когда ведомое устройство находится в режиме ожидания.
неподчиненный от VRF. Все остальные звонилки с этим справляются, но мы проиграли
возврат к петлевой проверке в ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu()
с фиксацией 4832c30d5458 ("net: ipv6: включите маршруты хоста и произвольной рассылки"
устройство с адресом»).
KASAN: null-ptr-deref в диапазоне [0x0000000000000108-0x000000000000010f]
RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418)
Отслеживание вызова:
ip6_pol_route (net/ipv6/route.c:2318)
fib6_rule_lookup (net/ipv6/fib6_rules.c:115)
ip6_route_output_flags (net/ipv6/route.c:2607)
vrf_process_v6_outbound (drivers/net/vrf.c:437)
У меня возникло желание переработать код отмены подчинения, чтобы сначала очистить флаг.
и вставьтеsync_rcu(), прежде чем удалить верхний. Но похоже
явный возврат к loopback_dev является устоявшимся шаблоном.
И я думаю, что избегать синхронизации_rcu() тоже неплохо.
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: ipv6: fix NULL pointer deref in ip6_rt_get_dev_rcu() l3mdev_master_dev_rcu() can return NULL when the slave device is being un-slaved from a VRF. All other callers deal with this, but we lost the fallback to loopback in ip6_rt_pcpu_alloc() -> ip6_rt_get_dev_rcu() with commit 4832c30d5458 ("net: ipv6: put host and anycast routes on device with address"). KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:ip6_rt_pcpu_alloc (net/ipv6/route.c:1418) Call Trace: ip6_pol_route (net/ipv6/route.c:2318) fib6_rule_lookup (net/ipv6/fib6_rules.c:115) ip6_route_output_flags (net/ipv6/route.c:2607) vrf_process_v6_outbound (drivers/net/vrf.c:437) I was tempted to rework the un-slaving code to clear the flag first and insert synchronize_rcu() before we remove the upper. But looks like the explicit fallback to loopback_dev is an established pattern. And I guess avoiding the synchronize_rcu() is nice, too.