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

exploitDog

nvd логотип

CVE-2026-46246

Опубликовано: 03 июн. 2026
Источник: nvd
CVSS3: 7.8
EPSS Низкий

Описание

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

power: supply: pm8916_lbc: Fix use-after-free for extcon in IRQ handler

Using the devm_ variant for requesting IRQ before the devm_ variant for allocating/registering the extcon handle, means that the extcon handle will be deallocated/unregistered before the interrupt handler (since devm_ naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just after the extcon handle has been freed, but just before the corresponding unregistration of the IRQ handler has run.

This will lead to the IRQ handler calling extcon_set_state_sync() with a freed extcon handle. Which usually crashes the system or otherwise silently corrupts the memory...

Fix this racy use-after-free by making sure the IRQ is requested after the registration of the extcon handle.

Уязвимые конфигурации

Конфигурация 1

Одно из

cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Версия от 6.7 (включая) до 6.12.75 (исключая)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Версия от 6.13 (включая) до 6.18.14 (исключая)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Версия от 6.19 (включая) до 6.19.4 (исключая)

EPSS

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

7.8 High

CVSS3

Дефекты

CWE-416

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

CVSS3: 7.8
ubuntu
2 месяца назад

In the Linux kernel, the following vulnerability has been resolved: power: supply: pm8916_lbc: Fix use-after-free for extcon in IRQ handler Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `extcon` handle, means that the `extcon` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `extcon` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `extcon_set_state_sync()` with a freed `extcon` handle. Which usually crashes the system or otherwise silently corrupts the memory... Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `extcon` handle.

redhat
2 месяца назад

In the Linux kernel, the following vulnerability has been resolved: power: supply: pm8916_lbc: Fix use-after-free for extcon in IRQ handler Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `extcon` handle, means that the `extcon` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `extcon` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `extcon_set_state_sync()` with a freed `extcon` handle. Which usually crashes the system or otherwise silently corrupts the memory... Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `extcon` handle.

CVSS3: 7.8
debian
2 месяца назад

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

CVSS3: 7.8
github
2 месяца назад

In the Linux kernel, the following vulnerability has been resolved: power: supply: pm8916_lbc: Fix use-after-free for extcon in IRQ handler Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `extcon` handle, means that the `extcon` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `extcon` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `extcon_set_state_sync()` with a freed `extcon` handle. Which usually crashes the system or otherwise silently corrupts the memory... Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `extcon` handle.

EPSS

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

7.8 High

CVSS3

Дефекты

CWE-416