Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

msrc логотип

CVE-2026-93054

Опубликовано: 19 сент. 2026
Источник: msrc
CVSS3: 5.5
EPSS Низкий

Описание

uio: Fix stale info pointer in failed registration path

Обновления

ПродуктСтатьяОбновление
azl3 kernel 6.6.150.1-1 on Azure Linux 3.0
azl3 kernel 6.6.152.1-1 on Azure Linux 3.0
-

Показывать по

EPSS

Процентиль: 4%
0.00145
Низкий

5.5 Medium

CVSS3

Связанные уязвимости

CVSS3: 7
ubuntu
7 дней назад

(In the Linux kernel, the following vulnerability has been resolved: u ...)

CVSS3: 7
nvd
7 дней назад

In the Linux kernel, the following vulnerability has been resolved: uio: Fix stale info pointer in failed registration path After device_add(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, __uio_register_device() unwinds the device but leaves idev->info pointing at the caller-owned struct uio_info. That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uio_device, while the caller sees registration failure and may free its struct uio_info. Later file operations can then follow idev->info and dereference freed memory. Handle post-device_add() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under info_lock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same "device gone" state as normal uio_unregister_device().

CVSS3: 7
debian
7 дней назад

In the Linux kernel, the following vulnerability has been resolved: u ...

CVSS3: 7
github
7 дней назад

In the Linux kernel, the following vulnerability has been resolved: uio: Fix stale info pointer in failed registration path After device_add(), the UIO device is visible to userspace and /dev/uioX can be opened. If a later setup step fails, __uio_register_device() unwinds the device but leaves idev->info pointing at the caller-owned struct uio_info. That is unsafe when an opener races with the failed registration path. The open file keeps a reference to the uio_device, while the caller sees registration failure and may free its struct uio_info. Later file operations can then follow idev->info and dereference freed memory. Handle post-device_add() failures like unregister: remove UIO attributes while the info pointer is still valid, then clear idev->info under info_lock and wake existing waiters/async users before removing the device and minor. This makes already-open file descriptors observe the same "device gone" state as normal uio_unregister_device().

EPSS

Процентиль: 4%
0.00145
Низкий

5.5 Medium

CVSS3