В ядре Linux устранена следующая уязвимость:
net/rds: исправлена зависимость циклической блокировки в rds_tcp_tune.
syzbot сообщил о зависимости циклической блокировки в rds_tcp_tune(), где
sk_net_refcnt_upgrade() вызывается при удержании блокировки сокета:
===================================================
ВНИМАНИЕ: обнаружена возможная зависимость от циклической блокировки.
===================================================
kworker/u10:8/15040 пытается получить блокировку:
ffffffff8e9aaf80 (fs_reclaim){+.+.}-{0:0},
по адресу: __kmalloc_cache_noprof+0x4b/0x6f0
но задача уже удерживает блокировку:
ffff88805a3c1ce0 (k-sk_lock-AF_INET6){+.+.}-{0:0},
по адресу: rds_tcp_tune+0xd7/0x930
Проблема возникает из-за того, что sk_net_refcnt_upgrade() выполняет обработку памяти.
выделение (через get_net_track() -> ref_tracker_alloc()), в то время как
блокировка сокета удерживается, создавая циклическую зависимость с fs_reclaim.
Исправьте это, переместив sk_net_refcnt_upgrade() за пределы блокировки сокета.
критический раздел. Это безопасно, поскольку поля, измененные
Вызов sk_net_refcnt_upgrade() (sk_net_refcnt, ns_tracker) не является
доступ к любому параллельному пути кода на этом этапе.
версия 2:
- Исправлен тег исправлений
- проверьте гниды наматывания патч-линий
- ай комментарии гниды
Показать оригинальное описание (EN)
In the Linux kernel, the following vulnerability has been resolved: net/rds: Fix circular locking dependency in rds_tcp_tune syzbot reported a circular locking dependency in rds_tcp_tune() where sk_net_refcnt_upgrade() is called while holding the socket lock: ====================================================== WARNING: possible circular locking dependency detected ====================================================== kworker/u10:8/15040 is trying to acquire lock: ffffffff8e9aaf80 (fs_reclaim){+.+.}-{0:0}, at: __kmalloc_cache_noprof+0x4b/0x6f0 but task is already holding lock: ffff88805a3c1ce0 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: rds_tcp_tune+0xd7/0x930 The issue occurs because sk_net_refcnt_upgrade() performs memory allocation (via get_net_track() -> ref_tracker_alloc()) while the socket lock is held, creating a circular dependency with fs_reclaim. Fix this by moving sk_net_refcnt_upgrade() outside the socket lock critical section. This is safe because the fields modified by the sk_net_refcnt_upgrade() call (sk_net_refcnt, ns_tracker) are not accessed by any concurrent code path at this point. v2: - Corrected fixes tag - check patch line wrap nits - ai commentary nits