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

iouring/poll: fix signed comparison in iopollgetownership()

iopollgetownership() uses a signed comparison to check whether pollrefs has reached the threshold for the slowpath:

if (unlikely(atomicread(&req->pollrefs) >= IOPOLLREFBIAS))

atomicread() returns int (signed). When IOPOLLCANCELFLAG (BIT(31)) is set in pollrefs, the value becomes negative in signed arithmetic, so the >= 128 comparison always evaluates to false and the slowpath is never taken.

Fix this by casting the atomicread() result to unsigned int before the comparison, so that the cancel flag is treated as a large positive value and correctly triggers the slowpath.

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

x86/amdnb: Use rdmsrsafe() in amdgetmmconfigrange()

Xen doesn't offer MSRFAM10HMMIOCONFBASE to all guests. This results in the following warning:

unchecked MSR access error: RDMSR from 0xc0010058 at rIP: 0xffffffff8101d19f (xendoreadmsr+0x7f/0xa0) Call Trace: xenreadmsr+0x1e/0x30 amdgetmmconfigrange+0x2b/0x80 quirkamdmmconfigarea+0x28/0x100 pnpfixupdevice+0x39/0x50 pnpadddevice+0xf/0x150 pnpadddevice+0x3d/0x100 pnpacpiadddevicehandler+0x1f9/0x280 acpinsgetdevicecallback+0x104/0x1c0 acpinswalknamespace+0x1d0/0x260 acpigetdevices+0x8a/0xb0 pnpacpiinit+0x50/0x80 dooneinitcall+0x46/0x2e0 kernelinitfreeable+0x1da/0x2f0 kernelinit+0x16/0x1b0 retfromfork+0x30/0x50 retfromforkasm+0x1b/0x30

based on quirks for a "PNP0c01" device. Treating MMCFG as disabled is the right course of action, so no change is needed there.

This was most likely exposed by fixing the Xen MSR accessors to not be silently-safe.

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

net: fec: handle pagepooldevallocpages error

The fecenetupdatecbd function calls pagepooldevallocpages but did not handle the case when it returned NULL. There was a WARNON(!newpage) but it would still proceed to use the NULL pointer and then crash.

This case does seem somewhat rare but when the system is under memory pressure it can happen. One case where I can duplicate this with some frequency is when writing over a smbd share to a SATA HDD attached to an imx6q.

Setting /proc/sys/vm/minfreekbytes to higher values also seems to solve the problem for my test case. But it still seems wrong that the fec driver ignores the memory allocation error and can crash.

This commit handles the allocation error by dropping the current packet.

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

iouring/eventfd: ensure ioeventfdsignal() defers another RCU period

ioeventfddosignal() is invoked from an RCU callback, but when dropping the reference to the ioevfd, it calls ioeventfdfree() directly if the refcount drops to zero. This isn't correct, as any potential freeing of the ioevfd should be deferred another RCU grace period.

Just call ioeventfdput() rather than open-code the dec-and-test and free, which will correctly defer it another RCU grace period.

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

wifi: mac80211: prohibit deactivating all links

In the internal API this calls this is a WARNON, but that should remain since internally we want to know about bugs that may cause this. Prevent deactivating all links in the debugfs write directly.

A vulnerability classified as critical has been found in Linux Kernel. Affected is the function btfdumpnamedups of the file tools/lib/bpf/btfdump.c of the component libbpf. The manipulation leads to use after free. It is recommended to apply a patch to fix this issue. The identifier of this vulnerability is VDB-211032.

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

NFSD: Fix SECINFONONAME decode error cleanup

nfsd4decodesecinfononame() currently initializes sinexp after decoding sinstyle. If the XDR stream is truncated, the decoder returns nfserrbadxdr before sinexp is initialized.

Since commit 3fdc54646234 ("NFSD: Reduce amount of struct nfsd4compoundargs that needs clearing"), the inline iops array is not cleared between RPC calls. A failed SECINFONONAME decode can therefore leave sinexp holding stale union contents from a previous operation.

The error response path still invokes nfsd4secinfononamerelease(), which calls expput() on a non-NULL sinexp.

Initialize sinexp before the first failable decode step, matching nfsd4decodesecinfo().

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

fs/ntfs3: Fix memory leak on ntfsfillsuper() error path

syzbot reported kmemleak as below:

BUG: memory leak unreferenced object 0xffff8880122f1540 (size 32): comm "a.out", pid 6664, jiffies 4294939771 (age 25.500s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 ed ff ed ff 00 00 00 00 ................ backtrace: [<ffffffff81b16052>] ntfsinitfscontext+0x22/0x1c0 [<ffffffff8164aaa7>] allocfscontext+0x217/0x430 [<ffffffff81626dd4>] pathmount+0x704/0x1080 [<ffffffff81627e7c>] x64sysmount+0x18c/0x1d0 [<ffffffff84593e14>] dosyscall64+0x34/0xb0 [<ffffffff84600087>] entrySYSCALL64afterhwframe+0x63/0xcd

This patch fixes this issue by freeing mount options on error path of ntfsfillsuper().

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

fs/ntfs3: Validate data run offset

This adds sanity checks for data run offset. We should make sure data run offset is legit before trying to unpack them, otherwise we may encounter use-after-free or some unexpected memory access behaviors.

[ 82.940342] BUG: KASAN: use-after-free in rununpack+0x2e3/0x570 [ 82.941180] Read of size 1 at addr ffff888008a8487f by task mount/240 [ 82.941670] [ 82.942069] CPU: 0 PID: 240 Comm: mount Not tainted 5.19.0+ #15 [ 82.942482] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 82.943720] Call Trace: [ 82.944204] <TASK> [ 82.944471] dumpstacklvl+0x49/0x63 [ 82.944908] printreport.cold+0xf5/0x67b [ 82.945141] ? waitonbit+0x106/0x120 [ 82.945750] ? rununpack+0x2e3/0x570 [ 82.946626] kasanreport+0xa7/0x120 [ 82.947046] ? rununpack+0x2e3/0x570 [ 82.947280] asanload1+0x51/0x60 [ 82.947483] rununpack+0x2e3/0x570 [ 82.947709] ? memcpy+0x4e/0x70 [ 82.947927] ? runpack+0x7a0/0x7a0 [ 82.948158] rununpackex+0xad/0x3f0 [ 82.948399] ? mienumattr+0x14a/0x200 [ 82.948717] ? rununpack+0x570/0x570 [ 82.949072] ? nienumattrex+0x1b2/0x1c0 [ 82.949332] ? nifnametype.part.0+0xd0/0xd0 [ 82.949611] ? miread+0x262/0x2c0 [ 82.949970] ? ntfscmpnamescpu+0x125/0x180 [ 82.950249] ntfsiget5+0x632/0x1870 [ 82.950621] ? ntfsgetblockbmap+0x70/0x70 [ 82.951192] ? evict+0x223/0x280 [ 82.951525] ? iput.part.0+0x286/0x320 [ 82.951969] ntfsfillsuper+0x1321/0x1e20 [ 82.952436] ? putntfs+0x1d0/0x1d0 [ 82.952822] ? vsprintf+0x20/0x20 [ 82.953188] ? mutexunlock+0x81/0xd0 [ 82.953379] ? setblocksize+0x95/0x150 [ 82.954001] gettreebdev+0x232/0x370 [ 82.954438] ? putntfs+0x1d0/0x1d0 [ 82.954700] ntfsfsgettree+0x15/0x20 [ 82.955049] vfsgettree+0x4c/0x130 [ 82.955292] pathmount+0x645/0xfd0 [ 82.955615] ? putname+0x80/0xa0 [ 82.955955] ? finishautomount+0x2e0/0x2e0 [ 82.956310] ? kmemcachefree+0x110/0x390 [ 82.956723] ? putname+0x80/0xa0 [ 82.957023] domount+0xd6/0xf0 [ 82.957411] ? pathmount+0xfd0/0xfd0 [ 82.957638] ? kasancheckwrite+0x14/0x20 [ 82.957948] x64sysmount+0xca/0x110 [ 82.958310] dosyscall64+0x3b/0x90 [ 82.958719] entrySYSCALL64afterhwframe+0x63/0xcd [ 82.959341] RIP: 0033:0x7fd0d1ce948a [ 82.960193] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 82.961532] RSP: 002b:00007ffe59ff69a8 EFLAGS: 00000202 ORIGRAX: 00000000000000a5 [ 82.962527] RAX: ffffffffffffffda RBX: 0000564dcc107060 RCX: 00007fd0d1ce948a [ 82.963266] RDX: 0000564dcc107260 RSI: 0000564dcc1072e0 RDI: 0000564dcc10fce0 [ 82.963686] RBP: 0000000000000000 R08: 0000564dcc107280 R09: 0000000000000020 [ 82.964272] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564dcc10fce0 [ 82.964785] R13: 0000564dcc107260 R14: 0000000000000000 R15: 00000000ffffffff

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

drm/amdgpu: Fix size validation for non-exclusive domains (v4)

Fix amdgpubovalidatesize() to check whether the TTM domain manager for the requested memory exists, else we get a kernel oops when dereferencing "man".

v2: Make the patch standalone, i.e. not dependent on local patches. v3: Preserve old behaviour and just check that the manager pointer is not NULL. v4: Complain if GTT domain requested and it is uninitialized--most likely a bug.

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

fs/ntfs3: Validate buffer length while parsing index

indxread 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] hdrfinde.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] ? upread+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] ? mutexlock+0x8f/0xe0 [ 560.907970] ? mutexlockslowpath+0x20/0x20 [ 560.908214] ? kmemcachealloc+0x143/0x4b0 [ 560.908459] ntfslookup+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] ? getnameflags+0x73/0x2b0 [ 560.913815] ? kasansavestack+0x3a/0x50 [ 560.914125] ? kasansavestack+0x26/0x50 [ 560.914542] ? kasanslaballoc+0x6d/0x90 [ 560.914924] ? kmemcachealloc+0x143/0x4b0 [ 560.915339] ? getnameflags+0x73/0x2b0 [ 560.915647] ? getname+0x12/0x20 [ 560.916114] ? x64sysopen+0x4c/0x60 [ 560.916460] ? pathlookupat.isra.0+0x230/0x230 [ 560.916867] ? isolatefreepage+0x2e0/0x2e0 [ 560.917194] dofilpopen+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] ? exittousermodeprepare+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---

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

crypto: hisilicon/hpre - fix resource leak in remove process

In hpreremove(), when the disable operation of qm sriov failed, the following logic should continue to be executed to release the remaining resources that have been allocated, instead of returning directly, otherwise there will be resource leakage.

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

crypto: hisilicon/qm - increase the memory of local variables

Increase the buffer to prevent stack overflow by fuzz test. The maximum length of the qos configuration buffer is 256 bytes. Currently, the value of the 'val buffer' is only 32 bytes. The sscanf does not check the dest memory length. So the 'val buffer' may stack overflow.

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

fs/ntfs3: Add null pointer check to attrloadrunsvcn

Some metadata files are handled before MFT. This adds a null pointer check for some corner cases that could lead to NPD while reading these metadata files for a malformed NTFS image.

[ 240.190827] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 240.191583] #PF: supervisor read access in kernel mode [ 240.191956] #PF: errorcode(0x0000) - not-present page [ 240.192391] PGD 0 P4D 0 [ 240.192897] Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 240.193805] CPU: 0 PID: 242 Comm: mount Tainted: G B 5.19.0+ #17 [ 240.194477] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 240.195152] RIP: 0010:nifindattr+0xae/0x300 [ 240.195679] Code: c8 48 c7 45 88 c0 4e 5e 86 c7 00 f1 f1 f1 f1 c7 40 04 00 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 e8 e2 d9f [ 240.196642] RSP: 0018:ffff88800812f690 EFLAGS: 00000286 [ 240.197019] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff85ef037a [ 240.197523] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffff88e95f60 [ 240.197877] RBP: ffff88800812f738 R08: 0000000000000001 R09: fffffbfff11d2bed [ 240.198292] R10: ffffffff88e95f67 R11: fffffbfff11d2bec R12: 0000000000000000 [ 240.198647] R13: 0000000000000080 R14: 0000000000000000 R15: 0000000000000000 [ 240.199410] FS: 00007f233c33be40(0000) GS:ffff888058200000(0000) knlGS:0000000000000000 [ 240.199895] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 240.200314] CR2: 0000000000000158 CR3: 0000000004d32000 CR4: 00000000000006f0 [ 240.200839] Call Trace: [ 240.201104] <TASK> [ 240.201502] ? niloadmi+0x80/0x80 [ 240.202297] ? slaballoc+0x465/0x830 [ 240.202614] attrloadrunsvcn+0x8c/0x1a0 [ 240.202886] ? kasanslaballoc+0x32/0x90 [ 240.203157] ? attrdatawriteresident+0x250/0x250 [ 240.203543] miread+0x133/0x2c0 [ 240.203785] miget+0x70/0x140 [ 240.204012] niloadmiex+0xfa/0x190 [ 240.204346] ? nistd5+0x90/0x90 [ 240.204588] ? kasankmalloc+0x88/0xb0 [ 240.204859] nienumattrex+0xf1/0x1c0 [ 240.205107] ? nifnametype.part.0+0xd0/0xd0 [ 240.205600] ? ntfsloadattrlist+0xbe/0x300 [ 240.205864] ? ntfscmpnamescpu+0x125/0x180 [ 240.206157] ntfsiget5+0x56c/0x1870 [ 240.206510] ? ntfsgetblockbmap+0x70/0x70 [ 240.206776] ? kasankmalloc+0x88/0xb0 [ 240.207030] ? setblocksize+0x95/0x150 [ 240.207545] ntfsfillsuper+0xb8f/0x1e20 [ 240.207839] ? putntfs+0x1d0/0x1d0 [ 240.208069] ? vsprintf+0x20/0x20 [ 240.208467] ? mutexunlock+0x81/0xd0 [ 240.208846] ? setblocksize+0x95/0x150 [ 240.209221] gettreebdev+0x232/0x370 [ 240.209804] ? putntfs+0x1d0/0x1d0 [ 240.210519] ntfsfsgettree+0x15/0x20 [ 240.210991] vfsgettree+0x4c/0x130 [ 240.211455] pathmount+0x645/0xfd0 [ 240.211806] ? putname+0x80/0xa0 [ 240.212112] ? finishautomount+0x2e0/0x2e0 [ 240.212559] ? kmemcachefree+0x110/0x390 [ 240.212906] ? putname+0x80/0xa0 [ 240.213329] domount+0xd6/0xf0 [ 240.213829] ? pathmount+0xfd0/0xfd0 [ 240.214246] ? kasancheckwrite+0x14/0x20 [ 240.214774] x64sysmount+0xca/0x110 [ 240.215080] dosyscall64+0x3b/0x90 [ 240.215442] entrySYSCALL64afterhwframe+0x63/0xcd [ 240.215811] RIP: 0033:0x7f233b4e948a [ 240.216104] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 240.217615] RSP: 002b:00007fff02211ec8 EFLAGS: 00000202 ORIGRAX: 00000000000000a5 [ 240.218718] RAX: ffffffffffffffda RBX: 0000561cdc35b060 RCX: 00007f233b4e948a [ 240.219556] RDX: 0000561cdc35b260 RSI: 0000561cdc35b2e0 RDI: 0000561cdc363af0 [ 240.219975] RBP: 0000000000000000 R08: 0000561cdc35b280 R09: 0000000000000020 [ 240.220403] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000561cdc363af0 [ 240.220803] R13: 000 ---truncated---

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

orangefs: Fix kmemleak in orangefs{kernel,client}debuginit()

When insert and remove the orangefs module, there are memory leaked as below:

unreferenced object 0xffff88816b0cc000 (size 2048): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): 6e 6f 6e 65 0a 00 00 00 00 00 00 00 00 00 00 00 none............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloctrace+0x27/0xa0 [<000000005b405fee>] orangefsdebugfsinit.cold+0xaf/0x17f [<00000000e5a0085b>] 0xffffffffa02780f9 [<000000004232d9f7>] dooneinitcall+0x87/0x2a0 [<0000000054f22384>] doinitmodule+0xdf/0x320 [<000000003263bdea>] loadmodule+0x2f98/0x3330 [<0000000052cd4153>] dosysfinitmodule+0x113/0x1b0 [<00000000250ae02b>] dosyscall64+0x35/0x80 [<00000000f11c03c7>] entrySYSCALL64afterhwframe+0x46/0xb0

Use the golbal variable as the buffer rather than dynamic allocate to slove the problem.

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

fs/ntfs3: Validate BOOT recordsize

When the NTFS BOOT recordsize field < 0, it represents a shift value. However, there is no sanity check on the shift result and the sbi->recordbits calculation through blksizebits() assumes the size always > 256, which could lead to NPD while mounting a malformed NTFS image.

[ 318.675159] BUG: kernel NULL pointer dereference, address: 0000000000000158 [ 318.675682] #PF: supervisor read access in kernel mode [ 318.675869] #PF: errorcode(0x0000) - not-present page [ 318.676246] PGD 0 P4D 0 [ 318.676502] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 318.676934] CPU: 0 PID: 259 Comm: mount Not tainted 5.19.0 #5 [ 318.677289] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [ 318.678136] RIP: 0010:nifindattr+0x2d/0x1c0 [ 318.678656] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180 [ 318.679848] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246 [ 318.680104] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080 [ 318.680790] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 318.681679] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 318.682577] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080 [ 318.683015] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000 [ 318.683618] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000 [ 318.684280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 318.684651] CR2: 0000000000000158 CR3: 0000000002e1a000 CR4: 00000000000006f0 [ 318.685623] Call Trace: [ 318.686607] <TASK> [ 318.686872] ? ntfsallocinode+0x1a/0x60 [ 318.687235] attrloadrunsvcn+0x2b/0xa0 [ 318.687468] miread+0xbb/0x250 [ 318.687576] ntfsiget5+0x114/0xd90 [ 318.687750] ntfsfillsuper+0x588/0x11b0 [ 318.687953] ? putntfs+0x130/0x130 [ 318.688065] ? snprintf+0x49/0x70 [ 318.688164] ? putntfs+0x130/0x130 [ 318.688256] gettreebdev+0x16a/0x260 [ 318.688407] vfsgettree+0x20/0xb0 [ 318.688519] pathmount+0x2dc/0x9b0 [ 318.688877] domount+0x74/0x90 [ 318.689142] x64sysmount+0x89/0xd0 [ 318.689636] dosyscall64+0x3b/0x90 [ 318.689998] entrySYSCALL64afterhwframe+0x63/0xcd [ 318.690318] RIP: 0033:0x7fd9e133c48a [ 318.690687] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008 [ 318.691357] RSP: 002b:00007ffd374406c8 EFLAGS: 00000202 ORIGRAX: 00000000000000a5 [ 318.691632] RAX: ffffffffffffffda RBX: 0000564d0b051080 RCX: 00007fd9e133c48a [ 318.691920] RDX: 0000564d0b051280 RSI: 0000564d0b051300 RDI: 0000564d0b0596a0 [ 318.692123] RBP: 0000000000000000 R08: 0000564d0b0512a0 R09: 0000000000000020 [ 318.692349] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564d0b0596a0 [ 318.692673] R13: 0000564d0b051280 R14: 0000000000000000 R15: 00000000ffffffff [ 318.693007] </TASK> [ 318.693271] Modules linked in: [ 318.693614] CR2: 0000000000000158 [ 318.694446] ---[ end trace 0000000000000000 ]--- [ 318.694779] RIP: 0010:nifindattr+0x2d/0x1c0 [ 318.694952] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180 [ 318.696042] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246 [ 318.696531] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080 [ 318.698114] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 318.699286] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 318.699795] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080 [ 318.700236] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000 [ 318.700973] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000 [ ---truncated---

drm/amdkfd: Fix double release compute pasid

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

orangefs: Fix kmemleak in orangefssysfsinit()

When insert and remove the orangefs module, there are kobjects memory leaked as below:

unreferenced object 0xffff88810f95af00 (size 64): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): a0 83 af 01 81 88 ff ff 08 af 95 0f 81 88 ff ff ................ 08 af 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloctrace+0x27/0xa0 [<000000005a6e4dfe>] orangefssysfsinit+0x42/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] dooneinitcall+0x87/0x2a0 [<0000000054f22384>] doinitmodule+0xdf/0x320 [<000000003263bdea>] loadmodule+0x2f98/0x3330 [<0000000052cd4153>] dosysfinitmodule+0x113/0x1b0 [<00000000250ae02b>] dosyscall64+0x35/0x80 [<00000000f11c03c7>] entrySYSCALL64afterhwframe+0x46/0xb0

unreferenced object 0xffff88810f95ae80 (size 64): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): c8 90 0f 02 81 88 ff ff 88 ae 95 0f 81 88 ff ff ................ 88 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloctrace+0x27/0xa0 [<000000001a4841fa>] orangefssysfsinit+0xc7/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] dooneinitcall+0x87/0x2a0 [<0000000054f22384>] doinitmodule+0xdf/0x320 [<000000003263bdea>] loadmodule+0x2f98/0x3330 [<0000000052cd4153>] dosysfinitmodule+0x113/0x1b0 [<00000000250ae02b>] dosyscall64+0x35/0x80 [<00000000f11c03c7>] entrySYSCALL64afterhwframe+0x46/0xb0

unreferenced object 0xffff88810f95ae00 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.511s) hex dump (first 32 bytes): 60 87 a1 00 81 88 ff ff 08 ae 95 0f 81 88 ff ff ............... 08 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloctrace+0x27/0xa0 [<000000005915e797>] orangefssysfsinit+0x12b/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] dooneinitcall+0x87/0x2a0 [<0000000054f22384>] doinitmodule+0xdf/0x320 [<000000003263bdea>] loadmodule+0x2f98/0x3330 [<0000000052cd4153>] dosysfinitmodule+0x113/0x1b0 [<00000000250ae02b>] dosyscall64+0x35/0x80 [<00000000f11c03c7>] entrySYSCALL64afterhwframe+0x46/0xb0

unreferenced object 0xffff88810f95ad80 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.511s) hex dump (first 32 bytes): 78 90 0f 02 81 88 ff ff 88 ad 95 0f 81 88 ff ff x............... 88 ad 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloctrace+0x27/0xa0 [<000000007a14eb35>] orangefssysfsinit+0x1ac/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] dooneinitcall+0x87/0x2a0 [<0000000054f22384>] doinitmodule+0xdf/0x320 [<000000003263bdea>] loadmodule+0x2f98/0x3330 [<0000000052cd4153>] dosysfinitmodule+0x113/0x1b0 [<00000000250ae02b>] dosyscall64+0x35/0x80 [<00000000f11c03c7>] entrySYSCALL64afterhwframe+0x46/0xb0

unreferenced object 0xffff88810f95ac00 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.531s) hex dump (first 32 bytes): e0 ff 67 02 81 88 ff ff 08 ac 95 0f 81 88 ff ff ..g............. 08 ac 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloctrace+0x27/0xa0 [<000000001f38adcb>] orangefssysfsinit+0x291/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] dooneinitcall+0x87/0x2a0 [<0000000054f22384>] doinitmodule+0xdf/0x320 [<000000003263bdea>] loadmodule+0x2f98/0x3330 [<0000000052cd4153>] dosysfinitmodule+0x113/0x1b0 [<00000000250ae02b>] dosyscall64+0x35/ ---truncated---

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

KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception

Previously, commit ed129ec9057f ("KVM: x86: forcibly leave nested mode on vCPU reset") addressed an issue where a triple fault occurring in nested mode could lead to use-after-free scenarios. However, the commit did not handle the analogous situation for System Management Mode (SMM).

This omission results in triggering a WARN when KVM forces a vCPU INIT after SHUTDOWN interception while the vCPU is in SMM. This situation was reprodused using Syzkaller by:

1) Creating a KVM VM and vCPU 2) Sending a KVMSMI ioctl to explicitly enter SMM 3) Executing invalid instructions causing consecutive exceptions and eventually a triple fault

The issue manifests as follows:

WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112 kvmvcpureset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Modules linked in: CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvmvcpureset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Call Trace: <TASK> shutdowninterception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svminvokeexithandler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svmhandleexit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpuenterguest arch/x86/kvm/x86.c:10959 [inline] vcpurun+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvmarchvcpuioctlrun+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvmvcpuioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvmmain.c:4122 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:870 [inline] sesysioctl fs/ioctl.c:856 [inline] x64sysioctl+0x19a/0x210 fs/ioctl.c:856 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x35/0x80 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x6e/0xd8

Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN() in kvmvcpureset() to guard against KVM bugs, e.g. to detect improper emulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs to do something sane with the VMCB, since it's technically undefined, and INIT is the least awful choice given KVM's ABI.

So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of SMM to avoid any weirdness (and the WARN).

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

[sean: massage changelog, make it clear this isn't architectural behavior]

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

smb: client: fix OOB reads parsing symlink error response

When a CREATE returns STATUSSTOPPEDONSYMLINK, smb2checkmessage() returns success without any length validation, leaving the symlink parsers as the only defense against an untrusted server.

symlinkdata() walks SMB 3.1.1 error contexts with the loop test "p < end", but reads p->ErrorId at offset 4 and p->ErrorDataLength at offset 0. When the server-controlled ErrorDataLength advances p to within 1-7 bytes of end, the next iteration will read past it. When the matching context is found, sym->SymLinkErrorTag is read at offset 4 from p->ErrorContextData with no check that the symlink header itself fits.

smb2parsesymlinkresponse() then bounds-checks the substitute name using SMB2SYMLINKSTRUCTSIZE as the offset of PathBuffer from iovbase. That value is computed as sizeof(smb2errrsp) + sizeof(smb2symlinkerrrsp), which is correct only when ErrorContextCount == 0.

With at least one error context the symlink data sits 8 bytes deeper, and each skipped non-matching context shifts it further by 8 + ALIGN(ErrorDataLength, 8). The check is too short, allowing the substitute name read to run past iovlen. The out-of-bound heap bytes are UTF-16-decoded into the symlink target and returned to userspace via readlink(2).

Fix this all up by making the loops test require the full context header to fit, rejecting sym if its header runs past end, and bound the substitute name against the actual position of sym->PathBuffer rather than a fixed offset.

Because suboffs and sublen are 16bits, the pointer math will not overflow here with the new greater-than.

A use-after-free vulnerability in the Linux kernel's netfilter: nftables component can be exploited to achieve local privilege escalation.

The nftverdictinit() function allows positive values as drop error within the hook verdict, and hence the nfhookslow() function can cause a double free vulnerability when NFDROP is issued with a drop error which resembles NFACCEPT.

We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.

Bluetooth: virtiobt: clamp rx length before skbput

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

dm: clear cloned request bio pointer when last clone bio completes

Stale rq->bio values have been observed to cause double-initialization of cloned bios in request-based device-mapper targets, leading to use-after-free and double-free scenarios.

One such case occurs when using dm-multipath on top of a PCIe NVMe namespace, where cloned request bios are freed during blkcompleterequest(), but rq->bio is left intact. Subsequent clone teardown then attempts to free the same bios again via blkrqunprepclone().

The resulting double-free path looks like:

nvmepcicompletebatch() nvmecompletebatch() blkmqendrequestbatch() blkcompleterequest() // called on a DM clone request bioendio() // first free of all clone bios ... rq->endio() // endclonerequest() dmcompleterequest(tio->orig) dmsoftirqdone() dmdone() dmendrequest() blkrqunprepclone() // second free of clone bios

Fix this by clearing the clone request's bio pointer when the last cloned bio completes, ensuring that later teardown paths do not attempt to free already-released bios.

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

wifi: iwlwifi: mvm: fix potential out-of-bounds read in iwlmvmndmatchinfohandler()

The memcpy function assumes the dynamic array notif->matches is at least as large as the number of bytes to copy. Otherwise, results->matches may contain unwanted data. To guarantee safety, extend the validation in one of the checks to ensure sufficient packet length.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

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

smb: client: split cachedfid bitfields to avoid shared-byte RMW races

isopen, haslease and onlist are stored in the same bitfield byte in struct cachedfid but are updated in different code paths that may run concurrently. Bitfield assignments generate byte read–modify–write operations (e.g. orb $mask, addr on x8664), so updating one flag can restore stale values of the others.

A possible interleaving is: CPU1: load old byte (haslease=1, onlist=1) CPU2: clear both flags (store 0) CPU1: RMW store (old | ISOPEN) -> reintroduces cleared bits

To avoid this class of races, convert these flags to separate bool fields.

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

octeontx2-pf: Fix use-after-free bugs in otx2synctstamp()

The original code relies on canceldelayedwork() in otx2ptpdestroy(), which does not ensure that the delayed work item synctstampwork has fully completed if it was already running. This leads to use-after-free scenarios where otx2ptp is deallocated by otx2ptpdestroy(), while synctstampwork remains active and attempts to dereference otx2ptp in otx2synctstamp(). Furthermore, the synctstampwork is cyclic, the likelihood of triggering the bug is nonnegligible.

A typical race condition is illustrated below:

CPU 0 (cleanup) | CPU 1 (delayed work callback) otx2remove() | otx2ptpdestroy() | otx2synctstamp() canceldelayedwork() | kfree(ptp) | | ptp = containerof(...); //UAF | ptp-> //UAF

This is confirmed by a KASAN report:

BUG: KASAN: slab-use-after-free in runtimerbase.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff88800aa09a18 by task bash/136 ... Call Trace: <IRQ> dumpstacklvl+0x55/0x70 printreport+0xcf/0x610 ? runtimerbase.part.0+0x7d7/0x8c0 kasanreport+0xb8/0xf0 ? runtimerbase.part.0+0x7d7/0x8c0 runtimerbase.part.0+0x7d7/0x8c0 ? pfxruntimerbase.part.0+0x10/0x10 ? pfxreadtsc+0x10/0x10 ? ktimeget+0x60/0x140 ? lapicnextevent+0x11/0x20 ? clockeventsprogramevent+0x1d4/0x2a0 runtimersoftirq+0xd1/0x190 handlesoftirqs+0x16a/0x550 irqexitrcu+0xaf/0xe0 sysvecapictimerinterrupt+0x70/0x80 </IRQ> ... Allocated by task 1: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 kasankmalloc+0x7f/0x90 otx2ptpinit+0xb1/0x860 otx2probe+0x4eb/0xc30 localpciprobe+0xdc/0x190 pcideviceprobe+0x2fe/0x470 reallyprobe+0x1ca/0x5c0 driverprobedevice+0x248/0x310 driverprobedevice+0x44/0x120 driverattach+0xd2/0x310 busforeachdev+0xed/0x170 busadddriver+0x208/0x500 driverregister+0x132/0x460 dooneinitcall+0x89/0x300 kernelinitfreeable+0x40d/0x720 kernelinit+0x1a/0x150 retfromfork+0x10c/0x1a0 retfromforkasm+0x1a/0x30

Freed by task 136: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3a/0x60 kasanslabfree+0x3f/0x50 kfree+0x137/0x370 otx2ptpdestroy+0x38/0x80 otx2remove+0x10d/0x4c0 pcideviceremove+0xa6/0x1d0 devicereleasedriverinternal+0xf8/0x210 pcistopbusdevice+0x105/0x150 pcistopandremovebusdevicelocked+0x15/0x30 removestore+0xcc/0xe0 kernfsfopwriteiter+0x2c3/0x440 vfswrite+0x871/0xd70 ksyswrite+0xee/0x1c0 dosyscall64+0xac/0x280 entrySYSCALL64afterhwframe+0x77/0x7f ...

Replace canceldelayedwork() with canceldelayedworksync() to ensure that the delayed work item is properly canceled before the otx2ptp is deallocated.

This bug was initially identified through static analysis. To reproduce and test it, I simulated the OcteonTX2 PCI device in QEMU and introduced artificial delays within the otx2synctstamp() function to increase the likelihood of triggering the bug.

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

kernfs: Fix UAF in polling when open file is released

A use-after-free (UAF) vulnerability was identified in the PSI (Pressure Stall Information) monitoring mechanism:

BUG: KASAN: slab-use-after-free in psitriggerpoll+0x3c/0x140 Read of size 8 at addr ffff3de3d50bd308 by task systemd/1

psitriggerpoll+0x3c/0x140 cgrouppressurepoll+0x70/0xa0 cgroupfilepoll+0x8c/0x100 kernfsfoppoll+0x11c/0x1c0 epitempoll.isra.0+0x188/0x2c0

Allocated by task 1: cgroupfileopen+0x88/0x388 kernfsfopopen+0x73c/0xaf0 dodentryopen+0x5fc/0x1200 vfsopen+0xa0/0x3f0 doopen+0x7e8/0xd08 pathopenat+0x2fc/0x6b0 dofilpopen+0x174/0x368

Freed by task 8462: cgroupfilerelease+0x130/0x1f8 kernfsdrainopenfiles+0x17c/0x440 kernfsdrain+0x2dc/0x360 kernfsshow+0x1b8/0x288 cgroupfileshow+0x150/0x268 cgrouppressurewrite+0x1dc/0x340 cgroupfilewrite+0x274/0x548

Reproduction Steps: 1. Open test/cpu.pressure and establish epoll monitoring 2. Disable monitoring: echo 0 > test/cgroup.pressure 3. Re-enable monitoring: echo 1 > test/cgroup.pressure

The race condition occurs because: 1. When cgroup.pressure is disabled (echo 0 > cgroup.pressure), it: - Releases PSI triggers via cgroupfilerelease() - Frees of->priv through kernfsdrainopenfiles() 2. While epoll still holds reference to the file and continues polling 3. Re-enabling (echo 1 > cgroup.pressure) accesses freed of->priv

epolling disable/enable cgroup.pressure fd=open(cpu.pressure) while(1) ... epollwait kernfsfoppoll kernfsgetactive = true echo 0 > cgroup.pressure ... cgroupfileshow kernfsshow // inactive kn kernfsdrainopenfiles cft->release(of); kfree(ctx); ... kernfsgetactive = false echo 1 > cgroup.pressure kernfsshow kernfsactivateone(kn); kernfsfoppoll kernfsgetactive = true cgroupfilepoll psitriggerpoll // UAF ... end: close(fd)

To address this issue, introduce kernfsgetactiveof() for kernfs open files to obtain active references. This function will fail if the open file has been released. Replace kernfsgetactive() with kernfsgetactiveof() to prevent further operations on released file descriptors.

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

xfrm: interface: fix use-after-free after changing collectmd xfrm interface

collectmd property on xfrm interfaces can only be set on device creation, thus xfrmichangelink() should fail when called on such interfaces.

The check to enforce this was done only in the case where the xi was returned from xfrmilocate() which doesn't look for the collectmd interface, and thus the validation was never reached.

Calling changelink would thus errornously place the special interface xi in the xfrminet->xfrmi hash, but since it also exists in the xfrminet->collectmdxfrmi pointer it would lead to a double free when the net namespace was taken down [1].

Change the check to use the xi from netdevpriv which is available earlier in the function to prevent changes in xfrm collectmd interfaces.

[1] resulting oops: [ 8.516540] kernel BUG at net/core/dev.c:12029! [ 8.516552] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 8.516559] CPU: 0 UID: 0 PID: 12 Comm: kworker/u80:0 Not tainted 6.15.0-virtme #5 PREEMPT(voluntary) [ 8.516565] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 8.516569] Workqueue: netns cleanupnet [ 8.516579] RIP: 0010:unregisternetdevicemanynotify+0x101/0xab0 [ 8.516590] Code: 90 0f 0b 90 48 8b b0 78 01 00 00 48 8b 90 80 01 00 00 48 89 56 08 48 89 32 4c 89 80 78 01 00 00 48 89 b8 80 01 00 00 eb ac 90 <0f> 0b 48 8b 45 00 4c 8d a0 88 fe ff ff 48 39 c5 74 5c 41 80 bc 24 [ 8.516593] RSP: 0018:ffffa93b8006bd30 EFLAGS: 00010206 [ 8.516598] RAX: ffff98fe4226e000 RBX: ffffa93b8006bd58 RCX: ffffa93b8006bc60 [ 8.516601] RDX: 0000000000000004 RSI: 0000000000000000 RDI: dead000000000122 [ 8.516603] RBP: ffffa93b8006bdd8 R08: dead000000000100 R09: ffff98fe4133c100 [ 8.516605] R10: 0000000000000000 R11: 00000000000003d2 R12: ffffa93b8006be00 [ 8.516608] R13: ffffffff96c1a510 R14: ffffffff96c1a510 R15: ffffa93b8006be00 [ 8.516615] FS: 0000000000000000(0000) GS:ffff98fee73b7000(0000) knlGS:0000000000000000 [ 8.516619] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.516622] CR2: 00007fcd2abd0700 CR3: 000000003aa40000 CR4: 0000000000752ef0 [ 8.516625] PKRU: 55555554 [ 8.516627] Call Trace: [ 8.516632] <TASK> [ 8.516635] ? rtnlislocked+0x15/0x20 [ 8.516641] ? unregisternetdevicequeue+0x29/0xf0 [ 8.516650] opsundolist+0x1f2/0x220 [ 8.516659] cleanupnet+0x1ad/0x2e0 [ 8.516664] processonework+0x160/0x380 [ 8.516673] workerthread+0x2aa/0x3c0 [ 8.516679] ? pfxworkerthread+0x10/0x10 [ 8.516686] kthread+0xfb/0x200 [ 8.516690] ? pfxkthread+0x10/0x10 [ 8.516693] ? pfxkthread+0x10/0x10 [ 8.516697] retfromfork+0x82/0xf0 [ 8.516705] ? pfxkthread+0x10/0x10 [ 8.516709] retfromforkasm+0x1a/0x30 [ 8.516718] </TASK>

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

tls: always refresh the queue when reading sock

After recent changes in net-next TCP compacts skbs much more aggressively. This unearthed a bug in TLS where we may try to operate on an old skb when checking if all skbs in the queue have matching decrypt state and geometry.

BUG: KASAN: slab-use-after-free in tlsstrpcheckrcv+0x898/0x9a0 [tls] (net/tls/tlsstrp.c:436 net/tls/tlsstrp.c:530 net/tls/tlsstrp.c:544) Read of size 4 at addr ffff888013085750 by task tls/13529

CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme Call Trace: kasanreport+0xca/0x100 tlsstrpcheckrcv+0x898/0x9a0 [tls] tlsrxrecwait+0x2c9/0x8d0 [tls] tlsswrecvmsg+0x40f/0x1aa0 [tls] inetrecvmsg+0x1c3/0x1f0

Always reload the queue, fast path is to have the record in the queue when we wake, anyway (IOW the path going down "if !strp->stm.fulllen").

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

LoongArch: BPF: Fix off-by-one error in buildprologue()

Vincent reported that running BPF progs with tailcalls on LoongArch causes kernel hard lockup. Debugging the issues shows that the JITed image missing a jirl instruction at the end of the epilogue.

There are two passes in JIT compiling, the first pass set the flags and the second pass generates JIT code based on those flags. With BPF progs mixing bpf2bpf and tailcalls, buildprologue() generates N insns in the first pass and then generates N+1 insns in the second pass. This makes epilogueoffset off by one and we will jump to some unexpected insn and cause lockup. Fix this by inserting a nop insn.