CVE WatchOct 15, 2026

CVE-2026-23357

In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix deadlock in error path of mcp251x_open The mcp251x_o

CVSS

5.5

Medium

EPSS

0.1%

KEV

—

Exploit Today

0-100

Published: Mar 25, 2026 · Last modified: Oct 15, 2026 · CWE-667

EPSS · 30d

0.1%EPSS · 30 days0.1%

2026-10-042026-10-31

Technical description

In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix deadlock in error path of mcp251x_open The mcp251x_open() function call free_irq() in its error path with the mpc_lock mutex held. But if an interrupt already occurred the interrupt handler will be waiting for the mpc_lock and free_irq() will deadlock waiting for the handler to finish. This issue is similar to the one fixed in commit 7dd9c26bd6cf ("can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open") but for the error path. To solve this issue move the call to free_irq() after the lock is released. Setting `priv->force_quit = 1` beforehand ensure that the IRQ handler will exit right away once it acquired the lock.

Official references

Related CVEs

CVECVSSEPSSKEVRExploitTitleMod.

CVE-2026-618548.2 HIG

15.6%

——5VoiceSentinel is a real-time voice moderation system for Minecraft servers. From 2.2.1 until 3.3.1, the optional report buffer feature has a race between retention cleanup and normal transcript writes. In `report_buffer.py`, `_maybe_cleanup()` uses an unlocked dictionary for once-per-hour cleanup throttling, allowing simultaneous `_cleanup_tenant()` operations for one tenant. Cleanup reads `transcripts.jsonl` and rewrites it in place without file locking or atomic replacement, while `report_buffer_append_async` uses `asyncio.to_thread` to append without synchronization. In `main.py`, concurrent `_processing_worker` tasks make this reachable in normal operation; `processing.worker_count` of two or more and public-pool servers sharing a `server_key` increase collisions. With `report_buffer.enabled` set to true, racing writes can lose, duplicate or corrupt transcript data and defeat `report_buffer.retention_seconds` pruning, allowing unbounded disk growth that can exhaust storage and crash the host or other services sharing it. The feature is opt-in and disabled by default. This issue is fixed in version 3.3.1.2d CVE-2026-1185935.9 MED

9.8%

——3A flaw was found in Red Hat Enterprise Linux 9 kernel builds. An incomplete backport of the CVE-2026-46099 fix in RHEL 9.6 through 9.10 left a local_bh imbalance in seg6_input_core(), where the drop path returns with bottom halves still disabled. This can lead to softirq starvation and denial of service on systems with SRv6 tunnels configured. Upstream and RHEL 10 are not affected.10h CVE-2026-1061747.5 HIG

20.8%

——6A improper locking vulnerability in Fortinet FortiOS 8.0.0, FortiOS 7.6.4 through 7.6.6 may allow an unauthenticated attacker with network access to the device to cause a denial of service of the HTTPS management interface via crafted HTTP requests.6d CVE-2026-110803—

20.3%

——6VaadinService.requestEnd() in Vaadin Framework 8 locks the session and then reads the v-uiId request parameter outside the block that releases the lock. A request carrying a non-numeric v-uiId makes Integer.parseInt throw while the session lock is held, so the lock is never released and the container thread returns to its pool still owning it. Every later request to that session then blocks forever in VaadinService.lockSession(), and repeating the request exhausts the thread pool and takes the application down. No authentication is required: a session cookie, which any client obtains with a single request, is enough. Vaadin 10 and later are not affected, because Flow releases the lock in a finally block and does not read that parameter there, and Vaadin Framework 7 is not affected either. Users of affected versions should apply the following mitigation or upgrade. Releases that have fixed this issue include: Product version Vaadin Framework 8.16.0 - 8.32.1 Mitigation Upgrade to 8.32.2 Vaadin Framework 7 and Vaadin 10 and later do not carry this behaviour and need no upgrade for this issue. Artifacts Maven coordinates / Vulnerable versions / Fixed version com.vaadin:vaadin-server / 8.16.0 - 8.32.1 / >=8.32.2 com.vaadin:vaadin-server-mpr-jakarta / 8.18.0 - 8.32.1 / >=8.32.22d CVE-2026-1118796.5 MED

25.8%

——8DBI versions before 1.656 for Perl hang on a later open of a DBD::DBM table because a failed open_data does not release the table's lock. open_data creates the table's lock file and takes an exclusive flock on it for a CREATE, before the checks that can croak: a dbm_mldbm value that is not a module name, a failing tie, or a missing data file. The croak unwinds before the table object is blessed, so nothing releases the lock, and the meta data holding the open descriptor stays cached on the database handle. The dbm_mldbm and dbm_type values come from the DSN or the connect attributes, so a caller that chooses the serializer or the storage backend can trigger the failure. The flock has no timeout, so a later open of that table (even through a separate database handle) blocks for as long as the handle holding the stale lock lives, in the same process or any other.3d CVE-2026-1076745.1 MED

0.0%

——0IBM i 7.3, 7.4, 7.5, and 7.6 is vulnerable to a denial of service to Digital Certificate Manager (DCM) for System TLS using applications attempting to create secure network connections. A bad actor could use this to prevent a service from starting or cause it to fallback to non-secure connections.10d