CVE-2026-23103High· 7.8▾ TwilightIn the Linux kernel, the following vulnerability has been resolved: ipvlan: Make the addrs_lock be per port Make the addrs_lock be per port, not per ipvlan dev. Initial code seems to be written in the assumption, that any address chan…
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 42.9 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake.
Exploit-prediction probability, daily snapshots since Sep 8.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
0.1%
7.8 → 4.7
high → medium
Last analysed / modified upstream
4.7 → 7.8
medium → high
0.1% → 0.1%
In the Linux kernel, the following vulnerability has been resolved:
ipvlan: Make the addrs_lock be per port
Make the addrs_lock be per port, not per ipvlan dev.
Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So
Introduce per-port addrs_lock.
It was needed to fix places where it was forgotten to take lock (ipvlan_open/ipvlan_close)
This appears to be a very minor problem though. Since it's highly unlikely that ipvlan_add_addr() will be called on 2 CPU simultaneously. But nevertheless, this could cause:
False-negative of ipvlan_addr_busy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlan_addr6_event() can be called without rtnl_lock.
Race since ipvlan_ht_addr_add(port) is called under different ipvlan->addrs_lock locks
This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths.
linux_kernel >= 4.17, < 5.10.249linux_kernel >= 5.11, < 5.15.199linux_kernel >= 5.16, < 6.1.162linux_kernel >= 6.2, < 6.6.122linux_kernel >= 6.7, < 6.12.68linux_kernel >= 6.13, < 6.18.8linux_kernel = 6.19Upgrade past the affected range:
linux_kernel 6.18.8Field changes observed since this record was first indexed.
Connected by shared product, vendor, weakness, or advisory.
CVE-2020-36311Medium· 5.5An issue was discovered in the Linux kernel before 5.9
CVE-2025-38232High· 7.8In the Linux kernel, the following vulnerability has been resolved: NFSD: fix race between nfsd registration and exports_proc As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at …
CVE-2025-71075High· 7.8In the Linux kernel, the following vulnerability has been resolved: scsi: aic94xx: fix use-after-free in device removal path The asd_pci_remove() function fails to synchronize with pending tasklets before freeing the asd_ha structure, …
CVE-2025-71221High· 7.8In the Linux kernel, the following vulnerability has been resolved: dmaengine: mmp_pdma: Fix race condition in mmp_pdma_residue() Add proper locking in mmp_pdma_residue() to prevent use-after-free when accessing descriptor list and des…
CVE-2023-53292Medium· 5.5In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_none After grabbing q->sysfs_lock, q->elevator may become NULL because of elevator switch. Fix the NU…
CVE-2020-36558Medium· 5.1A race condition in the Linux kernel before 5.5.7 involving VT_RESIZEX could lead to a NULL pointer dereference and general protection fault.