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

module: decompress: check return value of moduleextendmaxpages()

moduleextendmaxpages() calls kvrealloc() internally and returns -ENOMEM on allocation failure. The return value is never checked.

If the initial allocation fails, info->pages remains NULL and info->maxpages remains 0. Subsequent calls to modulegetnextpage() will attempt to dynamically grow the array by calling moduleextendmaxpages(info, 0) since info->usedpages is 0. This results in kvrealloc(NULL, 0) returning ZEROSIZEPTR, which is treated as a success, leading to a dereference of ZEROSIZEPTR and a kernel oops.

Fix: add the missing error check after moduleextendmaxpages() and return immediately on failure. This matches the pattern used by every other kvrealloc() caller in the module loading path.

[Sami: Corrected the analysis in the commit message.]

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

erofs: fix metabuf leak in inode xattr initialization

commit bb88e8da0025 ("erofs: use meta buffers for xattr operations") converted xattr operations to use on-stack erofsbuf instances. erofsinitinodexattrs() uses such a metabuf while reading the inline xattr header and shared xattr id array.

Some error paths after erofsreadmetabuf() leave through outunlock without dropping the metabuf, so the folio reference can leak.

Consolidate the cleanup at outunlock. erofsputmetabuf() is a no-op if no folio has been acquired, and this keeps all paths after taking EROFSIBLXATTRBIT covered by a single cleanup site.

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

nfsd: reset write verifier on deferred writeback errors

nfsdvfswrite() and nfsdcommit() both call filemapcheckwberr() to detect deferred writeback errors, but neither rotates the server's write verifier (nn->writeverf) when this check fails. Every other durable-storage-failure path in these functions calls commitresetwriteverifier() before returning an error.

The missing rotation means clients holding UNSTABLE write data under the current verifier will COMMIT, receive the unchanged verifier back, and conclude their data is durable — silently dropping data that failed writeback. This violates the UNSTABLE+COMMIT durability contract (RFC 1813 §3.3.7, RFC 8881 §18.32).

Add commitresetwriteverifier() calls at both filemapcheckwberr() error sites, matching the pattern used by adjacent error paths in the same functions. The helper already filters -EAGAIN and -ESTALE internally, so the calls are unconditionally safe.

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

KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying

When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero. This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN.

For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVMRUN. But if userspace never calls KVMRUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU.

Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nestedvmxfreevcpu() (but for completely unrelated reasons; suppressing WARN from nestedputvmcs12pages() is pure happenstance). But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless.

The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page. But for the VM's refcount to reach zero, there can't be any userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD. I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive. And so since userspace can't possibly reach the dirty ring, whether or not KVM technically "misses" a push to the dirty ring is irrelevant.

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

iio: frequency: admv1013: fix NULL pointer dereference on str

When devicepropertyreadstring() fails, str is left uninitialized but the code falls through to strcmp(str, ...), dereferencing a garbage pointer. Replace manual read/strcmp with devicepropertymatchpropertystring() and consolidate the SE mode enums into a single sequential enum, mapping to hardware register values via a switch consistent with other bitfields in the driver.

Several cleanup patches have been applied to this driver recently so this will need a manual backport.

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

ACPICA: Fix NULL pointer dereference in acpievaddressspacedispatch()

Cover a missed execution path with a new check.

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

scsi: mpi3mr: Add NULL checks when resetting request and reply queues

The driver encountered a crash during resource cleanup when the reply and request queues were NULL due to freed memory. This issue occurred when the creation of reply or request queues failed, and the driver freed the memory first, but attempted to mem set the content of the freed memory, leading to a system crash.

Add NULL pointer checks for reply and request queues before accessing the reply/request memory during cleanup

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

net: qrtr: Drop the MHI autoqueue feature for IPCR DL channels

MHI stack offers the 'autoqueue' feature, which allows the MHI stack to auto queue the buffers for the RX path (DL channel). Though this feature simplifies the client driver design, it introduces race between the client drivers and the MHI stack. For instance, with autoqueue, the 'dlcallback' for the DL channel may get called before the client driver is fully probed. This means, by the time the dlcallback gets called, the client driver's structures might not be initialized, leading to NULL ptr dereference.

Currently, the drivers have to workaround this issue by initializing the internal structures before calling mhipreparefortransferautoqueue(). But even so, there is a chance that the client driver's internal code path may call the MHI queue APIs before mhipreparefortransferautoqueue() is called, leading to similar NULL ptr dereference. This issue has been reported on the Qcom X1E80100 CRD machines affecting boot.

So to properly fix all these races, drop the MHI 'autoqueue' feature altogether and let the client driver (QRTR) manage the RX buffers manually. In the QRTR driver, queue the RX buffers based on the ring length during probe and recycle the buffers in 'dlcallback' once they are consumed. This also warrants removing the setting of 'autoqueue' flag from controller drivers.

Currently, this 'autoqueue' feature is only enabled for IPCR DL channel. So only the QRTR client driver requires the modification.

HID: magicmouse: avoid memory leak in magicmousereportfixup()

HID: apple: avoid memory leak in applereportfixup()

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

x86/fpu: Clear XSTATEBV[i] in guest XSAVE state whenever XFD[i]=1

When loading guest XSAVE state via KVMSETXSAVE, and when updating XFD in response to a guest WRMSR, clear XFD-disabled features in the saved (or to be restored) XSTATEBV to ensure KVM doesn't attempt to load state for features that are disabled via the guest's XFD. Because the kernel executes XRSTOR with the guest's XFD, saving XSTATEBV[i]=1 with XFD[i]=1 will cause XRSTOR to #NM and panic the kernel.

E.g. if fpuupdateguestxfd() sets XFD without clearing XSTATEBV:

------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at excdevicenotavailable+0x101/0x110, CPU#29: amxtest/848 Modules linked in: kvmintel kvm irqbypass CPU: 29 UID: 1000 PID: 848 Comm: amxtest Not tainted 6.19.0-rc2-ffa07f7fd437-x86amxnmxfdnoninit-vm #171 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:excdevicenotavailable+0x101/0x110 Call Trace: <TASK> asmexcdevicenotavailable+0x1a/0x20 RIP: 0010:restorefpregsfromfpstate+0x36/0x90 switchfpureturn+0x4a/0xb0 kvmarchvcpuioctlrun+0x1245/0x1e40 [kvm] kvmvcpuioctl+0x2c3/0x8f0 [kvm] x64sysioctl+0x8f/0xd0 dosyscall64+0x62/0x940 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---

This can happen if the guest executes WRMSR(MSRIA32XFD) to set XFD[18] = 1, and a host IRQ triggers kernelfpubegin() prior to the vmexit handler's call to fpuupdateguestxfd().

and if userspace stuffs XSTATEBV[i]=1 via KVMSETXSAVE:

------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at excdevicenotavailable+0x101/0x110, CPU#14: amxtest/867 Modules linked in: kvmintel kvm irqbypass CPU: 14 UID: 1000 PID: 867 Comm: amxtest Not tainted 6.19.0-rc2-2dace9faccd6-x86amxnmxfdnoninit-vm #168 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:excdevicenotavailable+0x101/0x110 Call Trace: <TASK> asmexcdevicenotavailable+0x1a/0x20 RIP: 0010:restorefpregsfromfpstate+0x36/0x90 fpuswapkvmfpstate+0x6b/0x120 kvmloadguestfpu+0x30/0x80 [kvm] kvmarchvcpuioctlrun+0x85/0x1e40 [kvm] kvmvcpuioctl+0x2c3/0x8f0 [kvm] x64sysioctl+0x8f/0xd0 dosyscall64+0x62/0x940 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---

The new behavior is consistent with the AMX architecture. Per Intel's SDM, XSAVE saves XSTATEBV as '0' for components that are disabled via XFD (and non-compacted XSAVE saves the initial configuration of the state component):

If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i, the instruction does not generate #NM when XCR0[i] = IA32XFD[i] = 1; instead, it operates as if XINUSE[i] = 0 (and the state component was in its initial state): it saves bit i of XSTATEBV field of the XSAVE header as 0; in addition, XSAVE saves the initial configuration of the state component (the other instructions do not save state component i).

Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using a constant XFD based on the set of enabled features when XSAVEing for a struct fpuguest. However, having XSTATEBV[i]=1 for XFD-disabled features can only happen in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, because fpuswapkvmfpstate()'s call to savefpregstofpstate() saves the outgoing FPU state with the current XFD; and that is (on all but the first WRMSR to XFD) the guest XFD.

Therefore, XFD can only go out of sync with XSTATEBV in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, and it we can consider it (de facto) part of KVM ABI that KVMGETXSAVE returns XSTATEBV[i]=0 for XFD-disabled features.

[Move clea ---truncated---

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

drivers/perf: hisi: Don't migrate perf to the CPU going to teardown

The driver needs to migrate the perf context if the current using CPU going to teardown. By the time calling the cpuhp::teardown() callback the cpuonlinemask() hasn't updated yet and still includes the CPU going to teardown. In current driver's implementation we may migrate the context to the teardown CPU and leads to the below calltrace:

... [ 368.104662][ T932] task:cpuhp/0 state:D stack: 0 pid: 15 ppid: 2 flags:0x00000008 [ 368.113699][ T932] Call trace: [ 368.116834][ T932] switchto+0x7c/0xbc [ 368.120924][ T932] schedule+0x338/0x6f0 [ 368.125098][ T932] schedule+0x50/0xe0 [ 368.128926][ T932] schedulepreemptdisabled+0x18/0x24 [ 368.134229][ T932] mutexlock.constprop.0+0x1d4/0x5dc [ 368.139617][ T932] mutexlockslowpath+0x1c/0x30 [ 368.144573][ T932] mutexlock+0x50/0x60 [ 368.148579][ T932] perfpmumigratecontext+0x84/0x2b0 [ 368.153884][ T932] hisipciepmuofflinecpu+0x90/0xe0 [hisipciepmu] [ 368.160579][ T932] cpuhpinvokecallback+0x2a0/0x650 [ 368.165707][ T932] cpuhpthreadfun+0xe4/0x190 [ 368.170316][ T932] smpbootthreadfn+0x15c/0x1a0 [ 368.175099][ T932] kthread+0x108/0x13c [ 368.179012][ T932] retfromfork+0x10/0x18 ...

Use function cpumaskanybut() to find one correct active cpu to fixes this issue.

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

dmaengine: qcom-adm: fix wrong sizeof config in slaveconfig

Fix broken slaveconfig function that uncorrectly compare the peripheralsize with the size of the config pointer instead of the size of the config struct. This cause the crci value to be ignored and cause a kernel panic on any slave that use adm driver.

To fix this, compare to the size of the struct and NOT the size of the pointer.

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

cifs: Release folio lock on fscache read hit.

Under the current code, when cifsreadpageworker is called, the call contract is that the callee should unlock the page. This is documented in the readfolio section of Documentation/filesystems/vfs.rst as:

The filesystem should unlock the folio once the read has completed, whether it was successful or not.

Without this change, when fscache is in use and cache hit occurs during a read, the page lock is leaked, producing the following stack on subsequent reads (via mmap) to the page:

$ cat /proc/3890/task/12864/stack [<0>] foliowaitbitcommon+0x124/0x350 [<0>] filemapreadfolio+0xad/0xf0 [<0>] filemapfault+0x8b1/0xab0 [<0>] dofault+0x39/0x150 [<0>] dofault+0x25c/0x3e0 [<0>] handlemmfault+0x6ca/0xc70 [<0>] handlemmfault+0xe9/0x350 [<0>] douseraddrfault+0x225/0x6c0 [<0>] excpagefault+0x84/0x1b0 [<0>] asmexcpagefault+0x27/0x30

This requires a reboot to resolve; it is a deadlock.

Note however that the call to cifsreadpagefromfscache does mark the page clean, but does not free the folio lock. This happens in cifsreadpagefromfscache on success. Releasing the lock at that point however is not appropriate as cifsreadahead also calls cifsreadpagefromfscache and does unconditionally release the lock after its return. This change therefore effectively makes cifsreadpageworker work like cifsreadahead.

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

rcu-tasks: Avoid prinfo() with spin lock in cblistinitgeneric()

prinfo() is called with rtp->cbsgbllock spin lock locked. Because prinfo() calls printk() that might sleep, this will result in BUG like below:

[ 0.206455] cblistinitgeneric: Setting adjustable number of callback queues. [ 0.206463] [ 0.206464] ============================= [ 0.206464] [ BUG: Invalid wait context ] [ 0.206465] 5.19.0-00428-g9de1f9c8ca51 #5 Not tainted [ 0.206466] ----------------------------- [ 0.206466] swapper/0/1 is trying to lock: [ 0.206467] ffffffffa0167a58 (&portlockkey){....}-{3:3}, at: serial8250consolewrite+0x327/0x4a0 [ 0.206473] other info that might help us debug this: [ 0.206473] context-{5:5} [ 0.206474] 3 locks held by swapper/0/1: [ 0.206474] #0: ffffffff9eb597e0 (rcutasks.cbsgbllock){....}-{2:2}, at: cblistinitgeneric.constprop.0+0x14/0x1f0 [ 0.206478] #1: ffffffff9eb579c0 (consolelock){+.+.}-{0:0}, at: printk+0x63/0x7e [ 0.206482] #2: ffffffff9ea77780 (consoleowner){....}-{0:0}, at: consoleemitnextrecord.constprop.0+0x111/0x330 [ 0.206485] stack backtrace: [ 0.206486] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-00428-g9de1f9c8ca51 #5 [ 0.206488] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014 [ 0.206489] Call Trace: [ 0.206490] <TASK> [ 0.206491] dumpstacklvl+0x6a/0x9f [ 0.206493] lockacquire.cold+0x2d7/0x2fe [ 0.206496] ? stacktracesave+0x46/0x70 [ 0.206497] lockacquire+0xd1/0x2f0 [ 0.206499] ? serial8250consolewrite+0x327/0x4a0 [ 0.206500] ? lockacquire+0x5c7/0x2720 [ 0.206502] rawspinlockirqsave+0x3d/0x90 [ 0.206504] ? serial8250consolewrite+0x327/0x4a0 [ 0.206506] serial8250consolewrite+0x327/0x4a0 [ 0.206508] consoleemitnextrecord.constprop.0+0x180/0x330 [ 0.206511] consoleunlock+0xf7/0x1f0 [ 0.206512] vprintkemit+0xf7/0x330 [ 0.206514] printk+0x63/0x7e [ 0.206516] cblistinitgeneric.constprop.0.cold+0x24/0x32 [ 0.206518] rcuinittasksgeneric+0x5/0xd9 [ 0.206522] kernelinitfreeable+0x15b/0x2a2 [ 0.206523] ? restinit+0x160/0x160 [ 0.206526] kernelinit+0x11/0x120 [ 0.206527] retfromfork+0x1f/0x30 [ 0.206530] </TASK> [ 0.207018] cblistinitgeneric: Setting shift to 1 and lim to 1.

This patch moves prinfo() so that it is called without rtp->cbsgbllock locked.

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

mtd: core: Fix refcount error in delmtddevice()

delmtddevice() will call ofnodeput() to mtdgetofnode(mtd), which is mtd->dev.ofnode. However, memset(&mtd->dev, 0) is called before ofnodeput(). As the result, ofnodeput() won't do anything in delmtddevice(), and causes the refcount leak.

delmtddevice() memset(&mtd->dev, 0, sizeof(mtd->dev) # clear mtd->dev ofnodeput() mtdgetofnode(mtd) # mtd->dev is cleared, can't locate ofnode # ofnodeput(NULL) won't do anything

Fix the error by caching the pointer of the devicenode.

OF: ERROR: memory leak, expected refcount 1 instead of 2, ofnodeget()/ofnodeput() unbalanced - destroy cset entry: attach overlay node /spi/spi-sram@0 CPU: 3 PID: 275 Comm: python3 Tainted: G N 6.1.0-rc3+ #54 0d8a1edddf51f172ff5226989a7565c6313b08e2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x67/0x83 kobjectget+0x155/0x160 ofnodeget+0x1f/0x30 offwnodeget+0x43/0x70 fwnodehandleget+0x54/0x80 fwnodegetnthparent+0xc9/0xe0 fwnodefullnamestring+0x3f/0xa0 devicenodestring+0x30f/0x750 pointer+0x598/0x7a0 vsnprintf+0x62d/0x9b0 ... cfsoverlayrelease+0x30/0x90 configitemrelease+0xbe/0x1a0 configitemput+0x5e/0x80 configfsrmdir+0x3bd/0x540 vfsrmdir+0x18c/0x320 dormdir+0x198/0x330 x64sysrmdir+0x2c/0x40 dosyscall64+0x37/0x90 entrySYSCALL64afterhwframe+0x63/0xcd

[<miquel.raynal@bootlin.com>: Light reword of the commit log]

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

ACPI: processor: Check for null return of devmkzalloc() in fchmiscsetup()

devmkzalloc() may fail, clkdata->name might be NULL and will cause a NULL pointer dereference later.

[ rjw: Subject and changelog edits ]

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

mm/vmalloc, mm/kasan: respect gfp mask in kasanpopulatevmalloc()

kasanpopulatevmalloc() and its helpers ignore the caller's gfpmask and always allocate memory using the hardcoded GFPKERNEL flag. This makes them inconsistent with vmalloc(), which was recently extended to support GFPNOFS and GFPNOIO allocations.

Page table allocations performed during shadow population also ignore the external gfpmask. To preserve the intended semantics of GFPNOFS and GFPNOIO, wrap the applytopagerange() calls into the appropriate memalloc scope.

xfs calls vmalloc with GFPNOFS, so this bug could lead to deadlock.

There was a report here https://lkml.kernel.org/r/686ea951.050a0220.385921.0016.GAE@google.com

This patch: - Extends kasanpopulatevmalloc() and helpers to take gfpmask; - Passes gfpmask down to allocpagesbulk() and getfreepage(); - Enforces GFPNOFS/NOIO semantics with memallocsave()/restore() around applytopagerange(); - Updates vmalloc.c and percpu allocator call sites accordingly.

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

drm/msm/dp: add atomiccheck to bridge ops

DRM committails() will disable downstream crtc/encoder/bridge if both disable crtc is required and crtc->active is set before pushing a new frame downstream.

There is a rare case that user space display manager issue an extra screen update immediately followed by close DRM device while down stream display interface is disabled. This extra screen update will timeout due to the downstream interface is disabled but will cause crtc->active be set. Hence the followed committails() called by drmrelease() will pass the disable downstream crtc/encoder/bridge conditions checking even downstream interface is disabled. This cause the crash to happen at dpbridgedisable() due to it trying to access the main link register to push the idle pattern out while main link clocks is disabled.

This patch adds atomiccheck to prevent the extra frame will not be pushed down if display interface is down so that crtc->active will not be set neither. This will fail the conditions checking of disabling down stream crtc/encoder/bridge which prevent drmrelease() from calling dpbridgedisable() so that crash at dpbridgedisable() prevented.

There is no protection in the DRM framework to check if the display pipeline has been already disabled before trying again. The only check is the crtcstate->active but this is controlled by usermode using UAPI. Hence if the usermode sets this and then crashes, the driver needs to protect against double disable.

SError Interrupt on CPU7, code 0x00000000be000411 -- SError CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19 Hardware name: Google Lazor (rev3 - 8) (DT) pstate: a04000c9 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : cmpxchgcaseacq32+0x14/0x2c lr : dorawspinlock+0xa4/0xdc sp : ffffffc01092b6a0 x29: ffffffc01092b6a0 x28: 0000000000000028 x27: 0000000000000038 x26: 0000000000000004 x25: ffffffd2973dce48 x24: 0000000000000000 x23: 00000000ffffffff x22: 00000000ffffffff x21: ffffffd2978d0008 x20: ffffffd2978d0008 x19: ffffff80ff759fc0 x18: 0000000000000000 x17: 004800a501260460 x16: 0441043b04600438 x15: 04380000089807d0 x14: 07b0089807800780 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000438 x10: 00000000000007d0 x9 : ffffffd2973e09e4 x8 : ffffff8092d53300 x7 : ffffff808902e8b8 x6 : 0000000000000001 x5 : ffffff808902e880 x4 : 0000000000000000 x3 : ffffff80ff759fc0 x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffffff80ff759fc0 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19 Hardware name: Google Lazor (rev3 - 8) (DT) Call trace: dumpbacktrace.part.0+0xbc/0xe4 showstack+0x24/0x70 dumpstacklvl+0x68/0x84 dumpstack+0x18/0x34 panic+0x14c/0x32c nmipanic+0x58/0x7c arm64serrorpanic+0x78/0x84 doserror+0x40/0x64 el1h64errorhandler+0x30/0x48 el1h64error+0x68/0x6c cmpxchgcaseacq32+0x14/0x2c rawspinlockirqsave+0x38/0x4c locktimerbase+0x40/0x78 modtimer+0xf4/0x25c scheduletimeout+0xd4/0xfc waitforcommon+0xac/0x140 waitforcompletiontimeout+0x2c/0x54 dpctrlpushidle+0x40/0x88 dpbridgedisable+0x24/0x30 drmatomicbridgechaindisable+0x90/0xbc drmatomichelpercommitmodesetdisables+0x198/0x444 msmatomiccommittail+0x1d0/0x374 committail+0x80/0x108 drmatomichelpercommit+0x118/0x11c drmatomiccommit+0xb4/0xe0 drmclientmodesetcommitatomic+0x184/0x224 drmclientmodesetcommitlocked+0x58/0x160 drmclientmodesetcommit+0x3c/0x64 drmfbhelperrestorefbdevmodeunlocked+0x98/0xac drmfbhelpersetpar+0x74/0x80 drmfbhelperhotplugevent+0xdc/0xe0 drmfbhelperrestorefbdevmodeunlocked+0x7c/0xac drmfbhelperrestorefbdevmodeunlocked+0x20/0x2c drmfbhelperlastclose+0x20/0x2c drmlastclose+0x44/0x6c drmrelease+0x88/0xd4 fput+0x104/0x220 fput+0x1c/0x28 taskworkrun+0x8c/0x100 d ---truncated---

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

mm/mempolicy: fix memory leak in setmempolicyhomenode system call

When encountering any vma in the range with policy other than MPOLBIND or MPOLPREFERREDMANY, an error is returned without issuing a mpolput on the policy just allocated with mpoldup().

This allows arbitrary users to leak kernel memory.

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

of/fdt: run soc memory setup when earlyinitdtscanmemory fails

If memory has been found earlyinitdtscanmemory now returns 1. If it hasn't found any memory it will return 0, allowing other memory setup mechanisms to carry on.

Previously earlyinitdtscanmemory always returned 0 without distinguishing between any kind of memory setup being done or not. Any code path after the earlyinitdtscan memory call in the ramips platmemsetup code wouldn't be executed anymore. Making earlyinitdtscanmemory the only way to initialize the memory.

Some boards, including my mt7621 based Cudy X6 board, depend on memory initialization being done via the socinfo.memdetect function pointer. Those wouldn't be able to obtain memory and panic the kernel during early bootup with the message "earlyinitdtallocmemoryarch: Failed to allocate 12416 bytes align=0x40".

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

wifi: wilc1000: add missing unregisternetdev() in wilcnetdevifcinit()

Fault injection test reports this issue:

kernel BUG at net/core/dev.c:10731! invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI Call Trace: <TASK> wilcnetdevifcinit+0x19f/0x220 [wilc1000 884bf126e9e98af6a708f266a8dffd53f99e4bf5] wilccfg80211init+0x30c/0x380 [wilc1000 884bf126e9e98af6a708f266a8dffd53f99e4bf5] wilcbusprobe+0xad/0x2b0 [wilc1000spi 1520a7539b6589cc6cde2ae826a523a33f8bacff] spiprobe+0xe4/0x140 reallyprobe+0x17e/0x3f0 driverprobedevice+0xe3/0x170 driverprobedevice+0x49/0x120

The root case here is allocorderedworkqueue() fails, but cfg80211unregisternetdevice() or unregisternetdev() not be called in error handling path. To fix add unregisternetdev goto lable to add the unregister operation in error handling path.

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

ubifs: Fix memory leak in ubifssysfsinit()

When insmod ubifs.ko, a kmemleak reported as below:

unreferenced object 0xffff88817fb1a780 (size 8): comm "insmod", pid 25265, jiffies 4295239702 (age 100.130s) hex dump (first 8 bytes): 75 62 69 66 73 00 ff ff ubifs... backtrace: [<ffffffff81b3fc4c>] slabpostallochook+0x9c/0x3c0 [<ffffffff81b44bf3>] kmalloctrackcaller+0x183/0x410 [<ffffffff8198d3da>] kstrdup+0x3a/0x80 [<ffffffff8198d486>] kstrdupconst+0x66/0x80 [<ffffffff83989325>] kvasprintfconst+0x155/0x190 [<ffffffff83bf55bb>] kobjectsetnamevargs+0x5b/0x150 [<ffffffff83bf576b>] kobjectsetname+0xbb/0xf0 [<ffffffff8100204c>] dooneinitcall+0x14c/0x5a0 [<ffffffff8157e380>] doinitmodule+0x1f0/0x660 [<ffffffff815857be>] loadmodule+0x6d7e/0x7590 [<ffffffff8158644f>] dosysfinitmodule+0x19f/0x230 [<ffffffff815866b3>] x64sysfinitmodule+0x73/0xb0 [<ffffffff88c98e85>] dosyscall64+0x35/0x80 [<ffffffff88e00087>] entrySYSCALL64afterhwframe+0x63/0xcd

When ksetregister() failed, we should call ksetput to cleanup it.

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

PCI: hv: Fix a crash in hvpcirestoremsimsg() during hibernation

When a Linux VM with an assigned PCI device runs on Hyper-V, if the PCI device driver is not loaded yet (i.e. MSI-X/MSI is not enabled on the device yet), doing a VM hibernation triggers a panic in hvpcirestoremsimsg() -> msilockdescs(&pdev->dev), because pdev->dev.msi.data is still NULL.

Avoid the panic by checking if MSI-X/MSI is enabled.

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

media: ov8865: Fix an error handling path in ov8865probe()

The commit in Fixes also introduced some new error handling which should goto the existing error handling path. Otherwise some resources leak.

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

parisc: Revise gateway LWS calls to probe user read access

We use load and stbys,e instructions to trigger memory reference interruptions without writing to memory. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel and gateway page execute at privilege level 0, so this code never triggers a read access interruption. Thus, it is currently possible for user code to execute a LWS compare and swap operation at an address that is read protected at privilege level 3 (PRIVUSER).

Fix this by probing read access rights at privilege level 3 and branching to lwsfault if access isn't allowed.

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

drm/tegra: nvdec: Fix dmaalloccoherent error check

Check for NULL return value with dmaalloccoherent, in line with Robin's fix for vic.c in 'drm/tegra: vic: Fix DMA API misuse'.

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

raid10: cleanup memleak at raid10makerequest

If raid10readrequest or raid10writerequest registers a new request and the REQNOWAIT flag is set, the code does not free the malloc from the mempool.

unreferenced object 0xffff8884802c3200 (size 192): comm "fio", pid 9197, jiffies 4298078271 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 88 41 02 00 00 00 00 00 .........A...... 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc c1a049a2): kmalloc+0x2bb/0x450 mempoolalloc+0x11b/0x320 raid10makerequest+0x19e/0x650 [raid10] mdhandlerequest+0x3b3/0x9e0 submitbio+0x394/0x560 submitbionoacct+0x145/0x530 submitbionoacctnocheck+0x682/0x830 blkdevdirectIOasync+0x4dc/0x6b0 blkdevreaditer+0x1e5/0x3b0 ioread+0x230/0x1110 ioread+0x13/0x30 ioissuesqe+0x134/0x1180 iosubmitsqes+0x48c/0xe90 dosysiouringenter+0x574/0x8b0 dosyscall64+0x5c/0xe0 entrySYSCALL64afterhwframe+0x76/0x7e

V4: changing backing tree to see if CKI tests will pass. The patch code has not changed between any versions.

btrfs: handle csum tree error with rescue=ibadroots correctly

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

coresight: holding cscfgcsdevlock while removing cscfg from csdev

There'll be possible race scenario for coresight config:

CPU0 CPU1 (perf enable) load module cscfgloadconfigsets() activate config. // sysfs (sysactivecnt == 1) ... cscfgcsdevenableactiveconfig() lock(csdev->cscfgcsdevlock) deactivate config // sysfs (sysactiveccnt == 0) cscfgunloadconfigsets() <iterating configcsdevlist> cscfgremoveownedcsdevconfigs() // here load config activate by CPU1 unlock(csdev->cscfgcsdevlock)

iterating configcsdevlist could be raced with configcsdevlist's entry delete.

To resolve this race , hold csdev->cscfgcsdevlock() while cscfgremoveownedcsdevconfigs()