CVE-2026-64057High· 7.8▾ TwilightIn the Linux kernel, the following vulnerability has been resolved: afs: Fix the locking used by afs_get_link() The afs filesystem in the kernel doesn't do locking correctly for symbolic links. There are a number of problems: (1) It…
▾ 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.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via NVD
Last analysed / modified upstream
0.1%
In the Linux kernel, the following vulnerability has been resolved:
afs: Fix the locking used by afs_get_link()
The afs filesystem in the kernel doesn't do locking correctly for symbolic links. There are a number of problems:
(1) It doesn't do any locking around afs_read_single() to prevent races between multiple ->get_link() calls, thereby allowing the possibility of leaks.
(2) It doesn't use RCU barriering when accessing the buffer pointers during RCU pathwalk.
(3) It can race with another thread updating the contents of the symlink if a third party updated it on the server.
Fix this by the following means:
(0) Move symlink handling into its own file as this makes it more complicated.
(1) Take the validate_lock around afs_read_single() to prevent races between multiple ->get_link() calls.
(2) Keep a separate copy of the symlink contents with an rcu_head. This is always going to be a lot smaller than a page, so it can be kmalloc'd and save quite a bit of memory. It also needs a refcount for non-RCU pathwalk.
(3) Split the symlink read and write-to-cache routines in afs from those for directories.
(4) Discard the I/O buffer as soon as the write-to-cache completes as this is a full page (plus a folio_queue).
(5) If there's no cache, discard the I/O buffer immediately after reading and copying if there is no cache.
linux_kernel >= 6.14, < 7.0.11linux_kernel = 7.1Upgrade past the affected range:
linux_kernel 7.0.11Connected by shared product, vendor, weakness, or advisory.
CVE-2026-53071High· 8.8In the Linux kernel, the following vulnerability has been resolved: Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding l2cap_chan_lock()
CVE-2026-23470Medium· 5.5In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix deadlock in soft reset sequence The soft reset sequence is currently executed from the threaded IRQ handler, hence it cannot call disable_irq() wh…
CVE-2026-46252Medium· 5.5In the Linux kernel, the following vulnerability has been resolved: regulator: core: fix locking in regulator_resolve_supply() error path If late enabling of a supply regulator fails in regulator_resolve_supply(), the code currently tr…
CVE-2026-100075Critical· 9.8In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Fix srpt_alloc_rw_ctxs() unwind counters When srpt_alloc_rw_ctxs() fails partway through a multi-buffer indirect descriptor, the unwind path destroys RDMA c…
CVE-2026-100074Medium· 5.5In the Linux kernel, the following vulnerability has been resolved: bpf: Mark bpf_refcount field as unique BPF_REFCOUNT is not marked as a unique field, while it should be
CVE-2026-100077Medium· 5.5In the Linux kernel, the following vulnerability has been resolved: drm/msm: Recover HW before retire hung submit During recovery, it is not safe to retire the hung submit before we recover the GPU