CVE-2023-53731

UnknownEPSS 0.21%

Last modified

CVE-2023-53731 is a vulnerability of currently unknown severity. In the Linux kernel, the following vulnerability has been resolved: netlink: fix potential deadlock in netlink_set_err() syzbot reported a possible deadlock in netlink_set_err() [1] A similar issue was fixed in commit 1d482e666b8e ("netlink: disable IRQs for netlink_lock_table()") in netlink_lock_table() This patch adds IRQ safety to netlink_set_err() and __netlink_diag_dump() which were not covered by cited commit. [1] WARNING: possible irq lock inversion dependency detected 6.4.0-rc6-syzkaller-00240-g4e9f0ec38852 #0 Not tainted syz-executor.2/23011 just changed the state of lock: ffffffff8e1a7a58 (nl_table_lock){.+.?}-{2:2}, at: netlink_set_err+0x2e/0x3a0 net/netlink/af_netlink.c:1612 but this lock was taken by another, SOFTIRQ-safe lock in the past: (&local->queue_stop_reason_lock){..-.}-{2:2} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nl_table_lock); local_irq_disable(); lock(&local->queue_stop_reason_lock); lock(nl_table_lock); <Interrupt> lock(&local->queue_stop_reason_lock); *** DEADLOCK ***. EPSS estimates a 0.21% chance of exploitation in the next 30 days.

Description

In the Linux kernel, the following vulnerability has been resolved: netlink: fix potential deadlock in netlink_set_err() syzbot reported a possible deadlock in netlink_set_err() [1] A similar issue was fixed in commit 1d482e666b8e ("netlink: disable IRQs for netlink_lock_table()") in netlink_lock_table() This patch adds IRQ safety to netlink_set_err() and __netlink_diag_dump() which were not covered by cited commit. [1] WARNING: possible irq lock inversion dependency detected 6.4.0-rc6-syzkaller-00240-g4e9f0ec38852 #0 Not tainted syz-executor.2/23011 just changed the state of lock: ffffffff8e1a7a58 (nl_table_lock){.+.?}-{2:2}, at: netlink_set_err+0x2e/0x3a0 net/netlink/af_netlink.c:1612 but this lock was taken by another, SOFTIRQ-safe lock in the past: (&local->queue_stop_reason_lock){..-.}-{2:2} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nl_table_lock); local_irq_disable(); lock(&local->queue_stop_reason_lock); lock(nl_table_lock); <Interrupt> lock(&local->queue_stop_reason_lock); *** DEADLOCK ***

Metrics

EPSS Probability
0.21%

11.4th percentile

Probability of exploitation in the next 30 days. Learn more

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
LinuxLinux>= 82b2ea5f904b3826934df4a00f3b8806272185f6, < c09e8e3f7fd432984bf5422302b093d2371dfc48; >= 59fba11d649854134c75ad88c8adafa9304ac419, < 4b9adb8d4a62ff7608d4a7d4eb42036a88f30980; >= 21df0c2e7d195de4a3c650de9361b3037fa6c59a, < 8f6652ed2ad98fe6d13b903483d9257762ab2ec6; >= 1d6d43d4805da9b3fa0f5841e8b1083c89868f35, < cde7b90e0539a3b11da377e463dfd2288a162dbf; >= 1d482e666b8e74c7555dbdfbfb77205eeed3ff2d, < a641240b7e071c5538dc0e7894ece833fce459dd; >= 1d482e666b8e74c7555dbdfbfb77205eeed3ff2d, < 61ffe8b1ee084e5c82a4e4bbf9e7b68e0c06e464; >= 1d482e666b8e74c7555dbdfbfb77205eeed3ff2d, < eb8e27c8fa9397b4a7b181c48fa58157dbe9902e; >= 1d482e666b8e74c7555dbdfbfb77205eeed3ff2d, < 1556ba034b95cfd4f75ea93c1a2679ae0444bba1; >= 1d482e666b8e74c7555dbdfbfb77205eeed3ff2d, < 8d61f926d42045961e6b65191c09e3678d86a9cf; 5f155c4046200f067b1dc3140ea99ef56e4e0b74; a8e9111a8625dd11e70edd61f7a1ccd26c041442; 76cc8e04f38c2bbfcba07f62864a011f142bd40c; >= 4.14.237, < 4.14.322; >= 4.19.195, < 4.19.291; >= 5.4.126, < 5.4.251; >= 5.10.44, < 5.10.188; >= 4.4.273, < 4.5; >= 4.9.273, < 4.10; >= 5.12.11, < 5.13
LinuxLinux5.13

References

Timeline

Published
Last Modified
Status
Deferred

Frequently Asked Questions

What is CVE-2023-53731?
In the Linux kernel, the following vulnerability has been resolved: netlink: fix potential deadlock in netlink_set_err() syzbot reported a possible deadlock in netlink_set_err() [1] A similar issue was fixed in commit 1d482e666b8e ("netlink: disable IRQs for netlink_lock_table()") in netlink_lock_table() This patch adds IRQ safety to netlink_set_err() and __netlink_diag_dump() which were not covered by cited commit. [1] WARNING: possible irq lock inversion dependency detected 6.4.0-rc6-syzkaller-00240-g4e9f0ec38852 #0 Not tainted syz-executor.2/23011 just changed the state of lock: ffffffff8e1a7a58 (nl_table_lock){.+.?}-{2:2}, at: netlink_set_err+0x2e/0x3a0 net/netlink/af_netlink.c:1612 but this lock was taken by another, SOFTIRQ-safe lock in the past: (&local->queue_stop_reason_lock){..-.}-{2:2} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nl_table_lock); local_irq_disable(); lock(&local->queue_stop_reason_lock); lock(nl_table_lock); <Interrupt> lock(&local->queue_stop_reason_lock); *** DEADLOCK ***
How severe is CVE-2023-53731?
Severity scoring for CVE-2023-53731 is pending analysis. The EPSS model estimates a 0.21% probability of exploitation in the next 30 days.
How do I fix CVE-2023-53731?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2023

Are you affected by CVE-2023-53731?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST