В ядре Linux устранена следующая уязвимость:
net/mlx5e: macsec: исправлено использование после освобождения Metadata_dst при удалении RX SC. Когда выгруженный MACsec RX SC удаляется, macsec_del_rxsc_ctx() освобождается.
метаданные_dst для каждого SC с помощью Metadata_dst_free(), который является kfree()
объект безоговорочно и игнорирует счетчик ссылок dst. Приёмник
datapath в mlx5e_macsec_offload_handle_rx_skb() ищет SC под
rcu_read_lock() через xa_load(), принимает ссылку с помощью dst_hold() и
присоединяет dst к skb с помощью skb_dst_set().
Читатель, который уже
полученный указатель rx_sc может соревноваться с путем удаления и работать
освободилась память. Исправьте сторону владельца, удалив ссылку с помощью dst_release().
безусловного освобождения и преобразования пути данных RX в
dst_hold_safe(), чтобы читатель, участвующий в удалении SC, не мог прикрепить dst
чья последняя ссылка была только что удалена; прикрепляйте его только тогда, когда ссылка
действительно был взят.
mlx5e_macsec_add_rxsc() также опубликовал sc_xarray_element через xa_alloc()
до того, как rx_sc->md_dst был выделен и инициализирован, поэтому читатель пути к данным
который просмотрел SC по fs_id, все еще мог наблюдать rx_sc с md_dst
NULL или, в слабоупорядоченных архитектурах, ненулевой указатель md_dst.
содержимое которого еще не было видно. NULL-проверьте результат xa_load() и
md_dst в пути к данным и измените порядок add_rxsc(), чтобы xa_alloc() опубликовал
происходит только после полной инициализации md_dst; публикация xarray RCU
затем соединяется с rcu_read_lock()/xa_load() в пути к данным.
Примечание: macsec_del_rxsc_ctx() также kfree() rx_sc->sc_xarray_element
без льготного периода RCU, в то время как тот же путь данных читает его под
rcu_read_lock(); это отдельная ранее существовавшая проблема, оставленная на усмотрение
последующий патч. Обнаружен с помощью автоматизированного инструмента исследования безопасности 0sec (https://0sec.ai).
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: macsec: fix use-after-free of metadata_dst on RX SC delete When an offloaded MACsec RX SC is deleted, macsec_del_rxsc_ctx() freed the per-SC metadata_dst with metadata_dst_free(), which kfree()s the object unconditionally and ignores the dst reference count. The RX datapath in mlx5e_macsec_offload_handle_rx_skb() looks up the SC under rcu_read_lock() via xa_load(), takes a reference with dst_hold() and attaches the dst to the skb with skb_dst_set(). A reader that already obtained the rx_sc pointer can race with the delete path and operate on freed memory. Fix the owner side by dropping the reference with dst_release() instead of freeing unconditionally, and convert the RX datapath to dst_hold_safe() so a reader racing the SC delete cannot attach a dst whose last reference was just dropped; only attach it when a reference was actually taken. mlx5e_macsec_add_rxsc() also published sc_xarray_element via xa_alloc() before rx_sc->md_dst was allocated and initialised, so a datapath reader that looked the SC up by fs_id could observe rx_sc with md_dst still NULL or, on weakly-ordered architectures, a non-NULL md_dst pointer whose contents were not yet visible. NULL-check the xa_load() result and md_dst on the datapath, and reorder add_rxsc() so the xa_alloc() publish happens only after md_dst is fully initialised; the xarray RCU publish then pairs with the rcu_read_lock()/xa_load() in the datapath. Note: macsec_del_rxsc_ctx() also kfree()s rx_sc->sc_xarray_element without an RCU grace period while the same datapath reads it under rcu_read_lock(); that is a separate pre-existing issue left to a follow-up patch. Found by 0sec automated security-research tooling (https://0sec.ai).
Характеристики атаки
Последствия
Строка CVSS v3.1