Status: UPDATED | Advisory ID: CVE-2026-52946
| CVE | CVE-2026-52946 |
| CVSS Score / Version | 7.5 (High) / CVSS v3.1 |
| Updated | 2026-09-08 |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H |
| CVSS Prose | attack vector is network; attack complexity is low; privileges required is none; user interaction is none; scope is unchanged; confidentiality impact is none; integrity impact is none; availability impact is high. |
| Affected products | Siemens SIMATIC S7-1500 CPU 1518-4 PN/DP MFP, Siemens SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP, and Siemens SIPLUS S7-1500 CPU 1518-4 PN/DP MFP |
| Classified as | CWE-667 (Improper Locking) |
| Vendor | Product | Affected Versions | Patch Status |
|---|---|---|---|
| Siemens | SIMATIC S7-1500 CPU 1518-4 PN/DP MFP | ||
| Siemens | SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP | ||
| Siemens | SIPLUS S7-1500 CPU 1518-4 PN/DP MFP |
| Subsystems | General OT |
| Sectors | Multiple |
In the Linux kernel, the following vulnerability has been resolved:
fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in
send_sigio() and send_sigurg() when a process group receives a signal.
When FASYNC is configured for a process group (PIDTYPE_PGID), both
functions use read_lock(&tasklist_lock) to traverse the task list.
However, they are frequently called from softirq context:
- send_sigio() via input_inject_event -> kill_fasync
- send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ)
The deadlock is caused by the rwlock writer fairness mechanism:
1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait().
2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in
fork() or exit() and spins, which blocks all new readers.
3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).
4. The softirq calls send_sigurg() and attempts to acquire
read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.
Since PID hashing and do_each_pid_task() traversals are already
RCU-protected, the read_lock on tasklist_lock is no longer strictly
required for safe traversal. Fix this by replacing tasklist_lock with
rcu_read_lock(), aligning the process group signaling path with the
single-PID path. This also mitigates a potential remote denial of
service vector via TCP URG packets.
Lockdep splat:
=====================================================
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
[...]
Chain exists of:
&dev->event_lock --> &f_owner->lock --> tasklist_lock
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(tasklist_lock);
local_irq_disable();
lock(&dev->event_lock);
lock(&f_owner->lock);
<Interrupt>
lock(&dev->event_lock);
*** DEADLOCK *** (NVD)
Monitor Siemens's web page for any future patch releases.
| Source | Reference |
|---|---|
| NVD | https://nvd.nist.gov/vuln/detail/CVE-2026-52946 |
| CVE | https://www.cve.org/CVERecord?id=CVE-2026-52946 |