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

LoongArch: cpuinfo: Fix a warning for CONFIGCPUMASKOFFSTACK

When CONFIGCPUMASKOFFSTACK and CONFIGDEBUGPERCPUMAPS is selected, cpumaxbitswarn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nrcpuids (the runtime limit) instead of NRCPUS to iterate CPUs.

[ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 showcpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.084034] Hardware name: Loongson Loongson-3A5000-7A1000-1w-V0.1-CRB/Loongson-LS3A5000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] showstack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dumpstacklvl+0x60/0x88 [ 3.217625] [<900000000023d268>] warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warnslowpathfmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] showcpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seqreaditer+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] newsyncread+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfsread+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksysread+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] dosyscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handlesyscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---

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

arm64: fix oops in concurrently setting insnemulation sysctls

emulationprochandler() changes table->data for procdointvecminmax and can generate the following Oops if called concurrently with itself:

| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 | Internal error: Oops: 96000006 [#1] SMP | Call trace: | updateinsnemulationmode+0xc0/0x148 | emulationprochandler+0x64/0xb8 | procsyscallhandler+0x9c/0xf8 | procsyswrite+0x18/0x20 | vfswrite+0x20/0x48 | vfswrite+0xe4/0x1d0 | ksyswrite+0x70/0xf8 | arm64syswrite+0x20/0x28 | el0svccommon.constprop.0+0x7c/0x1c0 | el0svchandler+0x2c/0xa0 | el0svc+0x8/0x200

To fix this issue, keep the table->data as &insn->currentmode and use containerof() to retrieve the insn pointer. Another mutex is used to protect against the currentmode update but not for retrieving insnemulation as table->data is no longer changing.

f2fs: fix null-ptr-deref in f2fsgetdnodeofdata

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

mm/memory: fix spurious warning when unmapping device-private/exclusive pages

Device private and exclusive entries are only supported for anonymous folios. This condition is tested in migratedevicepages() and makedeviceexclusive() using foliotestanon(). However the unmap path tests this assumption using vmaisanonymous().

This is wrong because whilst anonymous VMAs can only contain folios where foliotestanon() is true the opposite relation does not hold. A folio for which foliotestanon() is true does not imply vmaisanonymous() is true. Such a condition can occur if for example a folio is part of a private filebacked mapping.

In this case vmaisanonymous() is false as the mapping is filebacked, but foliotestanon() may be true, thus permitting devices to migrate the folio to device private memory. This can lead to the following spurious warnings during process teardown:

[ 772.737706] ------------[ cut here ]------------ [ 772.739201] WARNING: mm/memory.c:1754 at unmappagerange.cold+0x26/0x18a, CPU#17: hmm-tests/2041 [ 772.742050] Modules linked in: testhmm nvidiauvm(O) nvidia(O) [ 772.743959] CPU: 17 UID: 0 PID: 2041 Comm: hmm-tests Tainted: G W O 7.0.0+ #387 PREEMPT(full) [ 772.747104] Tainted: [W]=WARN, [O]=OOTMODULE [ 772.748509] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 772.752117] RIP: 0010:unmappagerange.cold+0x26/0x18a [ 772.753780] Code: 7e fe ff ff 48 89 4c 24 78 4c 89 44 24 38 e8 f2 ff b1 00 48 8b 4c 24 78 4c 8b 44 24 38 48 8b 44 24 18 48 83 78 48 00 74 04 90 <0f> 0b 90 48 89 ca b8 ff ff 37 00 48 c1 ea 03 48 c1 e0 2a 80 3c 02 [ 772.759602] RSP: 0018:ffff888112607550 EFLAGS: 00010286 [ 772.761310] RAX: ffff88811bbf4dc0 RBX: dffffc0000000000 RCX: ffffea03e9bfffd8 [ 772.763583] RDX: 1ffff1102377e9c1 RSI: 0000000000000008 RDI: ffff88811bbf4e08 [ 772.765914] RBP: 0000000000000006 R08: ffff8881059f7448 R09: ffffed10224c0e68 [ 772.768184] R10: ffff888112607347 R11: 0000000000000001 R12: 0000000000000001 [ 772.770461] R13: ffffea03e9bfffc0 R14: ffff888112607908 R15: ffffea03e9bfffc0 [ 772.772782] FS: 00007f327caa2780(0000) GS:ffff888427b7d000(0000) knlGS:0000000000000000 [ 772.775328] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 772.777187] CR2: 00007f327ca89000 CR3: 00000001994d5000 CR4: 00000000000006f0 [ 772.779135] Call Trace: [ 772.779792] <TASK> [ 772.780317] ? dmirrorintervalinvalidate+0x1a3/0x290 [testhmm] [ 772.781873] ? vmnormalpagepud+0x2b0/0x2b0 [ 772.782992] ? rwlockinit+0x150/0x150 [ 772.784006] ? lockrelease+0x216/0x2b0 [ 772.785008] ? mmunotifierinvalidaterangestart+0x505/0x6e0 [ 772.786522] ? lockrelease+0x216/0x2b0 [ 772.787498] ? unmapsinglevma+0xb6/0x210 [ 772.788573] unmapvmas+0x27d/0x520 [ 772.789506] ? unmapsinglevma+0x210/0x210 [ 772.790607] ? masupdategap.part.0+0x620/0x620 [ 772.791834] unmapregion+0x19e/0x350 [ 772.792769] ? removevma+0x130/0x130 [ 772.793684] ? masallocnodes+0x1f2/0x300 [ 772.794730] vmscompletemunmapvmas+0x8c1/0xe20 [ 772.795926] ? unmapregion+0x350/0x350 [ 772.796917] dovmialignmunmap+0x36a/0x4e0 [ 772.798018] ? lockrelease+0x216/0x2b0 [ 772.799024] ? vmashrink+0x620/0x620 [ 772.799983] dovmimunmap+0x150/0x2c0 [ 772.800939] vmmunmap+0x161/0x2c0 [ 772.801872] ? expanddownwards+0xd60/0xd60 [ 772.802948] ? clockeventsprogramevent+0x1ef/0x540 [ 772.804217] ? lockrelease+0x216/0x2b0 [ 772.805158] x64sysmunmap+0x59/0x80 [ 772.805776] dosyscall64+0xfc/0x670 [ 772.806336] ? irqentryexit+0xda/0x580 [ 772.806976] entrySYSCALL64afterhwframe+0x4b/0x53 [ 772.807772] RIP: 0033:0x7f327cbb2717 [ 772.808323] Code: 73 01 c3 48 8b 0d f9 76 0d 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 b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ---truncated---

drm/amdkfd: Don't call mmput from MMU notifier callback

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

drm/msm: always recover the gpu

Previously, in case there was no more work to do, recover worker wouldn't trigger recovery and would instead rely on the gpu going to sleep and then resuming when more work is submitted.

Recoverworker will first increment the fence of the hung ring so, if there's only one job submitted to a ring and that causes an hang, it will early out.

There's no guarantee that the gpu will suspend and resume before more work is submitted and if the gpu is in a hung state it will stay in that state and probably trigger a timeout again.

Just stop checking and always recover the gpu.

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

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

fsnotify: fix inode reference leak in fsnotifyrecalcmask()

fsnotifyrecalcmask() fails to handle the return value of fsnotifyrecalcmask(), which may return an inode pointer that needs to be released via fsnotifydropobject() when the connector's HASIREF flag transitions from set to cleared.

This manifests as a hung task with the following call trace:

INFO: task umount:1234 blocked for more than 120 seconds. Call Trace: schedule schedule fsnotifysbdelete genericshutdownsuper killanonsuper cleanupmnt taskworkrun doexit dogroupexit

The race window that triggers the iref leak:

Thread A (adding mark) Thread B (removing mark) ────────────────────── ──────────────────────── fsnotifyaddmarklocked(): fsnotifyaddmarklist(): spinlock(conn->lock) add markB(evictable) to list spinunlock(conn->lock) return

/ ---- gap: no lock held ---- /

fsnotifydetachmark(markA): spinlock(markA->lock) clear ATTACHED flag on markA spinunlock(markA->lock) fsnotifyputmark(markA)

fsnotifyrecalcmask(): spinlock(conn->lock) fsnotifyrecalcmask(): / markA skipped: ATTACHED cleared / / only markB(evictable) remains / wantiref = false hasiref = true / not yet cleared / -> HASIREF transitions true -> false -> returns inode pointer spinunlock(conn->lock) / BUG: return value discarded! iput() and fsnotifyputsbwatchedobjects() are never called /

Fix this by deferring the transition true -> false of HASIREF flag from fsnotifyrecalcmask() (Thread A) to fsnotifyputmark() (thread B).

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

dmaengine: dw: dmamux: fix OF node leak on route allocation failure

Make sure to drop the reference taken to the DMA master OF node also on late route allocation failures.

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

mm: slub: avoid wake up kswapd in settrackprepare

settrackprepare() can incur lock recursion. The issue is that it is called from hrtimerstartrangens holding the percpu(hrtimerbases)[n].lock, but when enabled CONFIGDEBUGOBJECTSTIMERS, may wake up kswapd in settrackprepare, and try to hold the percpu(hrtimerbases)[n].lock.

Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain GFPKSWAPDRECLAIM in the debugobjectsfillpool() case. Inside stack depot they are processed by gfpnestedmask(). Since slaballoc() has preemption disabled, we mask out GFPDIRECTRECLAIM from the flags there.

The oops looks something like:

BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .ownercpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spinbug+0x0 rawspinlockirqsave+0x80 hrtimertrytocancel+0x94 taskcontending+0x10c enqueuedlentity+0x2a4 dlserverstart+0x74 enqueuetaskfair+0x568 enqueuetask+0xac doactivatetask+0x14c ttwudoactivate+0xcc trytowakeup+0x6c8 defaultwakefunction+0x20 autoremovewakefunction+0x1c wakeup+0xac wakeupkswapd+0x19c wakeallkswapds+0x78 allocpagesslowpath+0x1ac allocpagesnoprof+0x298 stackdepotsaveflags+0x6b0 stackdepotsave+0x14 settrackprepare+0x5c slaballoc+0xccc kmalloccachenoprof+0x470 setpageowner+0x2bc postallochook[jt]+0x1b8 prepnewpage+0x28 getpagefromfreelist+0x1edc allocpagesnoprof+0x13c allocslabpage+0x244 allocateslab+0x7c slaballoc+0x8e8 kmemcacheallocnoprof+0x450 debugobjectsfillpool+0x22c debugobjectactivate+0x40 enqueuehrtimer[jt]+0xdc hrtimerstartrangens+0x5f8 ...

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

net: 9p: fix refcount leak in p9readwork() error handling

p9reqput need to be called when m->rreq->rc.sdata is NULL to avoid temporary refcount leak.

[Dominique: commit wording adjustments, p9reqput argument fixes for rebase]

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

pmdomain: imx8mp-blk-ctrl: add missing loop break condition

Currently imx8mpblkctrlremove() will continue the for loop until an out-of-bounds exception occurs.

pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : devpmdomaindetach+0x8/0x48 lr : imx8mpblkctrlshutdown+0x58/0x90 sp : ffffffc084f8bbf0 x29: ffffffc084f8bbf0 x28: ffffff80daf32ac0 x27: 0000000000000000 x26: ffffffc081658d78 x25: 0000000000000001 x24: ffffffc08201b028 x23: ffffff80d0db9490 x22: ffffffc082340a78 x21: 00000000000005b0 x20: ffffff80d19bc180 x19: 000000000000000a x18: ffffffffffffffff x17: ffffffc080a39e08 x16: ffffffc080a39c98 x15: 4f435f464f006c72 x14: 0000000000000004 x13: ffffff80d0172110 x12: 0000000000000000 x11: ffffff80d0537740 x10: ffffff80d05376c0 x9 : ffffffc0808ed2d8 x8 : ffffffc084f8bab0 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffffff80d19b9420 x4 : fffffffe03466e60 x3 : 0000000080800077 x2 : 0000000000000000 x1 : 0000000000000001 x0 : 0000000000000000 Call trace: devpmdomaindetach+0x8/0x48 platformshutdown+0x2c/0x48 deviceshutdown+0x158/0x268 kernelrestartprepare+0x40/0x58 kernelkexec+0x58/0xe8 dosysreboot+0x198/0x258 arm64sysreboot+0x2c/0x40 invokesyscall+0x5c/0x138 el0svccommon.constprop.0+0x48/0xf0 doel0svc+0x24/0x38 el0svc+0x38/0xc8 el0t64synchandler+0x120/0x130 el0t64sync+0x190/0x198 Code: 8128c2d0 ffffffc0 aa1e03e9 d503201f

bpf: Check rcureadlocktraceheld() in bpfmaplookuppercpuelem()

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

KVM: SVM: Don't BUG if userspace injects an interrupt with GIF=0

Don't BUG/WARN on interrupt injection due to GIF being cleared, since it's trivial for userspace to force the situation via KVMSETVCPUEVENTS (even if having at least a WARN there would be correct for KVM internally generated injections).

kernel BUG at arch/x86/kvm/svm/svm.c:3386! invalid opcode: 0000 [#1] SMP CPU: 15 PID: 926 Comm: smmtest Not tainted 5.17.0-rc3+ #264 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:svminjectirq+0xab/0xb0 [kvmamd] Code: <0f> 0b 0f 1f 00 0f 1f 44 00 00 80 3d ac b3 01 00 00 55 48 89 f5 53 RSP: 0018:ffffc90000b37d88 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810a234ac0 RCX: 0000000000000006 RDX: 0000000000000000 RSI: ffffc90000b37df7 RDI: ffff88810a234ac0 RBP: ffffc90000b37df7 R08: ffff88810a1fa410 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888109571000 R14: ffff88810a234ac0 R15: 0000000000000000 FS: 0000000001821380(0000) GS:ffff88846fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f74fc550008 CR3: 000000010a6fe000 CR4: 0000000000350ea0 Call Trace: <TASK> injectpendingevent+0x2f7/0x4c0 [kvm] kvmarchvcpuioctlrun+0x791/0x17a0 [kvm] kvmvcpuioctl+0x26d/0x650 [kvm] x64sysioctl+0x82/0xb0 dosyscall64+0x3b/0xc0 entrySYSCALL64afterhwframe+0x44/0xae </TASK>

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

KVM: nSVM: Avoid clearing VMCBLBR in vmcb12

svmcopylbrs() always marks VMCBLBR dirty in the destination VMCB. However, nestedsvmvmexit() uses it to copy LBRs to vmcb12, and clearing clean bits in vmcb12 is not architecturally defined.

Move vmcbmarkdirty() to callers and drop it for vmcb12.

This also facilitates incoming refactoring that does not pass the entire VMCB to svmcopylbrs().

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

tty: ngsm: fix deadlock and link starvation in outgoing data path

The current implementation queues up new control and user packets as needed and processes this queue down to the ldisc in the same code path. That means that the upper and the lower layer are hard coupled in the code. Due to this deadlocks can happen as seen below while transmitting data, especially during ldisc congestion. Furthermore, the data channels starve the control channel on high transmission load on the ldisc.

Introduce an additional control channel data queue to prevent timeouts and link hangups during ldisc congestion. This is being processed before the user channel data queue in gsmdatakick(), i.e. with the highest priority. Put the queue to ldisc data path into a workqueue and trigger it whenever new data has been put into the transmission queue. Change gsmdlcidatasweep() accordingly to fill up the transmission queue until TXTHRESHHI. This solves the locking issue, keeps latency low and provides good performance on high data load. Note that now all packets from a DLCI are removed from the internal queue if the associated DLCI was closed. This ensures that no data is sent by the introduced write task to an already closed DLCI.

BUG: spinlock recursion on CPU#0, testv24loop/124 lock: serial8250ports+0x3a8/0x7500, .magic: dead4ead, .owner: testv24loop/124, .ownercpu: 0 CPU: 0 PID: 124 Comm: testv24loop Tainted: G O 5.18.0-rc2 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <IRQ> dumpstacklvl+0x34/0x44 dorawspinlock+0x76/0xa0 rawspinlockirqsave+0x72/0x80 uartwriteroom+0x3b/0xc0 gsmdatakick+0x14b/0x240 [ngsm] gsmldwritewakeup+0x35/0x70 [ngsm] ttywakeup+0x53/0x60 ttyportdefaultwakeup+0x1b/0x30 serial8250txchars+0x12f/0x220 serial8250handleirq.part.0+0xfe/0x150 serial8250defaulthandleirq+0x48/0x80 serial8250interrupt+0x56/0xa0 handleirqeventpercpu+0x78/0x1f0 handleirqevent+0x34/0x70 handlefasteoiirq+0x90/0x1e0 commoninterrupt+0x69/0x100 commoninterrupt+0x48/0xc0 asmcommoninterrupt+0x1e/0x40 RIP: 0010:dosoftirq+0x83/0x34e Code: 2a 0a ff 0f b7 ed c7 44 24 10 0a 00 00 00 48 c7 c7 51 2a 64 82 e8 2d e2 d5 ff 65 66 c7 05 83 af 1e 7e 00 00 fb b8 ff ff ff ff <49> c7 c2 40 61 80 82 0f bc c5 41 89 c4 41 83 c4 01 0f 84 e6 00 00 RSP: 0018:ffffc90000003f98 EFLAGS: 00000286 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff82642a51 RDI: ffffffff825bb5e7 RBP: 0000000000000200 R08: 00000008de3271a8 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000030 R14: 0000000000000000 R15: 0000000000000000 ? dosoftirq+0x73/0x34e irqexitrcu+0xb5/0x100 commoninterrupt+0xa4/0xc0 </IRQ> <TASK> asmcommoninterrupt+0x1e/0x40 RIP: 0010:rawspinunlockirqrestore+0x2e/0x50 Code: 00 55 48 89 fd 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 85 28 36 ff 48 89 ef e8 cd 58 36 ff 80 e7 02 74 01 fb bf 01 00 00 00 <e8> 3d 97 33 ff 65 8b 05 96 23 2b 7e 85 c0 74 03 5b 5d c3 0f 1f 44 RSP: 0018:ffffc9000020fd08 EFLAGS: 00000202 RAX: 0000000000000000 RBX: 0000000000000246 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffffffff8257fd74 RDI: 0000000000000001 RBP: ffff8880057de3a0 R08: 00000008de233000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000100 R14: 0000000000000202 R15: ffff8880057df0b8 ? rawspinunlockirqrestore+0x23/0x50 gsmttywrite+0x65/0x80 [ngsm] nttywrite+0x33f/0x530 ? swakeupall+0xe0/0xe0 filettywrite.constprop.0+0x1b1/0x320 ? nttyflushbuffer+0xb0/0xb0 newsyncwrite+0x10c/0x190 vfswrite+0x282/0x310 ksyswrite+0x68/0xe0 dosyscall64+0x3b/0x90 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x7f3e5e35c15c Code: 8b 7c 24 08 89 c5 e8 c5 ff ff ff 89 ef 89 44 24 ---truncated---

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

nfsd: fix RELEASELOCKOWNER

The Linux kernel CVE team has assigned CVE-2024-26629 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/20240313140155.1913910-4-lee@kernel.org/T

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

xen/gntdev: Prevent leaking grants

Prior to this commit, if a grant mapping operation failed partially, some of the entries in the mapops array would be invalid, whereas all of the entries in the kmapops array would be valid. This in turn would cause the following logic in gntdevmapgrantpages to become invalid:

for (i = 0; i < map->count; i++) { if (map->mapops[i].status == GNTSTokay) { map->unmapops[i].handle = map->mapops[i].handle; if (!useptemod) alloced++; } if (useptemod) { if (map->kmapops[i].status == GNTSTokay) { if (map->mapops[i].status == GNTSTokay) alloced++; map->kunmapops[i].handle = map->kmapops[i].handle; } } } ... atomicadd(alloced, &map->livegrants);

Assume that useptemod is true (i.e., the domain mapping the granted pages is a paravirtualized domain). In the code excerpt above, note that the "alloced" variable is only incremented when both kmapops[i].status and mapops[i].status are set to GNTSTokay (i.e., both mapping operations are successful). However, as also noted above, there are cases where a grant mapping operation fails partially, breaking the assumption of the code excerpt above.

The aforementioned causes map->livegrants to be incorrectly set. In some cases, all of the mapops mappings fail, but all of the kmapops mappings succeed, meaning that livegrants may remain zero. This in turn makes it impossible to unmap the successfully grant-mapped pages pointed to by kmapops, because unmapgrantpages has the following snippet of code at its beginning:

if (atomicread(&map->livegrants) == 0) return; / Nothing to do /

In other cases where only some of the mapops mappings fail but all kmapops mappings succeed, livegrants is made positive, but when the user requests unmapping the grant-mapped pages, unmapgrantpagesdone will then make map->livegrants negative, because the latter function does not check if all of the pages that were requested to be unmapped were actually unmapped, and the same function unconditionally subtracts "data->count" (i.e., a value that can be greater than map->livegrants) from map->livegrants. The side effects of a negative livegrants value have not been studied.

The net effect of all of this is that grant references are leaked in one of the above conditions. In Qubes OS v4.1 (which uses Xen's grant mechanism extensively for X11 GUI isolation), this issue manifests itself with warning messages like the following to be printed out by the Linux kernel in the VM that had granted pages (that contain X11 GUI window data) to dom0: "g.e. 0x1234 still pending", especially after the user rapidly resizes GUI VM windows (causing some grant-mapping operations to partially or completely fail, due to the fact that the VM unshares some of the pages as part of the window resizing, making the pages impossible to grant-map from dom0).

The fix for this issue involves counting all successful mapops and kmapops mappings separately, and then adding the sum to livegrants. During unmapping, only the number of successfully unmapped grants is subtracted from livegrants. The code is also modified to check for negative livegrants values after the subtraction and warn the user.

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

drm/meson: encoderhdmi: Fix refcount leak in mesonencoderhdmiinit

ofgraphgetremotenode() returns remote device nodepointer with refcount incremented, we should use ofnodeput() on it when done. Add missing ofnodeput() to avoid refcount leak.

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

drm/msm/mdp5: Fix global state lock backoff

We need to grab the lock after the early return for !hwpipe case. Otherwise, we could have hit contention yet still returned 0.

Fixes an issue that the new CONFIGDRMDEBUGMODESETLOCK stuff flagged in CI:

WARNING: CPU: 0 PID: 282 at drivers/gpu/drm/drmmodesetlock.c:296 drmmodesetlock+0xf8/0x154 Modules linked in: CPU: 0 PID: 282 Comm: kmscursorlega Tainted: G W 5.19.0-rc2-15930-g875cc8bc536a #1 Hardware name: Qualcomm Technologies, Inc. DB820c (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drmmodesetlock+0xf8/0x154 lr : drmatomicgetprivateobjstate+0x84/0x170 sp : ffff80000cfab6a0 x29: ffff80000cfab6a0 x28: 0000000000000000 x27: ffff000083bc4d00 x26: 0000000000000038 x25: 0000000000000000 x24: ffff80000957ca58 x23: 0000000000000000 x22: ffff000081ace080 x21: 0000000000000001 x20: ffff000081acec18 x19: ffff80000cfabb80 x18: 0000000000000038 x17: 0000000000000000 x16: 0000000000000000 x15: fffffffffffea0d0 x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 5f534b434f4c5f47 x11: ffff80000a386aa8 x10: 0000000000000029 x9 : ffff80000cfab610 x8 : 0000000000000029 x7 : 0000000000000014 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff8000081ad904 x3 : 0000000000000029 x2 : ffff0000801db4c0 x1 : ffff80000cfabb80 x0 : ffff000081aceb58 Call trace: drmmodesetlock+0xf8/0x154 drmatomicgetprivateobjstate+0x84/0x170 mdp5getglobalstate+0x54/0x6c mdp5piperelease+0x2c/0xd4 mdp5planeatomiccheck+0x2ec/0x414 drmatomichelpercheckplanes+0xd8/0x210 drmatomichelpercheck+0x54/0xb0 ... ---[ end trace 0000000000000000 ]--- drmmodesetlock attempting to lock a contended lock without backoff: drmmodesetlock+0x148/0x154 mdp5getglobalstate+0x30/0x6c mdp5piperelease+0x2c/0xd4 mdp5planeatomiccheck+0x290/0x414 drmatomichelpercheckplanes+0xd8/0x210 drmatomichelpercheck+0x54/0xb0 drmatomiccheckonly+0x4b0/0x8f4 drmatomiccommit+0x68/0xe0

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

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

kunit: executor: Fix a memory leak on failure in kunitfiltertests

It's possible that memory allocation for 'filtered' will fail, but for the copy of the suite to succeed. In this case, the copy could be leaked.

Properly free 'copy' in the error case for the allocation of 'filtered' failing.

Note that there may also have been a similar issue in kunitfiltersubsuites, before it was removed in "kunit: flatten kunitsuite to kunitsuite in .kunittestsuites".

This was reported by clang-analyzer via the kernel test robot, here: https://lore.kernel.org/all/c8073b8e-7b9e-0830-4177-87c12f16349c@intel.com/

And by smatch via Dan Carpenter and the kernel test robot: https://lore.kernel.org/all/202207101328.ASjx88yj-lkp@intel.com/

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

mtd: partitions: Fix refcount leak in parseredbootof

ofgetchildbyname() returns a node pointer with refcount incremented, we should use ofnodeput() on it when not need anymore. Add missing ofnodeput() to avoid refcount leak.

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

staging: fbtft: core: set smemlen before fbdeferredioinit call

The fbtftframebufferalloc() calls fbdeferredioinit() before initializing info->fix.smemlen. It is set to zero by the framebufferalloc() function. It will trigger a WARNON() at the start of fbdeferredioinit() and the function will not do anything.

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

powerpc/perf: Optimize clearing the pending PMI and remove WARNON for PMI check in powerpmudisable

commit 2c9ac51b850d ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") added a new function "pmiirqpending" in hwirq.h. This function is to check if there is a PMI marked as pending in Paca (PACAIRQPMI).This is used in powerpmudisable in a WARNON. The intention here is to provide a warning if there is PMI pending, but no counter is found overflown.

During some of the perf runs, below warning is hit:

WARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 powerpmudisable+0x25c/0x2c0 Modules linked in: -----

NIP [c000000000141c3c] powerpmudisable+0x25c/0x2c0 LR [c000000000141c8c] powerpmudisable+0x2ac/0x2c0 Call Trace: [c000000baffcfb90] [c000000000141c8c] powerpmudisable+0x2ac/0x2c0 (unreliable) [c000000baffcfc10] [c0000000003e2f8c] perfpmudisable+0x4c/0x60 [c000000baffcfc30] [c0000000003e3344] groupschedout.part.124+0x44/0x100 [c000000baffcfc80] [c0000000003e353c] perfeventdisable+0x13c/0x240 [c000000baffcfcd0] [c0000000003dd334] eventfunction+0xc4/0x140 [c000000baffcfd20] [c0000000003d855c] remotefunction+0x7c/0xa0 [c000000baffcfd50] [c00000000026c394] flushsmpcallfunctionqueue+0xd4/0x300 [c000000baffcfde0] [c000000000065b24] smpipidemuxrelaxed+0xa4/0x100 [c000000baffcfe20] [c0000000000cb2b0] xivemuxedipiaction+0x20/0x40 [c000000baffcfe40] [c000000000207c3c] handleirqeventpercpu+0x8c/0x250 [c000000baffcfee0] [c000000000207e2c] handleirqeventpercpu+0x2c/0xa0 [c000000baffcff10] [c000000000210a04] handlepercpuirq+0x84/0xc0 [c000000baffcff40] [c000000000205f14] generichandleirq+0x54/0x80 [c000000baffcff60] [c000000000015740] doirq+0x90/0x1d0 [c000000baffcff90] [c000000000016990] doIRQ+0xc0/0x140 [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8 [c0000009732f39d0] [c000000000016b78] doIRQ+0x168/0x1c0 [c0000009732f3a00] [c0000000000090c8] hardwareinterruptcommonvirt+0x218/0x220

This means that there is no PMC overflown among the active events in the PMU, but there is a PMU pending in Paca. The function "anypmcoverflown" checks the PMCs on active events in cpuhw->nevents. Code snippet:

<<>> if (anypmcoverflown(cpuhw)) clearpmiirqpending(); else WARNON(pmiirqpending()); <<>>

Here the PMC overflown is not from active event. Example: When we do perf record, default cycles and instructions will be running on PMC6 and PMC5 respectively. It could happen that overflowed event is currently not active and pending PMI is for the inactive event. Debug logs from traceprintk:

<<>> anypmcoverflown: idx is 5: pmc value is 0xd9a powerpmudisable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011 <<>>

Here active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011). When we handle PMI interrupt for such cases, if the PMC overflown is from inactive event, it will be ignored. Reference commit: commit bc09c219b2e6 ("powerpc/perf: Fix finding overflowed PMC in interrupt")

Patch addresses two changes: 1) Fix 1 : Removal of warning ( WARNON(pmiirqpending()); ) We were printing warning if no PMC is found overflown among active PMU events, but PMI pending in PACA. But this could happen in cases where PMC overflown is not in active PMC. An inactive event could have caused the overflow. Hence the warning is not needed. To know pending PMI is from an inactive event, we need to loop through all PMC's which will cause more SPR reads via mfspr and increase in context switch. Also in existing function: perfeventinterrupt, already we ignore PMI's overflown when it is from an inactive PMC.

2) Fix 2: optimization in clearing pending PMI. Currently we check for any active PMC overflown before clearing PMI pending in Paca. This is causing additional SP ---truncated---

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

watchdog: sp5100tco: Fix a memory leak of EFCH MMIO resource

Unlike releasememregion(), a call to releaseresource() does not free the resource, so it has to be freed explicitly to avoid a memory leak.

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

ice: Fix call trace with null VSI during VF reset

During stress test with attaching and detaching VF from KVM and simultaneously changing VFs spoofcheck and trust there was a call trace in iceresetvf that VF's VSI is null.

[145237.352797] WARNING: CPU: 46 PID: 840629 at drivers/net/ethernet/intel/ice/icevflib.c:508 iceresetvf+0x3d6/0x410 [ice] [145237.352851] Modules linked in: ice(E) vfiopci vfiopcicore vfiovirqfd vfioiommutype1 vfio iavf dmmod xtCHECKSUM xtMASQUERADE xtconntrack iptREJECT nfrejectipv4 nftcompat nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 nftables nfnetlink tun bridge stp llc sunrpc intelraplmsr intelraplcommon sbedac x86pkgtempthermal intelpowerclamp coretemp kvmintel kvm iTCOwdt iTC Ovendorsupport irqbypass crct10difpclmul crc32pclmul ghashclmulniintel rapl ipmisi intelcstate ipmidevintf joydev inteluncore m eime ipmimsghandler i2ci801 pcspkr mei lpcich ioatdma i2csmbus acpipad acpipowermeter iptables xfs libcrc32c i2calgobit drmsh memhelper drmkmshelper sdmod t10pi crc64rocksoft syscopyarea crc64 sysfillrect sg sysimgblt fbsysfops drm i40e ixgbe ahci libahci libata crc32cintel mdio dca wmi fuse [last unloaded: ice] [145237.352917] CPU: 46 PID: 840629 Comm: kworker/46:2 Tainted: G S W I E 5.19.0-rc6+ #24 [145237.352921] Hardware name: Intel Corporation S2600WTT/S2600WTT, BIOS SE5C610.86B.01.01.0008.021120151325 02/11/2015 [145237.352923] Workqueue: ice iceservicetask [ice] [145237.352948] RIP: 0010:iceresetvf+0x3d6/0x410 [ice] [145237.352984] Code: 30 ec f3 cc e9 28 fd ff ff 0f b7 4b 50 48 c7 c2 48 19 9c c0 4c 89 ee 48 c7 c7 30 fe 9e c0 e8 d1 21 9d cc 31 c0 e9 a 9 fe ff ff <0f> 0b b8 ea ff ff ff e9 c1 fc ff ff 0f 0b b8 fb ff ff ff e9 91 fe [145237.352987] RSP: 0018:ffffb453e257fdb8 EFLAGS: 00010246 [145237.352990] RAX: ffff8bd0040181c0 RBX: ffff8be68db8f800 RCX: 0000000000000000 [145237.352991] RDX: 000000000000ffff RSI: 0000000000000000 RDI: ffff8be68db8f800 [145237.352993] RBP: ffff8bd0040181c0 R08: 0000000000001000 R09: ffff8bcfd520e000 [145237.352995] R10: 0000000000000000 R11: 00008417b5ab0bc0 R12: 0000000000000005 [145237.352996] R13: ffff8bcee061c0d0 R14: ffff8bd004019640 R15: 0000000000000000 [145237.352998] FS: 0000000000000000(0000) GS:ffff8be5dfb00000(0000) knlGS:0000000000000000 [145237.353000] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [145237.353002] CR2: 00007fd81f651d68 CR3: 0000001a0fe10001 CR4: 00000000001726e0 [145237.353003] Call Trace: [145237.353008] <TASK> [145237.353011] iceprocessvflrevent+0x8d/0xb0 [ice] [145237.353049] iceservicetask+0x79f/0xef0 [ice] [145237.353074] processonework+0x1c8/0x390 [145237.353081] ? processonework+0x390/0x390 [145237.353084] workerthread+0x30/0x360 [145237.353087] ? processonework+0x390/0x390 [145237.353090] kthread+0xe8/0x110 [145237.353094] ? kthreadcompleteandexit+0x20/0x20 [145237.353097] retfromfork+0x22/0x30 [145237.353103] </TASK>

Remove WARNON() from check if VSI is null in iceresetvf. Add "VF is already removed\n" in devdbg().

This WARNON() is unnecessary and causes call trace, despite that call trace, driver still works. There is no need for this warn because this piece of code is responsible for disabling VF's Tx/Rx queues when VF is disabled, but when VF is already removed there is no need to do reset or disable queues.

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

btrfs: fix transaction abort on file creation due to name hash collision

If we attempt to create several files with names that result in the same hash, we have to pack them in same dir item and that has a limit inherent to the leaf size. However if we reach that limit, we trigger a transaction abort and turns the filesystem into RO mode. This allows for a malicious user to disrupt a system, without the need to have administration privileges/capabilities.

Reproducer:

$ cat exploit-hash-collisions.sh #!/bin/bash

DEV=/dev/sdi MNT=/mnt/sdi

# Use smallest node size to make the test faster and require fewer file # names that result in hash collision. mkfs.btrfs -f --nodesize 4K $DEV mount $DEV $MNT

# List of names that result in the same crc32c hash for btrfs. declare -a names=( 'foobar' '%a8tYkxfGMLWRGr55QSeQc4PBNH9PCLIvR6jZnkDtUUru1t@RouaUeL:@xGkbO3nCwvLNYeK9vhE628gss:T$yZjZ5l-Nbd6CbC$M=hqE-ujhJICXyIxBvYrIU9-TDC' 'AQci3EUB%shMsg-N%frgU:02ByLs=IPJU0OpgiWit5nexSyxZDncY6WB:=zKZuk5Zy0DD$Ua78%MelgBuMqaHGyKsJUFf9s=UW80PcJmKctb46KveLSiUtNmqrMiL9-Y0Il5Fnam04CGIg=8@U:Z' 'CvVqJpJzueKcuA$wqwePfyu7VxuWNN3ho$p0zi2H8QFYK$7YlEqOhhb%:hHgjhIjW5vnqWHKNP4' 'ET:vk@rFU4tsvMB0$Cp=xQHaYZjvoF%-BTc%wkFW8yaDAPcCYoR%x$FH5O:' 'HwTon%v7SGSP4FE08jBwwiu5aot2CFKXHTeEAa@38fUcNGOWvE@Mz6WBeDHVooaZ6AgsXPkVGwy9l@@ZbNXabUU9csiWrrOp0MWUdfi$EZ3w9GkIqtz7IeOsByOkBOO' 'Ij%2VlFGXSuPvxJGf5UWy6O@1svxGha%b@=%wjkq:CIgE6u7eJOjmQY5qTtxE2Rjbis9@us' 'KBkjG5%9R8K9sOG8UTnAYjxLNAvBmvV5vz3IiZaPmKuLYO03-6asI9lJj4@6Xo$KZicaLWJ3Pv8XEwVeUPMwbHYWwbx0pYvNlGMO9F:ZhHAwyctnGy%eujl%WPd4U2BI7qooOSr85J-C2V$LfY' 'NcRfDfuUQ2=zP8K3CCF5dFcpfiOm6mwenShsAbF%n6GAGC7fT2JFFn:c35X-3aYwoq7jNX5$ZJ6hI3wnZs$7KgGi7wjulffhHNUxAT0fRRLF39vJ@NvaEMxsMO' 'Oj42AQAEzRoTxa5OuSKIr=AlwGMy132v4g3Pdq1GvUG9874YseIFQ6QU' 'Ono7avN5GjC:6dBJ' 'WHmN2gnmaN-9dVDy4aWo:yNGFzz8qsJyJhWEWcud7$QzN2D9R0efIWWEdu5kwWr73NZm4=@CoCDxrrZnRITr-kGtUcfW2:%2am' 'WiFnuTEhAG9FEC6zopQmj-A-$LDQ0T3WULz%ox3UZAPybSV6v1Z$b4LXBi4M4BMBtJZpz93r9xafpB77r:lbwvitWRyo$odnAUYlYMmU4RvgnNd--e=I5hiEjGLETTtaScWlQp8mYsBovZwM2k' 'XKyH=OsOAF3p%uziGFZVr$ivrvhVgD@1u%5RtrV-glvqAwHkK@x7YwlxX3qT6WKKQ%PR56NrUBU2dOAOAdzr2=5nJuKPM-T-$ZpQfCL7phxQbUcb:BZOTPaFExc-qK-gDRCDW2' 'd3uUR6OFEwZr%ns1XH@tbxA@cCPmbBRLdyh7p6V45H$P2$F%w0RqrD3M0g8aGvWpoTFMiBdOTJXjD:JF7=h9a43xBywYAP%r$SPZi%zDg%ql-KvkdUCtF9OLaQlxmd' 'ePTpbnit%hyNm@WELlpKzNZYOzOTf8EQ$sEfkMy1VOfIUu3coyvIr13-Y7Sv5v-Ivax2GoGQRFMU1b3362nktT9WOJf3SpT%z8sZmM3gvYQBDgmKI%%RM-G7hyrhgYflOw%z::ZRcv5O:lDCFm' 'evqk743Y@dvZAiG5J05LROFV@$2%rVWJ2%3nxV72-W7$e$-SK3tuSHA2mBt$qloC5jwNx33GmQUjD%akhBPu=VJ5g$xhlZiaFtTrjeeM5x7dt4cHpX0cZkmfImndYzGmvwQG:$euFYmXn$2rA9mKZ' 'gkgUtnihWXsZQTEkrMAWIxir09k3t7jkIK25t1:cy1XWN0GGqC%FrySdcmU7M8MuPOppkLw3=Dfr0UuBAL4%GFk2$Ma10V1jDRGJje%Xx9EV2ERaWKtjpwiZwh0gCSJsj5UL7CR8RtW5opCVFKGGy8Cky' 'hNgsG8lNRik3PvphqPm0yEH3P%%fYG:kQLY=6O-61Wa6nrVWVGR6TLB09vHOv%g4VQRP8Gzx7VXUY1qvZyS' 'isA7JVzN12xCxVPJZqoLm-pTBuhjjHMvV7o=F:EaClfYNyFGlsfw-Kf%uxdqW-kwk1sPl2vhbjyHU1A6$hz' 'kiJfgcdZFDiOptjgH5PN9-PSyLO4fbk:u52tz35lViXiJ6cx7pwjTtKy-XGaQ5IefmpJ4NZqGsqCsKuqOOBgf9LkUdffHet@Wu' 'lvwtxyhE9:%Q3UxeHiViUyNzJsy:fm38pgb6s25JvdhOAT=1s0$pG25x=LZ2rlHTszj=gN6M4zHZYrqrB49i=pA--@WqWLIuX7o1SSfS@2FSiUZN' 'rC24cw3UBDZ=5qJBUMs9e$=S4Y94ni%Z8639vnrGp=0Hv4z3dNFL0fBLmQ40=EYIY:Z=SLc@QLMSt2zsss2ZXrP7j4=' 'uwGl2s-fFrf@GqS=DQqq2I0LJSsOmM%xzTjS:lzXguE3wChdMoHYtLRKPvfaPOZF2fER@j53evbKa7R%A7r4%YEkD=kicJe@SFiGtXHbKe4gCgPAYbnVn' 'UG37U6KKua2bgc:IHzRs7BnB6FD:2Mt5Cc5NdlsW%$1tyvnfz7S27FvNkroXwAW:mBZLA1@qa9WnDbHCDmQmfPMC9z-Eq6QT0jhhPpqyymaD:R02ghwYo%yx7SAaaq-:x33LYpei$5g8DMl3C' 'y2vjek0FE1PDJC0qpfnN:x8k2wCFZ9xiUF2ege=JnP98R%wxjKkdfEiLWvQzmnW' '8-HCSgH5B%K7P8jaVtQhBXpBk:pE-$P7ts58U0J@iR9YZntMPl7j$s62yAJO@9eanFPS54b=UTw$94C-t=HLxT8n6o9P=QnIxq-f1=Ne2dvhe6WbjEQtc' 'YPPh:IFt2mtR6XWSmjHptXLhbSYu8bMw-JP8@PNyaFkdNFsk$M=xfL6LDKCDM-mSyGA2MBwZ8Dr4=R1D%7-mC ---truncated---

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

misc: bcmvk: Fix possible null-pointer dereferences in bcmvkread()

In the function bcmvkread(), the pointer entry is checked, indicating that it can be NULL. If entry is NULL and rc is set to -EMSGSIZE, the following code may cause null-pointer dereferences:

struct vkmsgblk tmpmsg = entry->tohmsg[0]; setmsgid(&tmpmsg, entry->usrmsgid); tmpmsg.size = entry->tohblks - 1;

To prevent these possible null-pointer dereferences, copy tohmsg, usrmsgid, and tohblks from iter into temporary variables, and return these temporary variables to the application instead of accessing them through a potentially NULL entry.

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

net/sched: actskbedit: fix divide-by-zero in tcfskbedithash()

Commit 38a6f0865796 ("net: sched: support hash selecting tx queue") added SKBEDITFTXQSKBHASH support. The inclusive range size is computed as:

mappingmod = queuemappingmax - queuemapping + 1;

The range size can be 65536 when the requested range covers all possible u16 queue IDs (e.g. queuemapping=0 and queuemappingmax=U16MAX). That value cannot be represented in a u16 and previously wrapped to 0, so tcfskbedithash() could trigger a divide-by-zero:

queuemapping += skbgethash(skb) % params->mappingmod;

Compute mappingmod in a wider type and reject ranges larger than U16MAX to prevent params->mappingmod from becoming 0 and avoid the crash.

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

net/mlx5: lag: Check for LAG device before creating debugfs

mlx5lagdevaddmdev() may return 0 (success) even when an error occurs that is handled gracefully. Consequently, the initialization flow proceeds to call mlx5ldevadddebugfs() even when there is no valid LAG context.

mlx5ldevadddebugfs() blindly created the debugfs directory and attributes. This exposed interfaces (like the members file) that rely on a valid ldev pointer, leading to potential NULL pointer dereferences if accessed when ldev is NULL.

Add a check to verify that mlx5lagdev(dev) returns a valid pointer before attempting to create the debugfs entries.

EDAC/mc: Fix error path ordering in edacmcalloc()