In the Linux kernel, the following vulnerability has been resolved:
libceph: Fix potential out-of-bounds access in cephhandleauth_reply()
This patch fixes an out-of-bounds access in cephhandleauthreply() that can be triggered by a message of type CEPHMSGAUTHREPLY. In cephhandleauthreply(), the value of the payloadlen field of such a message is stored in a variable of type int. A value greater than INTMAX leads to an integer overflow and is interpreted as a negative value. This leads to decrementing the pointer address by this value and subsequently accessing it because cephdecode_need() only checks that the memory access does not exceed the end address of the allocation.
This patch fixes the issue by changing the data type of payloadlen to u32. Additionally, the data type of resultmsg_len is changed to u32, as it is also a variable holding a non-negative length.
Also, an additional layer of sanity checks is introduced, ensuring that directly after reading it from the message, payloadlen and resultmsg_len are not greater than the overall segment length.
BUG: KASAN: slab-out-of-bounds in cephhandleauth_reply+0x642/0x7a0 [libceph] Read of size 4 at addr ffff88811404df14 by task kworker/20:1/262
CPU: 20 UID: 0 PID: 262 Comm: kworker/20:1 Not tainted 6.19.2 #5 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: ceph-msgr cephconworkfn [libceph] Call Trace: <TASK> dumpstacklvl+0x76/0xa0 printreport+0xd1/0x620 ? pfxrawspinlockirqsave+0x10/0x10 ? kasancompletemodereportinfo+0x72/0x210 kasanreport+0xe7/0x130 ? cephhandleauthreply+0x642/0x7a0 [libceph] ? cephhandleauth_reply+0x642/0x7a0 [libceph] __asanreportloadnnoabort+0xf/0x20 cephhandleauthreply+0x642/0x7a0 [libceph] mondispatch+0x973/0x23d0 [libceph] ? apparmorsocketrecvmsg+0x6b/0xa0 ? __pfxmondispatch+0x10/0x10 [libceph] ? __kasancheckwrite+0x14/0x30i ? mutex_unlock+0x7f/0xd0 ? __pfxmutexunlock+0x10/0x10 ? __pfxdorecvmsg+0x10/0x10 [libceph] cephconprocessmessage+0x1f1/0x650 [libceph] processmessage+0x1e/0x450 [libceph] cephconv2tryread+0x2e48/0x6c80 [libceph] ? __pfxcephconv2tryread+0x10/0x10 [libceph] ? savefpregstofpstate+0xb0/0x230 ? rawspinrqunlock+0x17/0xa0 ? finishtask_switch.isra.0+0x13b/0x760 ? __switch_to+0x385/0xda0 ? __kasancheckwrite+0x14/0x30 ? mutex_lock+0x8d/0xe0 ? __pfxmutexlock+0x10/0x10 cephconworkfn+0x248/0x10c0 [libceph] processonework+0x629/0xf80 ? __kasancheckwrite+0x14/0x30 workerthread+0x87f/0x1570 ? pfxrawspinlockirqsave+0x10/0x10 ? __pfxtrytowakeup+0x10/0x10 ? kasanprintaddressstackframe+0x1f7/0x280 ? __pfxworkerthread+0x10/0x10 kthread+0x396/0x830 ? pfxraw_spinlockirq+0x10/0x10 ? __pfx_kthread+0x10/0x10 ? __kasancheckwrite+0x14/0x30 ? recalc_sigpending+0x180/0x210 ? __pfxkthread+0x10/0x10 retfrom_fork+0x3f7/0x610 ? __pfxretfrom_fork+0x10/0x10 ? __switch_to+0x385/0xda0 ? __pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>
[ idryomov: replace if statements with cephdecodeneed() for payloadlen and resultmsg_len ]
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/43xxx/CVE-2026-43407.json",
"cna_assigner": "Linux"
}