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

netfilter: nftfib: fix stale stack leak via the OIFNAME register

For NFTFIBRESULTOIFNAME the destination register is declared with len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail, RTNLOCAL and oif-mismatch paths nftfib{4,6}eval() only writes one register via "dest = 0". The remaining three registers are left as whatever was on the stack in nftdochain()'s struct nftregs, and a downstream expression that loads the register span can leak that uninitialised kernel stack to userspace.

The NFTAFIBFPRESENT existence check has the same shape: it is only meaningful for NFTFIBRESULTOIF, yet it was accepted for any result type while the eval stores a single byte via nftregstore8(), leaving the rest of the declared span stale.

Fix both:

- replace the bare "dest = 0" in the eval with nftfibstoreresult(), which strscpypad()s the whole IFNAMSIZ for OIFNAME (and is already used on the other early-return path), and

- restrict NFTAFIBFPRESENT to NFTFIBRESULTOIF and declare its destination as a single u8, so the marked span matches the one byte the eval writes.

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

tracepoint: balance regfunc() on funcadd() failure in tracepointaddfunc()

When a tracepoint goes through the 0 -> 1 transition, tracepointaddfunc() invokes the subsystem's ext->regfunc() before attempting to install the new probe via funcadd(). If funcadd() then fails (for example, when allocateprobes() cannot allocate a new probe array under memory pressure and returns -ENOMEM), the function returns the error without calling the matching ext->unregfunc(), leaving the side effects of regfunc() behind with no installed probe to justify them.

For syscall tracepoints this is particularly unpleasant: syscallregfunc() bumps systracepointrefcount and sets SYSCALLTRACEPOINT on every task. After a leaked failure, the refcount is stuck at a non-zero value with no consumer, and every task continues paying the syscall trace entry/exit overhead until reboot. Other subsystems providing regfunc()/unregfunc() pairs exhibit similarly scoped persistent state.

Mirror the existing 1 -> 0 cleanup and call ext->unregfunc() in the funcadd() error path, gated on the same condition used there so the unwind is symmetric with the registration.

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

iio: sca3000: Fix a resource leak in sca3000probe()

spi->irq from requestthreadedirq() not released when iiodeviceregister() fails. Add an return value check and jump to a common error handler when iiodeviceregister() fails.

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

iio: gyro: mpu3050-core: fix pmruntime error handling

The return value of pmruntimegetsync() is not checked, allowing the driver to access hardware that may fail to resume. The device usage count is also unconditionally incremented. Use pmruntimeresumeandget() which propagates errors and avoids incrementing the usage count on failure.

In preenable, add pmruntimeputautosuspend() on set8khzsamplerate() failure since postdisable does not run when preenable fails.

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

media: mtk-mdp: Fix a reference leak bug in mtkmdpremove()

In mtkmdpprobe(), vpugetplatdevice() increases the reference count of the returned platform device. Add platformdeviceput() to prevent reference leak.

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

net: macb: properly unregister fixed rate clocks

The additional resources allocated with clkregisterfixedrate() need to be released with clkunregisterfixedrate(), otherwise they are lost.

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

iio: gyro: mpu3050: Fix incorrect freeirq() variable

The handler for the IRQ part of this driver is mpu3050->trig but, in the teardown freeirq() is called with handler mpu3050.

Use correct IRQ handler when calling freeirq().

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

iio: gyro: mpu3050: Fix irq resource leak

The interrupt handler is setup but only a few lines down if iiotriggerregister() fails the function returns without properly releasing the handler.

Add cleanup goto to resolve resource leak.

Detected by Smatch: drivers/iio/gyro/mpu3050-core.c:1128 mpu3050triggerprobe() warn: 'irq' from requestthreadedirq() not released on lines: 1124.

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

ipv6: add NULL checks for idev in SRv6 paths

in6devget() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6MINMTU or after NETDEVUNREGISTER).

Add NULL checks for idev returned by in6devget() in both seg6hmacvalidateskb() and ipv6srhrcv() to prevent potential NULL pointer dereferences.

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

net: liquidio: Fix off-by-one error in VF setupnicdevices() cleanup

In setupnicdevices(), the initialization loop jumps to the label setupnicdevfree on failure. The current cleanup loop while(i--) skip the failing index i, causing a memory leak.

Fix this by changing the loop to iterate from the current index i down to 0.

Compile tested only. Issue found using code review.

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

media: solo6x10: fix possible memory leak in solosysfsinit()

If deviceregister() returns error in solosysfsinit(), the name allocated by devsetname() need be freed. As comment of deviceregister() says, it should use putdevice() to give up the reference in the error path. So fix this by calling putdevice(), then the name can be freed in kobjectcleanup().

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

r6040: Fix kmemleak in probe and remove

There is a memory leaks reported by kmemleak:

unreferenced object 0xffff888116111000 (size 2048): comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s) hex dump (first 32 bytes): 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................ 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff815bcd82>] kmalloctrace+0x22/0x60 [<ffffffff827e20ee>] phydevicecreate+0x4e/0x90 [<ffffffff827e6072>] getphydevice+0xd2/0x220 [<ffffffff827e7844>] mdiobusscan+0xa4/0x2e0 [<ffffffff827e8be2>] mdiobusregister+0x482/0x8b0 [<ffffffffa01f5d24>] r6040initone+0x714/0xd2c [r6040] ...

The problem occurs in probe process as follows: r6040initone: mdiobusregister mdiobusscan <- alloc and register phydevice, the reference count of phydevice is 3 r6040miiprobe phyconnect <- connect to the first phydevice, so the reference count of the first phydevice is 4, others are 3 registernetdev <- fault inject succeeded, goto error handling path

// error handling path erroutmdiounregister: mdiobusunregister(lp->miibus); erroutmdio: mdiobusfree(lp->miibus); <- the reference count of the first phydevice is 1, it is not released and other phydevices are released // similarly, the remove process also has the same problem

The root cause is traced to the phydevice is not disconnected when removes one r6040 device in r6040removeone() or on error handling path after r6040mii probed successfully. In r6040miiprobe(), a net ethernet device is connected to the first PHY device of miibus, in order to notify the connected driver when the link status changes, which is the default behavior of the PHY infrastructure to handle everything. Therefore the phydevice should be disconnected when removes one r6040 device or on error handling path.

Fix it by adding phydisconnect() when removes one r6040 device or on error handling path after r6040mii probed successfully.

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

usb: host: xhci: Fix potential memory leak in xhciallocstreaminfo()

xhciallocstreaminfo() allocates stream context array for streaminfo ->streamctxarray with xhciallocstreamctx(). When some error occurs, streaminfo->streamctxarray is not released, which will lead to a memory leak.

We can fix it by releasing the streaminfo->streamctxarray with xhcifreestreamctx() on the error path to avoid the potential memory leak.

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

vme: Fix error not catched in fakeinit()

In fakeinit(), rootdeviceregister() is possible to fail but it's ignored, which can cause unregistering vmeroot fail when exit.

general protection fault, probably for non-canonical address 0xdffffc000000008c KASAN: null-ptr-deref in range [0x0000000000000460-0x0000000000000467] RIP: 0010:rootdeviceunregister+0x26/0x60 Call Trace: <TASK> x64sysdeletemodule+0x34f/0x540 dosyscall64+0x38/0x90 entrySYSCALL64afterhwframe+0x63/0xcd

Return error when rootdeviceregister() fails.

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

dm thin: Use last transaction's pmd->root when commit failed

Recently we found a softlock up problem in dm thin pool btree lookup code due to corrupted metadata:

Kernel panic - not syncing: softlockup: hung tasks CPU: 7 PID: 2669225 Comm: kworker/u16:3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: dm-thin doworker [dmthinpool] Call Trace: <IRQ> dumpstack+0x9c/0xd3 panic+0x35d/0x6b9 watchdogtimerfn.cold+0x16/0x25 runhrtimer+0xa2/0x2d0 </IRQ> RIP: 0010:relinklru+0x102/0x220 [dmbufio] bufionew+0x11f/0x4f0 [dmbufio] newread+0xa3/0x1e0 [dmbufio] dmbmreadlock+0x33/0xd0 [dmpersistentdata] rostep+0x63/0x100 [dmpersistentdata] btreelookupraw.constprop.0+0x44/0x220 [dmpersistentdata] dmbtreelookup+0x16f/0x210 [dmpersistentdata] dmthinfindblock+0x12c/0x210 [dmthinpool] processbioreadonly+0xc5/0x400 [dmthinpool] processthindeferredbios+0x1a4/0x4a0 [dmthinpool] processonework+0x3c5/0x730

Following process may generate a broken btree mixed with fresh and stale btree nodes, which could get dm thin trapped in an infinite loop while looking up data block: Transaction 1: pmd->root = A, A->B->C // One path in btree pmd->root = X, X->Y->Z // Copy-up Transaction 2: X,Z is updated on disk, Y write failed. // Commit failed, dm thin becomes read-only. processbioreadonly dmthinfindblock findblock dmbtreelookup(pmd->root) The pmd->root points to a broken btree, Y may contain stale node pointing to any block, for example X, which gets dm thin trapped into a dead loop while looking up Z.

Fix this by setting pmd->root in openmetadata(), so that dm thin will use the last transaction's pmd->root if commit failed.

Fetch a reproducer in [Link].

Linke: https://bugzilla.kernel.org/showbug.cgi?id=216790

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

iommu/fslpamu: Fix resource leak in fslpamuprobe()

The fslpamuprobe() returns directly when createcsd() failed, leaving irq and memories unreleased. Fix by jumping to error if createcsd() returns error.

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

clk: rockchip: Fix memory leak in rockchipclkregisterpll()

If clkregister() fails, @pll->ratetable may have allocated memory by kmemdup(), so it needs to be freed, otherwise will cause memory leak issue, this patch fixes it.

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

drm/radeon: Fix PCI device refcount leak in radeonatrmgetbios()

As comment of pcigetclass() says, it returns a pcidevice with its refcount increased and decreased the refcount for the input parameter @from if it is not NULL.

If we break the loop in radeonatrmgetbios() with 'pdev' not NULL, we need to call pcidevput() to decrease the refcount. Add the missing pcidevput() to avoid refcount leak.

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

nilfs2: replace WARNONs by nilfserror for checkpoint acquisition failure

If creation or finalization of a checkpoint fails due to anomalies in the checkpoint metadata on disk, a kernel warning is generated.

This patch replaces the WARNONs by nilfserror, so that a kernel, booted with paniconwarn, does not panic. A nilfserror is appropriate here to handle the abnormal filesystem condition.

This also replaces the detected error codes with an I/O error so that neither of the internal error codes is returned to callers.

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

media: coda: Add check for kmalloc

As the kmalloc may return NULL pointer, it should be better to check the return value in order to avoid NULL poineter dereference, same as the others.

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

hwmon: (coretemp) Simplify platform device handling

Coretemp's platform driver is unconventional. All the real work is done globally by the initcall and CPU hotplug notifiers, while the "driver" effectively just wraps an allocation and the registration of the hwmon interface in a long-winded round-trip through the driver core. The whole logic of dynamically creating and destroying platform devices to bring the interfaces up and down is error prone, since it assumes platformdeviceadd() will synchronously bind the driver and set drvdata before it returns, thus results in a NULL dereference if driversautoprobe is turned off for the platform bus. Furthermore, the unusual approach of doing that from within a CPU hotplug notifier, already commented in the code that it deadlocks suspend, also causes lockdep issues for other drivers or subsystems which may want to legitimately register a CPU hotplug notifier from a platform bus notifier.

All of these issues can be solved by ripping this unusual behaviour out completely, simply tying the platform devices to the lifetime of the module itself, and directly managing the hwmon interfaces from the hotplug notifiers. There is a slight user-visible change in that /sys/bus/platform/drivers/coretemp will no longer appear, and /sys/devices/platform/coretemp.n will remain present if package n is hotplugged off, but hwmon users should really only be looking for the presence of the hwmon interfaces, whose behaviour remains unchanged.

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

powerpc/rtas: avoid scheduling in rtasosterm()

It's unsafe to use rtasbusydelay() to handle a busy status from the ibm,os-term RTAS function in rtasosterm():

Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618 inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 1, name: swapper/0 preemptcount: 2, expected: 0 CPU: 7 PID: 1 Comm: swapper/0 Tainted: G D 6.0.0-rc5-02182-gf8553a572277-dirty #9 Call Trace: [c000000007b8f000] [c000000001337110] dumpstacklvl+0xb4/0x110 (unreliable) [c000000007b8f040] [c0000000002440e4] mightresched+0x394/0x3c0 [c000000007b8f0e0] [c00000000004f680] rtasbusydelay+0x120/0x1b0 [c000000007b8f100] [c000000000052d04] rtasosterm+0xb8/0xf4 [c000000007b8f180] [c0000000001150fc] pseriespanic+0x50/0x68 [c000000007b8f1f0] [c000000000036354] ppcpanicplatformhandler+0x34/0x50 [c000000007b8f210] [c0000000002303c4] notifiercallchain+0xd4/0x1c0 [c000000007b8f2b0] [c0000000002306cc] atomicnotifiercallchain+0xac/0x1c0 [c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0 [c000000007b8f390] [c0000000001e573c] doexit+0x140c/0x1420 [c000000007b8f480] [c0000000001e586c] maketaskdead+0xdc/0x200

Use rtasbusydelaytime() instead, which signals without side effects whether to attempt the ibm,os-term RTAS call again.

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

mtd: lpddr2nvm: Fix possible null-ptr-deref

It will cause null-ptr-deref when resourcesize(addrange) invoked, if platformgetresource() returns NULL.

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

media: coda: Add check for dcodairamalloc

As the codairamalloc may return NULL pointer, it should be better to check the return value in order to avoid NULL poineter dereference, same as the others.

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

thermal: intelpowerclamp: Use getcpu() instead of smpprocessorid() to avoid crash

When CPU 0 is offline and intelpowerclamp is used to inject idle, it generates kernel BUG:

BUG: using smpprocessorid() in preemptible [00000000] code: bash/15687 caller is debugsmpprocessorid+0x17/0x20 CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57 Call Trace: <TASK> dumpstacklvl+0x49/0x63 dumpstack+0x10/0x16 checkpreemptiondisabled+0xdd/0xe0 debugsmpprocessorid+0x17/0x20 powerclampsetcurstate+0x7f/0xf9 [intelpowerclamp] ... ...

Here CPU 0 is the control CPU by default and changed to the current CPU, if CPU 0 offlined. This check has to be performed under cpusreadlock(), hence the above warning.

Use getcpu() instead of smpprocessorid() to avoid this BUG.

[ rjw: Subject edits ]

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

drm/mipi-dsi: Detach devices when removing the host

Whenever the MIPI-DSI host is unregistered, the code of mipidsihostunregister() loops over every device currently found on that bus and will unregister it.

However, it doesn't detach it from the bus first, which leads to all kind of resource leaks if the host wants to perform some clean up whenever a device is detached.

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

net: ethernet: ti: Fix return type of netcpndostartxmit()

With clang's kernel control flow integrity (kCFI, CONFIGCFICLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A proposed warning in clang aims to catch these at compile time, which reveals:

drivers/net/ethernet/ti/netcpcore.c:1944:21: error: incompatible function pointer types initializing 'netdevtxt ()(struct skbuff , struct netdevice )' (aka 'enum netdevtx ()(struct skbuff , struct netdevice )') with an expression of type 'int (struct skbuff , struct netdevice )' [-Werror,-Wincompatible-function-pointer-types-strict] .ndostartxmit = netcpndostartxmit, ^~~~~~~~~~~~~~~~~~~~ 1 error generated.

->ndostartxmit() in 'struct netdeviceops' expects a return type of 'netdevtxt', not 'int'. Adjust the return type of netcpndostartxmit() to match the prototype's to resolve the warning and CFI failure.

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

ALSA: usb-audio: Fix potential memory leaks

When the driver hits -ENOMEM at allocating a URB or a buffer, it aborts and goes to the error path that releases the all previously allocated resources. However, when -ENOMEM hits at the middle of the sync EP URB allocation loop, the partially allocated URBs might be left without released, because ep->nurbs is still zero at that point.

Fix it by setting ep->nurbs at first, so that the error handler loops over the full URB list.

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

cxl: fix possible null-ptr-deref in cxlguestinitafu|adapter()

If deviceregister() fails in cxlregisterafu|adapter(), the device is not added, deviceunregister() can not be called in the error path, otherwise it will cause a null-ptr-deref because of removing not added device.

As comment of deviceregister() says, it should use putdevice() to give up the reference in the error path. So split deviceunregister() into devicedel() and putdevice(), then goes to put dev when register fails.

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

ntbnetdev: Use devkfreeskbany() in interrupt context

TX/RX callback handlers (ntbnetdevtxhandler(), ntbnetdevrxhandler()) can be called in interrupt context via the DMA framework when the respective DMA operations have completed. As such, any calls by these routines to free skb's, should use the interrupt context safe devkfreeskbany() function.

Previously, these callback handlers would call the interrupt unsafe version of devkfreeskb(). This has not presented an issue on Intel IOAT DMA engines as that driver utilizes tasklets rather than a hard interrupt handler, like the AMD PTDMA DMA driver. On AMD systems, a kernel WARNING message is encountered, which is being issued from skbreleaseheadstate() due to inhardirq() being true.

Besides the user visible WARNING from the kernel, the other symptom of this bug was that TCP/IP performance across the ntbnetdev interface was very poor, i.e. approximately an order of magnitude below what was expected. With the repair to use devkfreeskbany(), kernel WARNINGs from skbreleaseheadstate() ceased and TCP/IP performance, as measured by iperf, was on par with expected results, approximately 20 Gb/s on AMD Milan based server. Note that this performance is comparable with Intel based servers.