In the Linux kernel, the following vulnerability has been resolved:
ceph: add a bunch of missing cephpathinfo initializers
cephmdscbuildpath() must be called with a zero-initialized cephpathinfo parameter, or else the following cephmdscfreepath_info() may crash.
Example crash (on Linux 6.18.12):
virttocache: Object is not a Slab page! WARNING: CPU: 184 PID: 2871736 at mm/slub.c:6732 kmemcachefree+0x316/0x400 [...] Call Trace: [...] cephopen+0x13d/0x3e0 dodentryopen+0x134/0x480 vfsopen+0x2a/0xe0 pathopenat+0x9a3/0x1160 [...] cachefromobj: Wrong slab cache. namescache but object is from cephinodeinfo WARNING: CPU: 184 PID: 2871736 at mm/slub.c:6746 kmemcachefree+0x2dd/0x400 [...] kernel BUG at mm/slub.c:634! Oops: invalid opcode: 0000 [#1] SMP NOPTI RIP: 0010:_slabfree+0x1a4/0x350
Some of the cephmdscbuildpath() callers had initializers, but others had not, even though they were all added by commit 15f519e9f883 ("ceph: fix race condition validating rparent before applying state"). The ones without initializer are suspectible to random crashes. (I can imagine it could even be possible to exploit this bug to elevate privileges.)
Unfortunately, these Ceph functions are undocumented and its semantics can only be derived from the code. I see that cephmdscbuild_path() initializes the structure only on success, but not on error.
Calling cephmdscfreepathinfo() after a failed cephmdscbuild_path() call does not even make sense, but that's what all callers do, and for it to be safe, the structure must be zero-initialized. The least intrusive approach to fix this is therefore to add initializers everywhere.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/43xxx/CVE-2026-43408.json",
"cna_assigner": "Linux"
}