SUSE CVE-2026-46047

In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Fix use-after-free in driver remove In the remove callback, if a packet arrives after destroyworkqueue is called, but before sockrelease, the qrtrnsdataready callback will try to queue the work, causing...

CVE-2026-46047

In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Fix use-after-free in driver remove In the remove callback, if a packet arrives after destroyworkqueue is called, but before sockrelease, the qrtrnsdataready callback will try to queue the work, causing...

UBUNTU-CVE-2026-46047

In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Fix use-after-free in driver remove In the remove callback, if a packet arrives after destroyworkqueue is called, but before sockrelease, the qrtrnsdataready callback will try to queue the work, causing...

EUVD-2026-32429

In the Linux kernel, the following vulnerability has been resolved: net: qrtr: ns: Fix use-after-free in driver remove In the remove callback, if a packet arrives after destroyworkqueue is called, but before sockrelease, the qrtrnsdataready callback will try to queue the work, causing...

CVE-2026-46047

The CVE-2026-46047 entry describes a use-after-free in the Linux kernel net: qrtr: ns driver removal path. In the remove callback, if a packet arrives between destroy_workqueue() and sock_release(), the qrtr_ns_data_ready() callback may attempt to queue work, dereferencing a freed work item. The ...

PT-2026-43914

Name of the Vulnerable Software and Affected Versions Linux kernel affected versions not specified Description A use-after-free issue exists in the QRTR nameservice driver during the remove process. If a packet arrives after destroy workqueue is called but before sock release, the qrtr ns data...

CVE-2026-23179

The CVE affects the Linux kernel nvmet-tcp implementation. A deadlock could occur when a socket is closed during TCP_LISTEN because nvmet_tcp_listen_data_ready() is called with sk_callback_lock held; the fix adds a TCP_LISTEN check before acquiring the lock to avoid deadlock. The issue is resolve...