mirror of
https://github.com/torvalds/linux.git
synced 2026-11-07 06:17:02 +01:00
9c7e89fc1b
ncsi_vlan_rx_kill_vid() removes an entry from the NCSI VLAN list with:
list_for_each_entry_safe(vlan, tmp, &ndp->vlan_vids, list)
if (vlan->vid == vid) {
list_del_rcu(&vlan->list);
found = true;
kfree(vlan);
}
The list is published with list_add_rcu(), so readers traverse it
under rcu_read_lock(). The writer holds only the RTNL, which does not
exclude those readers. list_for_each_entry_safe() protects the writer
iteration itself, not concurrent readers.
The reader is set_one_vid(), invoked from the NCSI channel
configuration state machine (ndp->work) while sending the "Set VLAN
Filter" command:
rcu_read_lock();
list_for_each_entry_rcu(vlan, &ndp->vlan_vids, list) {
vid = vlan->vid;
...
}
rcu_read_unlock();
An RCU read-side critical section only protects objects released via
call_rcu()/kfree_rcu(); it does not protect against the immediate
kfree() above. If the state machine work has already obtained the
list entry pointer and is then scheduled out while another CPU removes
the VLAN id, the resumed iteration reads the freed node and follows
the ->next pointer of reused memory.
This is reachable on BMC systems using NCSI when a VLAN id is deleted
(ip link / rtnetlink) concurrently with an NCSI configuration cycle.
Fix this by adding an rcu_head to struct vlan_vid and releasing the
node with kfree_rcu().
Found during a static-analysis-assisted audit: candidate sites were
surfaced by a Coccinelle rule, and the reader/writer paths were
confirmed by LLM-assisted (GLM-5.3) code inspection. The issue was
not observed at runtime; it is identified by code inspection only.
Cc: stable+noautosel@kernel.org # LLM report + LLM fix, not seen in real life
Fixes:
|
||
|---|---|---|
| .. | ||
| internal.h | ||
| Kconfig | ||
| Makefile | ||
| ncsi-aen.c | ||
| ncsi-cmd.c | ||
| ncsi-manage.c | ||
| ncsi-netlink.c | ||
| ncsi-netlink.h | ||
| ncsi-pkt.h | ||
| ncsi-rsp.c | ||