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

CVE-2026-46047: In the Linux kernel, net: qrtr: ns use-after-free in driver remove is fixed. The vulnerability arises if a packet arrives after destroy_workqueue() but before sock_release(), causing qrtr_ns_data_ready() to queue a work item that dereferences freed memory. Root and distro advisori...

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...