The Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Validate buffer length while parsing index
indx_read is called when we have some NTFS directory operations that need more information from the index buffers. This adds a sanity check to make sure the returned index buffer length is legit, or we may have some out-of-bound memory accesses.
[ 560.897595] BUG: KASAN: slab-out-of-bounds in hdrfinde.isra.0+0x10c/0x320 [ 560.898321] Read of size 2 at addr ffff888009497238 by task exp/245 [ 560.898760] [ 560.899129] CPU: 0 PID: 245 Comm: exp Not tainted 6.0.0-rc6 #37 [ 560.899505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 560.900170] Call Trace: [ 560.900407] <TASK> [ 560.900732] dumpstacklvl+0x49/0x63 [ 560.901108] printreport.cold+0xf5/0x689 [ 560.901395] ? hdrfinde.isra.0+0x10c/0x320 [ 560.901716] kasanreport+0xa7/0x130 [ 560.901950] ? hdrfinde.isra.0+0x10c/0x320 [ 560.902208] __asanload2+0x68/0x90 [ 560.902427] hdrfind_e.isra.0+0x10c/0x320 [ 560.902846] ? cmpuints+0xe0/0xe0 [ 560.903363] ? cmpsdh+0x90/0x90 [ 560.903883] ? ntfsbreadrun+0x190/0x190 [ 560.904196] ? rwsemdownreadslowpath+0x750/0x750 [ 560.904969] ? ntfsfixpostread+0xe0/0x130 [ 560.905259] ? __kasancheckwrite+0x14/0x20 [ 560.905599] ? up_read+0x1a/0x90 [ 560.905853] ? indxread+0x22c/0x380 [ 560.906096] indxfind+0x2ef/0x470 [ 560.906352] ? indxfindbuffer+0x2d0/0x2d0 [ 560.906692] ? __kasankmalloc+0x88/0xb0 [ 560.906977] dirsearchu+0x196/0x2f0 [ 560.907220] ? ntfsnlstoutf16+0x450/0x450 [ 560.907464] ? __kasancheckwrite+0x14/0x20 [ 560.907747] ? mutex_lock+0x8f/0xe0 [ 560.907970] ? __mutexlockslowpath+0x20/0x20 [ 560.908214] ? kmemcachealloc+0x143/0x4b0 [ 560.908459] ntfs_lookup+0xe0/0x100 [ 560.908788] __lookupslow+0x116/0x220 [ 560.909050] ? lookupfast+0x1b0/0x1b0 [ 560.909309] ? lookupfast+0x13f/0x1b0 [ 560.909601] walkcomponent+0x187/0x230 [ 560.909944] linkpathwalk.part.0+0x3f0/0x660 [ 560.910285] ? handlelookupdown+0x90/0x90 [ 560.910618] ? pathinit+0x642/0x6e0 [ 560.911084] ? percpucounteraddbatch+0x6e/0xf0 [ 560.912559] ? __allocfile+0x114/0x170 [ 560.913008] pathopenat+0x19c/0x1d10 [ 560.913419] ? getname_flags+0x73/0x2b0 [ 560.913815] ? kasansavestack+0x3a/0x50 [ 560.914125] ? kasansavestack+0x26/0x50 [ 560.914542] ? __kasanslaballoc+0x6d/0x90 [ 560.914924] ? kmem_cachealloc+0x143/0x4b0 [ 560.915339] ? getnameflags+0x73/0x2b0 [ 560.915647] ? getname+0x12/0x20 [ 560.916114] ? __x64sysopen+0x4c/0x60 [ 560.916460] ? path_lookupat.isra.0+0x230/0x230 [ 560.916867] ? __isolatefreepage+0x2e0/0x2e0 [ 560.917194] do_filpopen+0x15c/0x1f0 [ 560.917448] ? mayopendev+0x60/0x60 [ 560.917696] ? expandfiles+0xa4/0x3a0 [ 560.917923] ? __kasancheckwrite+0x14/0x20 [ 560.918185] ? rawspinlock+0x88/0xdb [ 560.918409] ? rawspinlockirqsave+0x100/0x100 [ 560.918783] ? findnextbit+0x4a/0x130 [ 560.919026] ? rawspinunlock+0x19/0x40 [ 560.919276] ? allocfd+0x14b/0x2d0 [ 560.919635] dosysopenat2+0x32a/0x4b0 [ 560.920035] ? fileopenroot+0x230/0x230 [ 560.920336] ? __rcureadunlock+0x5b/0x280 [ 560.920813] dosysopen+0x99/0xf0 [ 560.921208] ? filpopen+0x60/0x60 [ 560.921482] ? exittousermode_prepare+0x49/0x180 [ 560.921867] _x64sysopen+0x4c/0x60 [ 560.922128] dosyscall64+0x3b/0x90 [ 560.922369] entrySYSCALL64afterhwframe+0x63/0xcd [ 560.923030] RIP: 0033:0x7f7dff2e4469 [ 560.923681] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088 [ 560.924451] RSP: 002b:00007ffd41a210b8 EFLAGS: 00000206 ORIGRAX: 0000000000000002 [ 560.925168] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7dff2e4469 [ 560.925655] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ---truncated---(CVE-2022-50442)
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Avoid UBSAN error on truesectorsper_clst()
syzbot reported UBSAN error as below:
[ 76.901829][ T6677] ================================================================================ [ 76.903908][ T6677] UBSAN: shift-out-of-bounds in fs/ntfs3/super.c:675:13 [ 76.905363][ T6677] shift exponent -247 is negative
This patch avoid this error.(CVE-2022-50762)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix potential panic dues to unprotected smcllcsrvaddlink()
There is a certain chance to trigger the following panic:
PID: 5900 TASK: ffff88c1c8af4100 CPU: 1 COMMAND: "kworker/1:48" #0 [ffff9456c1cc79a0] machine_kexec at ffffffff870665b7 #1 [ffff9456c1cc79f0] __crashkexec at ffffffff871b4c7a #2 [ffff9456c1cc7ab0] crashkexec at ffffffff871b5b60 #3 [ffff9456c1cc7ac0] oopsend at ffffffff87026ce7 #4 [ffff9456c1cc7ae0] pagefaultoops at ffffffff87075715 #5 [ffff9456c1cc7b58] excpagefault at ffffffff87ad0654 #6 [ffff9456c1cc7b80] asmexcpagefault at ffffffff87c00b62 [exception RIP: iballocmr+19] RIP: ffffffffc0c9cce3 RSP: ffff9456c1cc7c38 RFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000004 RDX: 0000000000000010 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88c1ea281d00 R8: 000000020a34ffff R9: ffff88c1350bbb20 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000010 R14: ffff88c1ab040a50 R15: ffff88c1ea281d00 ORIGRAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff9456c1cc7c60] smcibgetmemoryregion at ffffffffc0aff6df [smc] #8 [ffff9456c1cc7c88] smcrbufmaplink at ffffffffc0b0278c [smc] #9 [ffff9456c1cc7ce0] __smcbufcreate at ffffffffc0b03586 [smc]
The reason here is that when the server tries to create a second link, smcllcsrvaddlink() has no protection and may add a new link to link group. This breaks the security environment protected by llcconfmutex.(CVE-2023-54237)
In the Linux kernel, the following vulnerability has been resolved:
NFSD: free copynotify stateid in nfs4freeol_stateid()
Typically copynotify stateid is freed either when parent's stateid is being close/freed or in nfsd4_laundromat if the stateid hasn't been used in a lease period.
However, in case when the server got an OPEN (which created a parent stateid), followed by a COPYNOTIFY using that stateid, followed by a client reboot. New client instance while doing CREATESESSION would force expire previous state of this client. It leads to the open state being freed thru releaseopenowner-> nfs4freeolstateid() and it finds that it still has copynotify stateid associated with it. We currently print a warning and is triggerred
WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4freeol_stateid+0xb0/0x100 [nfsd]
This patch, instead, frees the associated copynotify stateid here.
If the parent stateid is freed (without freeing the copynotify stateids associated with it), it leads to the list corruption when laundromat ends up freeing the copynotify state later.
[ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 1626.842828] Modules linked in: nfnetlinkqueue nfnetlinklog bluetooth cfg80211 rpcrdma rdmacm iwcm ibcm ibcore nfsd nfsacl lockd grace nfslocalio ext4 crc16 mbcache jbd2 overlay uinput sndseqdummy sndhrtimer qrtr rfkill vfat fat uvcvideo sndhdacodecgeneric videobuf2vmalloc videobuf2memops sndhdaintel uvc sndinteldspcfg videobuf2v4l2 videobuf2common sndhdacodec sndhdacore videodev sndhwdep sndseq mc sndseqdevice sndpcm sndtimer snd soundcore sg loop authrpcgss vsockloopback vmwvsockvirtiotransportcommon vmwvsockvmcitransport vmwvmci vsock xfs 8021q garp stp llc mrp nvme ghashce e1000e nvmecore srmod nvmekeyring nvmeauth cdrom vmwgfx drmttmhelper ttm sunrpc dmmirror dmregionhash dmlog iscsitcp libiscsitcp libiscsi scsitransportiscsi fuse dmmultipath dmmod nfnetlink [ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary) [ 1626.857075] Tainted: [B]=BADPAGE, [W]=WARN [ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd] [ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1626.860010] pc : __listdelentryvalidor_report+0x148/0x200 [ 1626.860601] lr : __listdelentryvalidor_report+0x148/0x200 [ 1626.861182] sp : ffff8000881d7a40 [ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200 [ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20 [ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8 [ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000 [ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065 [ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3 [ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000 [ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001 [ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000 [ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d [ 1626.868167] Call trace: [ 1626.868382] __listdelentryvalidorreport+0x148/0x200 (P) [ 1626.868876] freecpntfstatelocked+0xd0/0x268 [nfsd] [ 1626.869368] nfs4laundromat+0x6f8/0x1058 [nfsd] [ 1626.869813] laundromatmain+0x24/0x60 [nfsd] [ 1626.870231] processonework+0x584/0x1050 [ 1626.870595] workerthread+0x4c4/0xc60 [ 1626.870893] kthread+0x2f8/0x398 [ 1626.871146] retfromfork+0x10/0x20 [ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000) [ 1626.871892] SMP: stopping secondary CPUs(CVE-2025-40273)
In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: fix fragment overflow handling in RX path
The atlantic driver can receive packets with more than MAXSKBFRAGS (17) fragments when handling large multi-descriptor packets. This causes an out-of-bounds write in skbaddrxfragnetmem() leading to kernel panic.
The issue occurs because the driver doesn't check the total number of fragments before calling skbaddrxfrag(). When a packet requires more than MAXSKB_FRAGS fragments, the fragment index exceeds the array bounds.
Fix by assuming there will be an extra frag if buff->len > AQCFGRXHDRSIZE, then all fragments are accounted for. And reusing the existing check to prevent the overflow earlier in the code path.
This crash occurred in production with an Aquantia AQC113 10G NIC.
Stack trace from production environment:
RIP: 0010:skb_add_rx_frag_netmem+0x29/0xd0
Code: 90 f3 0f 1e fa 0f 1f 44 00 00 48 89 f8 41 89
ca 48 89 d7 48 63 ce 8b 90 c0 00 00 00 48 c1 e1 04 48 01 ca 48 03 90
c8 00 00 00 <48> 89 7a 30 44 89 52 3c 44 89 42 38 40 f6 c7 01 75 74 48
89 fa 83
RSP: 0018:ffffa9bec02a8d50 EFLAGS: 00010287
RAX: ffff925b22e80a00 RBX: ffff925ad38d2700 RCX:
fffffffe0a0c8000
RDX: ffff9258ea95bac0 RSI: ffff925ae0a0c800 RDI:
0000000000037a40
RBP: 0000000000000024 R08: 0000000000000000 R09:
0000000000000021
R10: 0000000000000848 R11: 0000000000000000 R12:
ffffa9bec02a8e24
R13: ffff925ad8615570 R14: 0000000000000000 R15:
ffff925b22e80a00
FS: 0000000000000000(0000)
GS:ffff925e47880000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff9258ea95baf0 CR3: 0000000166022004 CR4:
0000000000f72ef0
PKRU: 55555554
Call Trace:
<IRQ>
aq_ring_rx_clean+0x175/0xe60 [atlantic]
? aq_ring_rx_clean+0x14d/0xe60 [atlantic]
? aq_ring_tx_clean+0xdf/0x190 [atlantic]
? kmem_cache_free+0x348/0x450
? aq_vec_poll+0x81/0x1d0 [atlantic]
? __napi_poll+0x28/0x1c0
? net_rx_action+0x337/0x420
Changes in v4: - Add Fixes: tag to satisfy patch validation requirements.
Changes in v3: - Fix by assuming there will be an extra frag if buff->len > AQCFGRXHDRSIZE, then all fragments are accounted for.(CVE-2025-68301)
In the Linux kernel, the following vulnerability has been resolved:
seg6: separate dst_cache for input and output paths in seg6 lwtunnel
The seg6 lwtunnel uses a single dstcache per encap route, shared between seg6inputcore() and seg6output_core(). These two paths can perform the post-encap SID lookup in different routing contexts (e.g., ip rules matching on the ingress interface, or VRF table separation). Whichever path runs first populates the cache, and the other reuses it blindly, bypassing its own lookup.
Fix this by splitting the cache into cacheinput and cacheoutput, so each path maintains its own cached dst independently.(CVE-2026-31668)
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: validate connector number in ucsinotifycommon()
The connector number extracted from CCI via UCSICCICONNECTOR() is a 7-bit field (0-127) that is used to index into the connector array in ucsiconnectorchange(). However, the array is only allocated for the number of connectors reported by the device (typically 2-4 entries).
A malicious or malfunctioning device could report an out-of-range connector number in the CCI, causing an out-of-bounds array access in ucsiconnectorchange().
Add a bounds check in ucsinotifycommon(), the central point where CCI is parsed after arriving from hardware, so that bogus connector numbers are rejected before they propagate further.(CVE-2026-31729)
In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix regsafe() for pointers to packet
In case rold->reg->range == BEYONDPKTEND && rcur->reg->range == N regsafe() may return true which may lead to current state with valid packet range not being explored. Fix the bug.(CVE-2026-43030)
In the Linux kernel, the following vulnerability has been resolved:
net: ipv6: ndisc: fix ndiscrauseropt to initialize nduseropt_padX fields to zero to prevent an info-leak
When processing Router Advertisements with user options the kernel builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct has three padding fields that are never zeroed and can leak kernel data
The fix is simple, just zeroes the padding fields.(CVE-2026-43040)
In the Linux kernel, the following vulnerability has been resolved:
xfs: close crash window in attr dabtree inactivation
When inactivating an inode with node-format extended attributes, xfsattr3nodeinactive() invalidates all child leaf/node blocks via xfstransbinval(), but intentionally does not remove the corresponding entries from their parent node blocks. The implicit assumption is that xfsattr_inactive() will truncate the entire attr fork to zero extents afterwards, so log recovery will never reach the root node and follow those stale pointers.
However, if a log shutdown occurs after the leaf/node block cancellations commit but before the attr bmap truncation commits, this assumption breaks. Recovery replays the attr bmap intact (the inode still has attr fork extents), but suppresses replay of all cancelled leaf/node blocks, maybe leaving them as stale data on disk. On the next mount, xlogrecoverprocess_iunlinks() retries inactivation and attempts to read the root node via the attr bmap. If the root node was not replayed, reading the unreplayed root block triggers a metadata verification failure immediately; if it was replayed, following its child pointers to unreplayed child blocks triggers the same failure:
XFS (pmem0): Metadata corruption detected at xfsda3nodereadverify+0x53/0x220, xfsda3node block 0x78 XFS (pmem0): Unmount and run xfsrepair XFS (pmem0): First 128 bytes of corrupted metadata buffer: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ XFS (pmem0): metadata I/O error in "xfsdareadbuf+0x104/0x190" at daddr 0x78 len 8 error 117
Fix this in two places:
In xfsattr3nodeinactive(), after calling xfstransbinval() on a child block, immediately remove the entry that references it from the parent node in the same transaction. This eliminates the window where the parent holds a pointer to a cancelled block. Once all children are removed, the now-empty root node is converted to a leaf block within the same transaction. This node-to-leaf conversion is necessary for crash safety. If the system shutdown after the empty node is written to the log but before the second-phase bmap truncation commits, log recovery will attempt to verify the root block on disk. xfsda3nodeverify() does not permit a node block with count == 0; such a block will fail verification and trigger a metadata corruption shutdown. on the other hand, leaf blocks are allowed to have this transient state.
In xfsattrinactive(), split the attr fork truncation into two explicit phases. First, truncate all extents beyond the root block (the child extents whose parent references have already been removed above). Second, invalidate the root block and truncate the attr bmap to zero in a single transaction. The two operations in the second phase must be atomic: as long as the attr bmap has any non-zero length, recovery can follow it to the root block, so the root block invalidation must commit together with the bmap-to-zero truncation.(CVE-2026-43053)
In the Linux kernel, the following vulnerability has been resolved:
btrfs: tracepoints: get correct superblock from dentry in event btrfssyncfile()
If overlay is used on top of btrfs, dentry->d_sb translates to overlay's super block and fsid assignment will lead to a crash.
Use fileinode(file)->isb to always get btrfs_sb.(CVE-2026-43117)
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix missing key size check for L2CAPLECONN_REQ
This adds a check for encryption key size upon receiving L2CAPLECONNREQ which is required by L2CAP/LE/CFC/BV-15-C which expects L2CAPCRLEBADKEYSIZE.(CVE-2026-43134)
In the Linux kernel, the following vulnerability has been resolved:
kexec: derive purgatory entry from symbol
kexecloadpurgatory() derives image->start by locating eentry inside an SHFEXECINSTR section. If the purgatory object contains multiple executable sections with overlapping sh_addr, the entrypoint check can match more than once and trigger a WARN.
Derive the entry section from the purgatorystart symbol when present and compute image->start from its final placement. Keep the existing eentry fallback for purgatories that do not expose the symbol.
WARNING: kernel/kexecfile.c:1009 at kexecloadpurgatory+0x395/0x3c0, CPU#10: kexec/1784 Call Trace: <TASK> bzImage64load+0x133/0xa00 __dosyskexecfileload+0x2b3/0x5c0 dosyscall64+0x81/0x610 entrySYSCALL64afterhwframe+0x76/0x7e
[(CVE-2026-43289)
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
In the Linux kernel, the following vulnerability has been resolved:
crypto: pcrypt - Fix handling of MAY_BACKLOG requests
MAY_BACKLOG requests can return EBUSY. Handle them by checking for that value and filtering out EINPROGRESS notifications.(CVE-2026-43493)
{
"severity": "Critical"
}{
"aarch64": [
"bpftool-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm",
"bpftool-debuginfo-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm",
"kernel-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm",
"kernel-debuginfo-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm",
"kernel-debugsource-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm",
"kernel-devel-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm",
"kernel-headers-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm",
"kernel-source-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm",
"kernel-tools-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm",
"kernel-tools-debuginfo-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm",
"kernel-tools-devel-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm",
"perf-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm",
"perf-debuginfo-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm",
"python3-perf-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm",
"python3-perf-debuginfo-5.10.0-316.0.0.219.oe2203sp4.aarch64.rpm"
],
"src": [
"kernel-5.10.0-316.0.0.219.oe2203sp4.src.rpm"
],
"x86_64": [
"bpftool-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm",
"bpftool-debuginfo-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm",
"kernel-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm",
"kernel-debuginfo-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm",
"kernel-debugsource-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm",
"kernel-devel-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm",
"kernel-headers-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm",
"kernel-source-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm",
"kernel-tools-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm",
"kernel-tools-debuginfo-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm",
"kernel-tools-devel-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm",
"perf-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm",
"perf-debuginfo-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm",
"python3-perf-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm",
"python3-perf-debuginfo-5.10.0-316.0.0.219.oe2203sp4.x86_64.rpm"
]
}