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:

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:

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---

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:

iouring: check if we need to reschedule during overflow flush

In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while.

Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.

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:

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.

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

mapletree: fix MASTATEPREALLOC flag in maspreallocate()

Temporarily clear the preallocation flag when explicitly requesting allocations. Pre-existing allocations are already counted against the request through masnodecountgfp(), but the allocations will not happen if the MASTATEPREALLOC flag is set. This flag is meant to avoid re-allocating in bulk allocation mode, and to detect issues with preallocation calculations.

The MASTATEPREALLOC flag should also always be set on zero allocations so that detection of underflow allocations will print a WARNON() during consumption.

User visible effect of this flaw is a WARNON() followed by a null pointer dereference when subsequent requests for larger number of nodes is ignored, such as the vma merge retry in mmapregion() caused by drivers altering the vma flags (which happens in v6.6, at least)

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

Bluetooth: hciconn: Fix crash on hcicreatecissync

When attempting to connect multiple ISO sockets without using DEFERSETUP may result in the following crash:

BUG: KASAN: null-ptr-deref in hcicreatecissync+0x18b/0x2b0 Read of size 2 at addr 0000000000000036 by task kworker/u3:1/50

CPU: 0 PID: 50 Comm: kworker/u3:1 Not tainted 6.0.0-rc7-02243-gb84a13ff4eda #4373 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-1.fc36 04/01/2014 Workqueue: hci0 hcicmdsyncwork Call Trace: <TASK> dumpstacklvl+0x19/0x27 kasanreport+0xbc/0xf0 ? hcicreatecissync+0x18b/0x2b0 hcicreatecissync+0x18b/0x2b0 ? getlinkmode+0xd0/0xd0 ? wwmutexlockslowpath+0x10/0x10 ? mutexlock+0xe0/0xe0 ? getlinkmode+0xd0/0xd0 hcicmdsyncwork+0x111/0x190 processonework+0x427/0x650 workerthread+0x87/0x750 ? processonework+0x650/0x650 kthread+0x14e/0x180 ? kthreadexit+0x50/0x50 retfromfork+0x22/0x30 </TASK>

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

phy: qcom-qmp-usb: Fix an NULL vs ISERR() bug

The qmpusbiomap() helper function currently returns the raw result of devmioremap() for non-exclusive mappings. Since devmioremap() may return a NULL pointer and the caller only checks error pointers with ISERR(), NULL could bypass the check and lead to an invalid dereference.

Fix the issue by checking if devmioremap() returns NULL. When it does, qmpusbiomap() now returns an error pointer via IOMEMERRPTR(-ENOMEM), ensuring safe and consistent error handling.

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

RDMA/mlx5: Fix mlx5ibgethwstats when used for device

Currently, when mlx5ibgethwstats() is used for device (portnum = 0), there is a special handling in order to use the correct counters, but, portnum is being passed down the stack without any change. Also, some functions assume that portnum >=1. As a result, the following oops can occur.

BUG: unable to handle page fault for address: ffff89510294f1a8 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP CPU: 8 PID: 1382 Comm: devlink Tainted: G W 6.1.0-rc4forupstreambase202211101612 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rawspinlock+0xc/0x20 Call Trace: <TASK> mlx5ibgetnativeportmdev+0x73/0xe0 [mlx5ib] dogethwstats.constprop.0+0x109/0x160 [mlx5ib] mlx5ibgethwstats+0xad/0x180 [mlx5ib] ibsetupdeviceattrs+0xf0/0x290 [ibcore] ibregisterdevice+0x3bb/0x510 [ibcore] ? atomicnotifierchainregister+0x67/0x80 mlx5ibadd+0x2b/0x80 [mlx5ib] mlx5rprobe+0xb8/0x150 [mlx5ib] ? auxiliarymatchid+0x6a/0x90 auxiliarybusprobe+0x3c/0x70 ? driversysfsadd+0x6b/0x90 reallyprobe+0xcd/0x380 driverprobedevice+0x80/0x170 driverprobedevice+0x1e/0x90 deviceattachdriver+0x7d/0x100 ? driverallowsasyncprobing+0x60/0x60 ? driverallowsasyncprobing+0x60/0x60 busforeachdrv+0x7b/0xc0 deviceattach+0xbc/0x200 busprobedevice+0x87/0xa0 deviceadd+0x404/0x940 ? devsetname+0x53/0x70 auxiliarydeviceadd+0x43/0x60 addadev+0x99/0xe0 [mlx5core] mlx5attachdevice+0xc8/0x120 [mlx5core] mlx5loadonedevllocked+0xb2/0xe0 [mlx5core] devlinkreload+0x133/0x250 devlinknlcmdreload+0x480/0x570 ? devlinknlpredoit+0x44/0x2b0 genlfamilyrcvmsgdoit.isra.0+0xc2/0x110 genlrcvmsg+0x180/0x2b0 ? devlinknlcmdregionreaddumpit+0x540/0x540 ? devlinkreload+0x250/0x250 ? devlinkput+0x50/0x50 ? genlfamilyrcvmsgdoit.isra.0+0x110/0x110 netlinkrcvskb+0x54/0x100 genlrcv+0x24/0x40 netlinkunicast+0x1f6/0x2c0 netlinksendmsg+0x237/0x490 socksendmsg+0x33/0x40 syssendto+0x103/0x160 ? handlemmfault+0x10e/0x290 ? douseraddrfault+0x1c0/0x5f0 x64syssendto+0x25/0x30 dosyscall64+0x3d/0x90 entrySYSCALL64afterhwframe+0x46/0xb0

Fix it by setting portnum to 1 in order to get device status and remove unused variable.

A NULL pointer dereference flaw was found in the Linux kernel's drivers/gpu/drm/msm/msmgemsubmit.c code in the submitlookupcmds function, which fails because it lacks a check of the return value of kmalloc(). This issue allows a local user to crash the system.

Bluetooth: virtiobt: validate rx pkttype header length

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

ASoC: SOF: Don't allow pointer operations on unconfigured streams

When reporting the pointer for a compressed stream we report the current I/O frame position by dividing the position by the number of channels multiplied by the number of container bytes. These values default to 0 and are only configured as part of setting the stream parameters so this allows a divide by zero to be configured. Validate that they are non zero, returning an error if not

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

spi: microchip-core-qspi: control built-in cs manually

The coreQSPI IP supports only a single chip select, which is automagically operated by the hardware - set low when the transmit buffer first gets written to and set high when the number of bytes written to the TOTALBYTES field of the FRAMES register have been sent on the bus. Additional devices must use GPIOs for their chip selects. It was reported to me that if there are two devices attached to this QSPI controller that the in-built chip select is set low while linux tries to access the device attached to the GPIO.

This went undetected as the boards that connected multiple devices to the SPI controller all exclusively used GPIOs for chip selects, not relying on the built-in chip select at all. It turns out that this was because the built-in chip select, when controlled automagically, is set low when active and high when inactive, thereby ruling out its use for active-high devices or devices that need to transmit with the chip select disabled.

Modify the driver so that it controls chip select directly, retaining the behaviour for memops of setting the chip select active for the entire duration of the transfer in the execop callback. For regular transfers, implement the setcs callback for the core to use.

As part of this, the existing setup callback, mchpcoreqspisetupop(), is removed. Modifying the CLKIDLE field is not safe to do during operation when there are multiple devices, so this code is removed entirely. Setting the MASTER and ENABLE fields is something that can be done once at probe, it doesn't need to be re-run for each device. Instead the new setup callback sets the built-in chip select to its inactive state for active-low devices, as the reset value of the chip select in software controlled mode is low.

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

arm64: Set nocfi on swsusparchresume()

A DABT is reported[1] on an android based system when resume from hiberate. This happens because swsusparchsuspendexit() is marked with SYMCODE() and does not have a CFI hash, but swsusparchresume() will attempt to verify the CFI hash when calling a copy of swsusparchsuspendexit().

Given that there's an existing requirement that the entrypoint to swsusparchsuspendexit() is the first byte of the .hibernateexit.text section, we cannot fix this by marking swsusparchsuspendexit() with SYMFUNC(). The simplest fix for now is to disable the CFI check in swsusparchresume().

Mark swsusparchresume() as nocfi to disable the CFI check.

[1] [ 22.991934][ T1] Unable to handle kernel paging request at virtual address 0000000109170ffc [ 22.991934][ T1] Mem abort info: [ 22.991934][ T1] ESR = 0x0000000096000007 [ 22.991934][ T1] EC = 0x25: DABT (current EL), IL = 32 bits [ 22.991934][ T1] SET = 0, FnV = 0 [ 22.991934][ T1] EA = 0, S1PTW = 0 [ 22.991934][ T1] FSC = 0x07: level 3 translation fault [ 22.991934][ T1] Data abort info: [ 22.991934][ T1] ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 [ 22.991934][ T1] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 22.991934][ T1] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 22.991934][ T1] [0000000109170ffc] user address but activemm is swapper [ 22.991934][ T1] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP [ 22.991934][ T1] Dumping ftrace buffer: [ 22.991934][ T1] (ftrace buffer empty) [ 22.991934][ T1] Modules linked in: [ 22.991934][ T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.98-android15-8-g0b1d2aee7fc3-dirty-4k #1 688c7060a825a3ac418fe53881730b355915a419 [ 22.991934][ T1] Hardware name: Unisoc UMS9360-base Board (DT) [ 22.991934][ T1] pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 22.991934][ T1] pc : swsusparchresume+0x2ac/0x344 [ 22.991934][ T1] lr : swsusparchresume+0x294/0x344 [ 22.991934][ T1] sp : ffffffc08006b960 [ 22.991934][ T1] x29: ffffffc08006b9c0 x28: 0000000000000000 x27: 0000000000000000 [ 22.991934][ T1] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000820 [ 22.991934][ T1] x23: ffffffd0817e3000 x22: ffffffd0817e3000 x21: 0000000000000000 [ 22.991934][ T1] x20: ffffff8089171000 x19: ffffffd08252c8c8 x18: ffffffc080061058 [ 22.991934][ T1] x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 0000000000000004 [ 22.991934][ T1] x14: ffffff8178c88000 x13: 0000000000000006 x12: 0000000000000000 [ 22.991934][ T1] x11: 0000000000000015 x10: 0000000000000001 x9 : ffffffd082533000 [ 22.991934][ T1] x8 : 0000000109171000 x7 : 205b5d3433393139 x6 : 392e32322020205b [ 22.991934][ T1] x5 : 000000010916f000 x4 : 000000008164b000 x3 : ffffff808a4e0530 [ 22.991934][ T1] x2 : ffffffd08058e784 x1 : 0000000082326000 x0 : 000000010a283000 [ 22.991934][ T1] Call trace: [ 22.991934][ T1] swsusparchresume+0x2ac/0x344 [ 22.991934][ T1] hibernationrestore+0x158/0x18c [ 22.991934][ T1] loadimageandrestore+0xb0/0xec [ 22.991934][ T1] softwareresume+0xf4/0x19c [ 22.991934][ T1] softwareresumeinitcall+0x34/0x78 [ 22.991934][ T1] dooneinitcall+0xe8/0x370 [ 22.991934][ T1] doinitcalllevel+0xc8/0x19c [ 22.991934][ T1] doinitcalls+0x70/0xc0 [ 22.991934][ T1] dobasicsetup+0x1c/0x28 [ 22.991934][ T1] kernelinitfreeable+0xe0/0x148 [ 22.991934][ T1] kernelinit+0x20/0x1a8 [ 22.991934][ T1] retfromfork+0x10/0x20 [ 22.991934][ T1] Code: a9400a61 f94013e0 f9438923 f9400a64 (b85fc110)

[catalin.marinas@arm.com: commit log updated by Mark Rutland]

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

xen/netfront: fix crash when removing device

When removing a netfront device directly after a suspend/resume cycle it might happen that the queues have not been setup again, causing a crash during the attempt to stop the queues another time.

Fix that by checking the queues are existing before trying to stop them.

This is XSA-465 / CVE-2024-53240.

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

perf: Fix event leak upon exit

When a task is scheduled out, pending sigtrap deliveries are deferred to the target task upon resume to userspace via taskwork.

However failures while adding an event's callback to the taskwork engine are ignored. And since the last call for events exit happen after task work is eventually closed, there is a small window during which pending sigtrap can be queued though ignored, leaking the event refcount addition such as in the following scenario:

TASK A -----

doexit() exittaskwork(tsk);

<IRQ> perfeventoverflow() event->pendingsigtrap = pendingid; irqworkqueue(&event->pendingirq); </IRQ> =========> PREEMPTION: TASK A -> TASK B eventschedout() event->pendingsigtrap = 0; atomiclongincnotzero(&event->refcount) // FAILS: task work has exited taskworkadd(&event->pendingtask) [...] <IRQ WORK> perfpendingirq() // early return: event->oncpu = -1 </IRQ WORK> [...] =========> TASK B -> TASK A perfeventexittask(tsk) perfeventexitevent() freeevent() WARN(atomiclongcmpxchg(&event->refcount, 1, 0) != 1) // leak event due to unexpected refcount == 2

As a result the event is never released while the task exits.

Fix this with appropriate taskworkadd()'s error handling.

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

perf: Fix event leak upon exec and file release

The perf pending task work is never waited upon the matching event release. In the case of a child event, released via freeevent() directly, this can potentially result in a leaked event, such as in the following scenario that doesn't even require a weak IRQ work implementation to trigger:

schedule() preparetaskswitch() =======> <NMI> perfeventoverflow() event->pendingsigtrap = ... irqworkqueue(&event->pendingirq) <======= </NMI> perfeventtaskschedout() eventschedout() event->pendingsigtrap = 0; atomiclongincnotzero(&event->refcount) taskworkadd(&event->pendingtask) finishlockswitch() =======> <IRQ> perfpendingirq() //do nothing, rely on pending task work <======= </IRQ>

beginnewexec() perfeventexittask() perfeventexitevent() // If is child event freeevent() WARN(atomiclongcmpxchg(&event->refcount, 1, 0) != 1) // event is leaked

Similar scenarios can also happen with perfeventremoveonexec() or simply against concurrent perfeventrelease().

Fix this with synchonizing against the possibly remaining pending task work while freeing the event, just like is done with remaining pending IRQ work. This means that the pending task callback neither need nor should hold a reference to the event, preventing it from ever beeing freed.

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

s390/dasd: fix error checks in dasdcopypairstore()

dasdaddbusid() can return an error via ERRPTR() if an allocation fails. However, two callsites in dasdcopypairstore() do not check the result, potentially resulting in a NULL pointer dereference. Fix this by checking the result with ISERR() and returning the error up the stack.

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

usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock

When config CONFIGUSBDWC3DUALROLE is selected, and trigger system to enter suspend status with below command: echo mem > /sys/power/state There will be a deadlock issue occurring. Detailed invoking path as below: dwc3suspendcommon() spinlockirqsave(&dwc->lock, flags); <-- 1st dwc3gadgetsuspend(dwc); dwc3gadgetsoftdisconnect(dwc); spinlockirqsave(&dwc->lock, flags); <-- 2nd This issue is exposed by commit c7ebd8149ee5 ("usb: dwc3: gadget: Fix NULL pointer dereference in dwc3gadgetsuspend") that removes the code of checking whether dwc->gadgetdriver is NULL or not. It causes the following code is executed and deadlock occurs when trying to get the spinlock. In fact, the root cause is the commit 5265397f9442("usb: dwc3: Remove DWC3 locking during gadget suspend/resume") that forgot to remove the lock of otg mode. So, remove the redundant lock of otg mode during gadget suspend/resume.

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

md/raid5: fix deadlock that raid5d() wait for itself to clear MDSBCHANGEPENDING

Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MDSBCHANGEPENDING in raid5d"")

However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d().

Current implementation in raid5d() has a weird dependence:

1) mdcheckrecovery() from raid5d() must hold 'reconfigmutex' to clear MDSBCHANGEPENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MDSBCHANGEPENDING to be cleared;

This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfigmutex', and mdcheckrecovery() can't update superblock, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfigmutex' is released.

Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MDSBCHANGEPENDING is still set after mdcheckrecovery(), daemon thread will be woken up when 'reconfigmutex' is released. Meanwhile, the hang problem will be fixed as well.

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

fbdev: savage: Handle err return when savagefbcheckvar failed

The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero") checks the value of pixclock to avoid divide-by-zero error. However the function savagefbprobe doesn't handle the error return of savagefbcheckvar. When pixclock is 0, it will cause divide-by-zero error.

dma-buf/sw-sync: don't enable IRQ from syncprintobj()

bpf: Allow delete from sockmap/sockhash only if update is allowed

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

drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails

Calling a6xxdestroy() before adrenogpuinit() leads to a null pointer dereference on:

msmgpucleanup() : platformsetdrvdata(gpu->pdev, NULL);

as gpu->pdev is only assigned in:

a6xxgpuinit() | adrenogpuinit | msmgpuinit()

Instead of relying on handwavy null checks down the cleanup chain, explicitly de-allocate the LLC data and free a6xxgpu instead.

Patchwork: https://patchwork.freedesktop.org/patch/588919/