CVE-2026-45993

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

drbd: add missing kref_get in handle_write_conflicts

With two-primaries enabled, DRBD tries to detect "concurrent" writes and handle write conflicts, so that even if you write to the same sector simultaneously on both nodes, they end up with the identical data once the writes are completed.

In handling "superseeded" writes, we forgot a kref_get, resulting in a premature drbd_destroy_device and use after free, and further to kernel crashes with symptoms.

Relevance: No one should use DRBD as a random data generator, and apparently all users of "two-primaries" handle concurrent writes correctly on layer up. That is cluster file systems use some distributed lock manager, and live migration in virtualization environments stops writes on one node before starting writes on the other node.

Which means that other than for "test cases", this code path is never taken in real life.

FYI, in DRBD 9, things are handled differently nowadays. We still detect "write conflicts", but no longer try to be smart about them. We decided to disconnect hard instead: upper layers must not submit concurrent writes. If they do, that's their fault.(CVE-2025-38708)

In the Linux kernel, the following vulnerability has been resolved:

wifi: mwifiex: Initialize the chan_stats array to zero

The adapter->chan_stats[] array is initialized in mwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero out memory. The array is filled in mwifiex_update_chan_statistics() and then the user can query the data in mwifiex_cfg80211_dump_survey().

There are two potential issues here. What if the user calls mwifiex_cfg80211_dump_survey() before the data has been filled in. Also the mwifiex_update_chan_statistics() function doesn't necessarily initialize the whole array. Since the array was not initialized at the start that could result in an information leak.

Also this array is pretty small. It's a maximum of 900 bytes so it's more appropriate to use kcalloc() instead vmalloc().(CVE-2025-39891)

In the Linux kernel, the following vulnerability has been resolved:

ALSA: ctxfi: Fix potential OOB access in audio mixer handling

In the audio mixer handling code of ctxfi driver, the conf field is used as a kind of loop index, and it's referred in the index callbacks (amixer_index() and sum_index()).

As spotted recently by fuzzers, the current code causes OOB access at those functions. | UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48 | index 8 is out of range for type 'unsigned char [8]'

After the analysis, the cause was found to be the lack of the proper (re-)initialization of conj field.

This patch addresses those OOB accesses by adding the proper initializations of the loop indices.(CVE-2026-23076)

In the Linux kernel, the following vulnerability has been resolved:

rxrpc: Fix call removal to use RCU safe deletion

Fix rxrpc call removal from the rxnet->calls list to use list_del_rcu() rather than list_del_init() to prevent stuffing up reading /proc/net/rxrpc/calls from potentially getting into an infinite loop.

This, however, means that list_empty() no longer works on an entry that's been deleted from the list, making it harder to detect prior deletion. Fix this by:

Firstly, make rxrpc_destroy_all_calls() only dump the first ten calls that are unexpectedly still on the list. Limiting the number of steps means there's no need to call cond_resched() or to remove calls from the list here, thereby eliminating the need for rxrpc_put_call() to check for that.

rxrpc_put_call() can then be fixed to unconditionally delete the call from the list as it is the only place that the deletion occurs.(CVE-2026-31642)

In the Linux kernel, the following…

In the Linux kernel, the following vulnerability has been resolved: LoongArch: Add spectre boundry for syscall dispatch table The LoongArch syscall number is directly controlled by userspace, but does not have a array_index_nospec() boundry to prevent access past the syscall function pointer tables.

In the Linux kernel, the following vulnerability has been resolved:

LoongArch: Add spectre boundry for syscall dispatch table

The LoongArch syscall number is directly controlled by userspace, but does not have a array_index_nospec() boundry to prevent access past the syscall function pointer tables.

In the Linux kernel, the following vulnerability has been resolved:

LoongArch: Add spectre boundry for syscall dispatch table

The LoongArch syscall number is directly controlled by userspace, but does not have a array_index_nospec() boundry to prevent access past the syscall function pointer tables.

These are all security issues fixed in the kernel-devel-7.0.11-1.1 package on the GA media of openSUSE Tumbleweed.

Root has patched CVE-2026-45993 in the linux package for Root:Debian:11. Multiple fixed versions available.

Root has patched CVE-2026-45993 in the linux package for Root:Debian:12. Multiple fixed versions available.

Root has patched CVE-2026-45993 in the linux package for Root:Ubuntu:22.04. Multiple fixed versions available.

Root has patched CVE-2026-45993 in the linux package for Root:Ubuntu:24.04. Multiple fixed versions available.