OESA-2025-1161

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ceph: prevent use-after-free in encodecapmsg()

In fs/ceph/caps.c, in encodecapmsg(), "use after free" error was caught by KASAN at this line - 'cephbufferget(arg->xattr_buf);'. This implies before the refcount could be increment here, it was freed.

In same file, in "handlecapgrant()" refcount is decremented by this line - 'cephbufferput(ci->i_xattrs.blob);'. It appears that a race occurred and resource was freed by the latter line before the former line could increment it.

encodecapmsg() is called by _sendcap() and _sendcap() is called by cephcheckcaps() after calling _prepcap(). _prepcap() is where arg->xattrbuf is assigned to ci->ixattrs.blob. This is the spot where the refcount must be increased to prevent "use after free" error.(CVE-2024-26689)

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

xsk: fix OOB map writes when deleting elements

Jordy says:

" In the xskmapdeleteelem function an unsigned integer (map->maxentries) is compared with a user-controlled signed integer (k). Due to implicit type conversion, a large unsigned value for map->max_entries can bypass the intended bounds check:

if (k >= map->max_entries)
    return -EINVAL;

This allows k to hold a negative value (between -2147483648 and -2), which is then used as an array index in m->xsk_map[k], which results in an out-of-bounds access.

spin_lock_bh(&m->lock);
map_entry = &m->xsk_map[k]; // Out-of-bounds map_entry
old_xs = unrcu_pointer(xchg(map_entry, NULL));  // Oob write
if (old_xs)
    xsk_map_sock_delete(old_xs, map_entry);
spin_unlock_bh(&m->lock);

The xchg operation can then be used to cause an out-of-bounds write. Moreover, the invalid mapentry passed to xskmapsockdelete can lead to further memory corruption. "

It indeed results in following splat:

[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108 [76612.904330] #PF: supervisor write access in kernel mode [76612.909639] #PF: errorcode(0x0002) - not-present page [76612.914855] PGD 0 P4D 0 [76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP [76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470 [76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [76612.939781] RIP: 0010:xskmapdeleteelem+0x2d/0x60 [76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31 [76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246 [76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000 [76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000 [76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007 [76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8 [76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0 [76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000 [76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0 [76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [76613.041086] PKRU: 55555554 [76613.043842] Call Trace: [76613.046331] <TASK> [76613.048468] ? _die+0x20/0x60 [76613.051581] ? pagefaultoops+0x15a/0x450 [76613.055747] ? searchextable+0x22/0x30 [76613.059649] ? searchbpfextables+0x5f/0x80 [76613.063988] ? excpagefault+0xa9/0x140 [76613.067975] ? asmexcpagefault+0x22/0x30 [76613.072229] ? xskmapdeleteelem+0x2d/0x60 [76613.076573] ? xskmapdeleteelem+0x23/0x60 [76613.080914] _sysbpf+0x19b7/0x23c0 [76613.084555] _x64sysbpf+0x1a/0x20 [76613.088194] dosyscall64+0x37/0xb0 [76613.091832] entrySYSCALL64afterhwframe+0x4b/0x53 [76613.096962] RIP: 0033:0x7f80b6d1e88d [76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48 [76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141 [76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d [76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003 [76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000 [76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8 [76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00 ---truncated---(CVE-2024-56614)

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

netfilter: xtables: fix LED ID check in ledtg_check()

Syzbot has reported the following BUG detected by KASAN:

BUG: KASAN: slab-out-of-bounds in strlen+0x58/0x70 Read of size 1 at addr ffff8881022da0c8 by task repro/5879 ... Call Trace: <TASK> dumpstacklvl+0x241/0x360 ? pfxdumpstacklvl+0x10/0x10 ? _pfxprintk+0x10/0x10 ? printk+0xd5/0x120 ? virtaddrvalid+0x183/0x530 ? _virtaddrvalid+0x183/0x530 printreport+0x169/0x550 ? _virtaddrvalid+0x183/0x530 ? _virtaddrvalid+0x183/0x530 ? _virtaddrvalid+0x45f/0x530 ? _physaddr+0xba/0x170 ? strlen+0x58/0x70 kasanreport+0x143/0x180 ? strlen+0x58/0x70 strlen+0x58/0x70 kstrdup+0x20/0x80 ledtgcheck+0x18b/0x3c0 xtchecktarget+0x3bb/0xa40 ? _pfxxtchecktarget+0x10/0x10 ? stackdepotsaveflags+0x6e4/0x830 ? nfttargetinit+0x174/0xc30 nfttargetinit+0x82d/0xc30 ? _pfxnfttargetinit+0x10/0x10 ? nftablesnewrule+0x1609/0x2980 ? nftablesnewrule+0x1609/0x2980 ? rcuiswatching+0x15/0xb0 ? nftablesnewrule+0x1609/0x2980 ? nftablesnewrule+0x1609/0x2980 ? _kmallocnoprof+0x21a/0x400 nftablesnewrule+0x1860/0x2980 ? _pfxnftablesnewrule+0x10/0x10 ? _nlaparse+0x40/0x60 nfnetlinkrcv+0x14e5/0x2ab0 ? _pfxvalidatechain+0x10/0x10 ? _pfxnfnetlinkrcv+0x10/0x10 ? _lockacquire+0x1384/0x2050 ? netlinkdelivertap+0x2e/0x1b0 ? _pfxlockrelease+0x10/0x10 ? netlinkdelivertap+0x2e/0x1b0 netlinkunicast+0x7f8/0x990 ? _pfxnetlinkunicast+0x10/0x10 ? _virtaddrvalid+0x183/0x530 ? _checkobjectsize+0x48e/0x900 netlinksendmsg+0x8e4/0xcb0 ? _pfxnetlinksendmsg+0x10/0x10 ? aasockmsgperm+0x91/0x160 ? _pfxnetlinksendmsg+0x10/0x10 _socksendmsg+0x223/0x270 syssendmsg+0x52a/0x7e0 ? pfxsyssendmsg+0x10/0x10 _syssendmsg+0x292/0x380 ? _pfxsyssendmsg+0x10/0x10 ? lockdephardirqsonprepare+0x43d/0x780 ? _pfxlockdephardirqsonprepare+0x10/0x10 ? excpagefault+0x590/0x8c0 ? dosyscall64+0xb6/0x230 dosyscall64+0xf3/0x230 entrySYSCALL64afterhwframe+0x77/0x7f ... </TASK>

Since an invalid (without '\0' byte at all) byte sequence may be passed from userspace, add an extra check to ensure that such a sequence is rejected as possible ID and so never passed to 'kstrdup()' and further.(CVE-2024-56650)

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

selinux: ignore unknown extended permissions

When evaluating extended permissions, ignore unknown permissions instead of calling BUG(). This commit ensures that future permissions can be added without interfering with older kernels.(CVE-2024-57931)

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

netfilter: conntrack: clamp maximum hashtable size to INT_MAX

Use INTMAX as maximum size for the conntrack hashtable. Otherwise, it is possible to hit WARNONONCE in _kvmallocnodenoprof() when resizing hashtable because _GFPNOWARN is unset. See:

0708a0afe291 ("mm: Consider _GFPNOWARN flag for oversized kvmalloc() calls")

Note: hashtable resize is only possible from init_netns.(CVE-2025-21648)