CWE-911БазаНеполный
Некорректное обновление счётчика ссылок
Продукт использует счётчик ссылок для управления ресурсом, однако не обновляет счётчик ссылок или обновляет его некорректно.
Открыть в каталоге с фильтром CWE →Связанные CAPEC
—
Связанные уязвимости
CVE-2024-46972Программное обеспечение, установленное и запущенное как непривилегированный пользователь, может проводить неправильные системные вызовы GPU, что может привести к исключениям ядра после освобождения.
CVE-2023-5633Изменения подсчета ссылок, внесенные в рамках исправлений CVE-2023-33951 и CVE-2023-33952, выявили недостаток использования памяти после освобождения в способе обработки объектов памяти, когда они использовались для хранения поверхности. При работе внутри гостевой машины VMware с включенным 3D-ускорением локальный пользователь без привилегий потенциально мог использовать этот недостаток для повышения своих привилегий.
CVE-2022-29581Неправильное обновление счетчика ссылок в net/sched ядра Linux позволяет локальному злоумышленнику вызвать повышение привилегий до root. Эта проблема затрагивает: версии ядра Linux до 5.18; версия 4.14 и более поздние версии.
CVE-2023-22394Уязвимость, связанная с неправильной обработкой неожиданного типа данных при обработке вызовов SIP в Juniper Networks Junos OS на платформах SRX Series и MX Series, позволяет злоумышленнику вызвать утечку памяти, приводящую к отказу в обслуживании (DoS). Эта проблема возникает на всех платформах MX Series с картой MS-MPC или MS-MIC и на всех платформах SRX Series, где включен SIP ALG. Успешная эксплуатация этой уязвимости не позволяет дополнительным вызовам SIP и приложениям быть успешными. SIP ALG должен быть включен, либо неявно/по умолчанию, либо посредством конфигурации. Чтобы подтвердить, включен ли SIP ALG на SRX, используйте следующую команду: user@host> show security alg status | match sip SIP : Enabled Эта проблема затрагивает Juniper Networks Junos OS на SRX Series и на MX Series: Все версии до 19.3R3-S7; версии 19.4 до 19.4R2-S8, 19.4R3-S10; версии 20.1 20.1R1 и более поздние версии; версии 20.2 до 20.2R3-S6; версии 20.3 до 20.3R3-S6; версии 20.4 до 20.4R3-S5; версии 21.1 до 21.1R3-S5; версии 21.2 до 21.2R3-S1; версии 21.3 до 21.3R3; версии 21.4 до 21.4R2-S2, 21.4R3; версии 22.1 до 22.1R1-S2, 22.1R2, 22.1R3-S1. Эта проблема не затрагивает Juniper Networks Junos OS на SRX Series и на MX Series: Все версии до 18.2R1.
CVE-2022-37012Эта уязвимость позволяет удаленным злоумышленникам создавать состояние отказа в обслуживании на затронутых установках Unified Automation OPC UA C++ Demo Server 1.7.6-537. Аутентификация не требуется для'exploitation этой уязвимости. Конкретный недостаток существует внутри метода OpcUa_SecureListener_ProcessSessionCallRequest. Составленное сообщение OPC UA может заставить сервер неправильно обновить статистику ссылок. Злоумышленник может использовать эту уязвимость для создания состояния отказа в обслуживании на системе. Задействован ZDI-CAN-16927.
CVE-2022-22195Некорректное обновление счетчика ссылок в ядре Juniper Networks Junos OS Evolved позволяет не прошедшему проверку подлинности злоумышленнику, находящемуся в сети, вызвать переполнение счетчика, что в конечном итоге приведет к отказу в обслуживании (DoS). Эта проблема затрагивает Juniper Networks Junos OS Evolved: все версии до 20.4R3-S1-EVO; версии 21.1 до 21.1R3-EVO; версии 21.2 до 21.2R3-EVO; версии 21.3 до 21.3R2-EVO. Эта проблема не затрагивает Juniper Networks Junos OS.
CVE-2022-1678В ядре Linux с версии 4.18 до 4.19 неправильное обновление ссылки sock в TCP pacing может привести к утечке памяти/netns, которая может быть использована удаленными клиентами.
CVE-2023-6270В драйвере ATA over Ethernet (AoE) в ядре Linux была обнаружена ошибка. Функция aoecmd_cfg_pkts() неправильно обновляет refcnt в `struct net_device`, и use-after-free может быть вызван гонкой между освобождением структуры и доступом к ней через глобальную очередь `skbtxq`. Это может привести к состоянию отказа в обслуживании или потенциальному выполнению кода.
CVE-2022-3910Уязвимость Use After Free в ядре Linux позволяет повысить привилегии. Неправильное обновление счетчика ссылок в io_uring приводит к Use-After-Free и Local Privilege Escalation. Когда io_msg_ring вызывался с фиксированным файлом, он вызывал io_fput_file(), который неправильно уменьшал его счетчик ссылок (что приводило к Use-After-Free и Local Privilege Escalation). Фиксированные файлы постоянно регистрируются в кольце и не должны размещаться отдельно. Мы рекомендуем обновиться после коммита https://github.com/torvalds/linux/commit/fc7222c3a9f56271fba02aabbfbae999042f1679 https://github.com/torvalds/linux/commit/fc7222c3a9f56271fba02aabbfbae999042f1679
CVE-2022-3649В ядре Linux обнаружена уязвимость. Ей присвоена классификация problematic. Уязвимой является функция nilfs_new_inode файла fs/nilfs2/inode.c компонента BPF. Манипуляция приводит к use after free. Можно начать атаку удаленно. Рекомендуется применить патч для устранения этой проблемы. Идентификатор этой уязвимости — VDB-211992.
CVE-2024-40913В ядре Linux устранена следующая уязвимость:
cachefiles: отложить предоставление anon_fd до успешного выполнения copy_to_user()
После установки анонимного fd мы теперь можем видеть его в пользовательском пространстве и закрыть его.
Однако в этот момент мы, возможно, не получили счетчик ссылок кеша, но мы поместим его во время закрытия fd, поэтому это может вызвать UAF кеша.
Поэтому захватите счетчик ссылок кеша перед fd_install(). Кроме того, по соглашению ядра, fd переходит к пользовательскому пространству после fd_install(), и ядро не должно вызывать close_fd() после этого, то есть оно должно вызывать fd_install() после того, как все будет готово, таким образом, fd_install() вызывается после успешного выполнения copy_to_user().
CVE-2024-43850В ядре Linux устранена следующая уязвимость:
soc: qcom: icc-bwmon: Исправлен дисбаланс счетчика ссылок, наблюдаемый во время bwmon_remove.
Во время bwmon_remove наблюдается следующее предупреждение из-за дисбаланса счетчика ссылок, исправим это, освободив OPP после использования.
Логи:
WARNING: at drivers/opp/core.c:1640 _opp_table_kref_release+0x150/0x158
Hardware name: Qualcomm Technologies, Inc. X1E80100 CRD (DT)
...
Call trace:
_opp_table_kref_release+0x150/0x158
dev_pm_opp_remove_table+0x100/0x1b4
devm_pm_opp_of_table_release+0x10/0x1c
devm_action_release+0x14/0x20
devres_release_all+0xa4/0x104
device_unbind_cleanup+0x18/0x60
device_release_driver_internal+0x1ec/0x228
driver_detach+0x50/0x98
bus_remove_driver+0x6c/0xbc
driver_unregister+0x30/0x60
platform_driver_unregister+0x14/0x20
bwmon_driver_exit+0x18/0x524 [icc_bwmon]
__arm64_sys_delete_module+0x184/0x264
invoke_syscall+0x48/0x118
el0_svc_common.constprop.0+0xc8/0xe8
do_el0_svc+0x20/0x2c
el0_svc+0x34/0xdc
el0t_64_sync_handler+0x13c/0x158
el0t_64_sync+0x190/0x194
--[ end trace 0000000000000000 ]---
CVE-2024-40983В ядре Linux устранена следующая уязвимость:
tipc: принудительно увеличивать счетчик ссылок dst перед выполнением дешифрования
Как указано в коммите 3bc07321ccc2 ("xfrm: Принудительно увеличивать счетчик ссылок dst перед входом в обработчики типов xfrm"):
"Криптографические запросы могут возвращаться асинхронно. В этом случае мы покидаем защищенную RCU область, поэтому принудительно увеличиваем счетчик ссылок для записи назначения skb перед тем, как войти в обработчики ввода/вывода типа xfrm."
На пути дешифрования TIPC возникает та же проблема, и skb_dst_force() следует вызывать перед выполнением дешифрования, чтобы избежать возможного сбоя.
Shuang сообщил об этой проблеме, когда срабатывает следующее предупреждение:
[] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc]
[] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug
[] Workqueue: crypto cryptd_queue_worker
[] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc]
[] Call Trace:
[] tipc_sk_mcast_rcv+0x548/0xea0 [tipc]
[] tipc_rcv+0xcf5/0x1060 [tipc]
[] tipc_aead_decrypt_done+0x215/0x2e0 [tipc]
[] cryptd_aead_crypt+0xdb/0x190
[] cryptd_queue_worker+0xed/0x190
[] process_one_work+0x93d/0x17e0
CVE-2024-40910В ядре Linux устранена следующая уязвимость:
ax25: Исправлен дисбаланс счетчика ссылок для входящих соединений.
При высвобождении сокета в ax25_release() мы вызываем netdev_put() для уменьшения счетчика ссылок на связанное устройство ax.25. Однако путь выполнения для принятия входящего соединения никогда не вызывает netdev_hold(). Этот дисбаланс приводит к ошибкам счетчика ссылок и, в конечном итоге, к сбоям ядра.
Типичная трассировка вызовов для вышеописанной ситуации начинается с одной из следующих ошибок:
refcount_t: decrement hit 0; leaking memory.
refcount_t: underflow; use-after-free.
И затем имеет трассировку, подобную следующей:
Call Trace:
<TASK>
? show_regs+0x64/0x70
? __warn+0x83/0x120
? refcount_warn_saturate+0xb2/0x100
? report_bug+0x158/0x190
? prb_read_valid+0x20/0x30
? handle_bug+0x3e/0x70
? exc_invalid_op+0x1c/0x70
? asm_exc_invalid_op+0x1f/0x30
? refcount_warn_saturate+0xb2/0x100
? refcount_warn_saturate+0xb2/0x100
ax25_release+0x2ad/0x360
__sock_release+0x35/0xa0
sock_close+0x19/0x20
[...]
При перезагрузке (или любой попытке удалить интерфейс) ядро застревает в бесконечном цикле:
unregister_netdevice: waiting for ax0 to become free. Usage count = 0
Этот патч исправляет эти проблемы, обеспечивая вызов netdev_hold() и ax25_dev_hold() для новых соединений в ax25_accept(). Это делает логику, приводящую к ax25_accept(), соответствующей логике для ax25_bind(): в обоих случаях мы увеличиваем счетчик ссылок, который в конечном итоге уменьшается в ax25_release().
CVE-2024-35932В ядре Linux устранена следующая уязвимость:
drm/vc4: не проверять, plane->state->fb == state->fb
В настоящее время при использовании неблокирующих коммитов можно увидеть следующее предупреждение ядра:
[ 110.908514] ------------[ cut here ]------------
[ 110.908529] refcount_t: underflow; use-after-free.
[ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0
[ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6
[ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32
[ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
[ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0
[ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0
[ 110.909170] sp : ffffffc00913b9c0
[ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60
[ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480
[ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78
[ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000
[ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004
[ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003
[ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00
[ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572
[ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000
[ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001
[ 110.909434] Call trace:
[ 110.909441] refcount_dec_not_one+0xb8/0xc0
[ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]
[ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4]
[ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]
[ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4]
[ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper]
[ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]
[ 110.911716] drm_atomic_commit+0xb0/0xdc [drm]
[ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm]
[ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm]
[ 110.914091] drm_ioctl+0x24c/0x3b0 [drm]
[ 110.914850] __arm64_sys_ioctl+0x9c/0xd4
[ 110.914873] invoke_syscall+0x4c/0x114
[ 110.914897] el0_svc_common+0xd0/0x118
[ 110.914917] do_el0_svc+0x38/0xd0
[ 110.914936] el0_svc+0x30/0x8c
[ 110.914958] el0t_64_sync_handler+0x84/0xf0
[ 110.914979] el0t_64_sync+0x18c/0x190
[ 110.914996] ---[ end trace 0000000000000000 ]---
Это происходит потому, что, хотя `prepare_fb` и `cleanup_fb` идеально сбалансированы, мы не можем гарантировать согласованность при проверке plane->state->fb == state->fb. Это означает, что иногда мы можем увеличить refcount в `prepare_fb` и не уменьшить его в `cleanup_fb`. Противоположное тоже может быть правдой.
Фактически, struct drm_plane .state не следует получать напрямую, вместо этого следует использовать вспомогательную функцию `drm_atomic_get_new_plane_state()`. Таким образом, мы могли бы придерживаться этой проверки, но используя `drm_atomic_get_new_plane_state()`. Но на самом деле эта проверка не является...
---truncated---