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

scsi: qla2xxx: Fix improper freeing of purex item

In qla2xxxprocesspurlsiocb(), an item is allocated via qla27xxcopymultiplepkt(), which internally calls qla24xxallocpurexitem().

The qla24xxallocpurexitem() function may return a pre-allocated item from a per-adapter pool for small allocations, instead of dynamically allocating memory with kzalloc().

An error handling path in qla2xxxprocesspurlsiocb() incorrectly uses kfree() to release the item. If the item was from the pre-allocated pool, calling kfree() on it is a bug that can lead to memory corruption.

Fix this by using the correct deallocation function, qla24xxfreepurexitem(), which properly handles both dynamically allocated and pre-allocated items.

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

cifs: fix potential oops in cifsoplockbreak

With deferred close we can have closes that race with lease breaks, and so with the current checks for whether to send the lease response, oplockresponse(), this can mean that an unmount (killsb) can occur just before we were checking if the tcon->ses is valid. See below:

[Fri Aug 4 04:12:50 2023] RIP: 0010:cifsoplockbreak+0x1f7/0x5b0 [cifs] [Fri Aug 4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e <48> 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39 [Fri Aug 4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206 [Fri Aug 4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009 [Fri Aug 4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188 [Fri Aug 4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900 [Fri Aug 4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138 [Fri Aug 4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000 [Fri Aug 4 04:12:50 2023] FS: 0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000 [Fri Aug 4 04:12:50 2023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [Fri Aug 4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0 [Fri Aug 4 04:12:50 2023] Call Trace: [Fri Aug 4 04:12:50 2023] <TASK> [Fri Aug 4 04:12:50 2023] processonework+0x225/0x3d0 [Fri Aug 4 04:12:50 2023] workerthread+0x4d/0x3e0 [Fri Aug 4 04:12:50 2023] ? processonework+0x3d0/0x3d0 [Fri Aug 4 04:12:50 2023] kthread+0x12a/0x150 [Fri Aug 4 04:12:50 2023] ? setkthreadstruct+0x50/0x50 [Fri Aug 4 04:12:50 2023] retfromfork+0x22/0x30 [Fri Aug 4 04:12:50 2023] </TASK>

To fix this change the ordering of the checks before sending the oplockresponse to first check if the openFileList is empty.

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

RDMA/irdma: Fix data race on CQP request done

KCSAN detects a data race on cqprequest->requestdone memory location which is accessed locklessly in irdmahandlecqpop while being updated in irdmacqpcehandler.

Annotate lockless intent with READONCE/WRITEONCE to avoid any compiler optimizations like load fusing and/or KCSAN warning.

[222808.417128] BUG: KCSAN: data-race in irdmacqpcehandler [irdma] / irdmawaitevent [irdma]

[222808.417532] write to 0xffff8e44107019dc of 1 bytes by task 29658 on cpu 5: [222808.417610] irdmacqpcehandler+0x21e/0x270 [irdma] [222808.417725] cqpcomplworker+0x1b/0x20 [irdma] [222808.417827] processonework+0x4d1/0xa40 [222808.417835] workerthread+0x319/0x700 [222808.417842] kthread+0x180/0x1b0 [222808.417852] retfromfork+0x22/0x30

[222808.417918] read to 0xffff8e44107019dc of 1 bytes by task 29688 on cpu 1: [222808.417995] irdmawaitevent+0x1e2/0x2c0 [irdma] [222808.418099] irdmahandlecqpop+0xae/0x170 [irdma] [222808.418202] irdmacqpcqdestroycmd+0x70/0x90 [irdma] [222808.418308] irdmapudadelersrc+0x46d/0x4d0 [irdma] [222808.418411] irdmartdeinithw+0x179/0x1d0 [irdma] [222808.418514] irdmaibdeallocdevice+0x11/0x40 [irdma] [222808.418618] ibdeallocdevice+0x2a/0x120 [ibcore] [222808.418823] ibunregisterdevice+0xde/0x100 [ibcore] [222808.418981] ibunregisterdevice+0x22/0x40 [ibcore] [222808.419142] irdmaibunregisterdevice+0x70/0x90 [irdma] [222808.419248] i40iwclose+0x6f/0xc0 [irdma] [222808.419352] i40eclientdeviceunregister+0x14a/0x180 [i40e] [222808.419450] i40iwremove+0x21/0x30 [irdma] [222808.419554] auxiliarybusremove+0x31/0x50 [222808.419563] deviceremove+0x69/0xb0 [222808.419572] devicereleasedriverinternal+0x293/0x360 [222808.419582] driverdetach+0x7c/0xf0 [222808.419592] busremovedriver+0x8c/0x150 [222808.419600] driverunregister+0x45/0x70 [222808.419610] auxiliarydriverunregister+0x16/0x30 [222808.419618] irdmaexitmodule+0x18/0x1e [irdma] [222808.419733] dosysdeletemodule.constprop.0+0x1e2/0x310 [222808.419745] x64sysdeletemodule+0x1b/0x30 [222808.419755] dosyscall64+0x39/0x90 [222808.419763] entrySYSCALL64afterhwframe+0x63/0xcd

[222808.419829] value changed: 0x01 -> 0x03

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

btrfs: fix use-after-free warning in btrfsgetorcreatedelayednode()

Previously, btrfsgetorcreatedelayednode() set the delayednode's refcount before acquiring the root->delayednodes lock. Commit e8513c012de7 ("btrfs: implement reftracker for delayednodes") moved refcountset inside the critical section, which means there is no longer a memory barrier between setting the refcount and setting btrfsinode->delayednode.

Without that barrier, the stores to node->refs and btrfsinode->delayednode may become visible out of order. Another thread can then read btrfsinode->delayednode and attempt to increment a refcount that hasn't been set yet, leading to a refcounting bug and a use-after-free warning.

The fix is to move refcountset back to where it was to take advantage of the implicit memory barrier provided by lock acquisition.

Because the allocations now happen outside of the lock's critical section, they can use GFPNOFS instead of GFPATOMIC.

HID: multitouch: fix slab out-of-bounds access in mtreportfixup()

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

media: si470x: Fix use-after-free in si470xintincallback()

syzbot reported use-after-free in si470xintincallback() [1]. This indicates that urb->context, which contains struct si470xdevice object, is freed when si470xintincallback() is called.

The cause of this issue is that si470xintincallback() is called for freed urb.

si470xusbdriverprobe() calls si470xstartusb(), which then calls usbsubmiturb() and si470xstart(). If si470xstartusb() fails, si470xusbdriverprobe() doesn't kill urb, but it just frees struct si470xdevice object, as depicted below:

si470xusbdriverprobe() ... si470xstartusb() ... usbsubmiturb() retval = si470xstart() return retval if (retval < 0) free struct si470xdevice object, but don't kill urb

This patch fixes this issue by killing urb when si470xstartusb() fails and urb is submitted. If si470xstartusb() fails and urb is not submitted, i.e. submitting usb fails, it just frees struct si470xdevice object.

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

blk-mq: use quiesced elevator switch when reinitializing queues

The hctx's runwork may be racing with the elevator switch when reinitializing hardware queues. The queue is merely frozen in this context, but that only prevents requests from allocating and doesn't stop the hctx work from running. The work may get an elevator pointer that's being torn down, and can result in use-after-free errors and kernel panics (example below). Use the quiesced elevator switch instead, and make the previous one static since it is now only used locally.

nvme nvme0: resetting controller nvme nvme0: 32/0/0 default/read/poll queues BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops: 0000 [#1] SMP PTI Workqueue: kblockd blkmqrunworkfn RIP: 0010:kyberhaswork+0x29/0x70

...

Call Trace: blkmqdodispatchsched+0x83/0x2b0 blkmqscheddispatchrequests+0x12e/0x170 blkmqscheddispatchrequests+0x30/0x60 blkmqrunhwqueue+0x2b/0x50 processonework+0x1ef/0x380 workerthread+0x2d/0x3e0

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

net: bridge: fix use-after-free due to MST port state bypass

syzbot reported[1] a use-after-free when deleting an expired fdb. It is due to a race condition between learning still happening and a port being deleted, after all its fdbs have been flushed. The port's state has been toggled to disabled so no learning should happen at that time, but if we have MST enabled, it will bypass the port's state, that together with VLAN filtering disabled can lead to fdb learning at a time when it shouldn't happen while the port is being deleted. VLAN filtering must be disabled because we flush the port VLANs when it's being deleted which will stop learning. This fix adds a check for the port's vlan group which is initialized to NULL when the port is getting deleted, that avoids the port state bypass. When MST is enabled there would be a minimal new overhead in the fast-path because the port's vlan group pointer is cache-hot.

[1] https://syzkaller.appspot.com/bug?extid=dd280197f0f7ab3917be

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

iouring/net: ensure vectored buffer node import is tied to notification

When support for vectored registered buffers was added, the import itself is using 'req' rather than the notification iokiocb, sr->notif. For non-vectored imports, sr->notif is correctly used. This is important as the lifetime of the two may be different. Use the correct iokiocb for the vectored buffer import.

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

platform/x86: intel: punitipc: fix memory corruption

This passes the address of the pointer "&punitipcdev" when the intent was to pass the pointer itself "punitipcdev" (without the ampersand). This means that the:

complete(&ipcdev->cmdcomplete);

in intelpunitioc() will write to a wrong memory address corrupting it.

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

opp: Fix use-after-free in lazyopptables after probe deferral

When devpmoppoffindiccpaths() in allocateopptable() returns -EPROBEDEFER, the opptable is freed again, to wait until all the interconnect paths are available.

However, if the OPP table is using required-opps then it may already have been added to the global lazyopptables list. The error path does not remove the opptable from the list again.

This can cause crashes later when the provider of the required-opps is added, since we will iterate over OPP tables that have already been freed. E.g.:

Unable to handle kernel NULL pointer dereference when read CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.4.0-rc3 PC is at ofaddopptablev2 (include/linux/of.h:949 drivers/opp/of.c:98 drivers/opp/of.c:344 drivers/opp/of.c:404 drivers/opp/of.c:1032) -> lazylinkrequiredopptable()

Fix this by calling ofclearopptable() to remove the opptable from the list and clear other allocated resources. While at it, also add the missing mutexdestroy() calls in the error path.

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

staging: media: tegra-video: fix devicenode use after free

At probe time this code path is followed:

tegracsiinit tegracsichannelsalloc foreachchildofnode(node, channel) -- iterates over channels automatically gets 'channel' tegracsichannelalloc() saves into chan->ofnode a pointer to the channel OF node automatically gets and puts 'channel' now the node saved in chan->ofnode has refcount 0, can disappear tegracsichannelsinit iterates over channels tegracsichannelinit -- uses chan->ofnode

After that, chan->ofnode keeps storing the node until the device is removed.

ofnodeget() the node and ofnodeput() it during teardown to avoid any risk.

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

blk-cgroup: hold queuelock when removing blkg->qnode

When blkg is removed from q->blkglist from blkgfreeworkfn(), queuelock has to be held, otherwise, all kinds of bugs(list corruption, hard lockup, ..) can be triggered from blkgdestroyall().

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

hfs/hfsplus: avoid WARNON() for sanity check, use proper error handling

Commit 55d1cbbbb29e ("hfs/hfsplus: use WARNON for sanity check") fixed a build warning by turning a comment into a WARNON(), but it turns out that syzbot then complains because it can trigger said warning with a corrupted hfs image.

The warning actually does warn about a bad situation, but we are much better off just handling it as the error it is. So rather than warn about us doing bad things, stop doing the bad things and return -EIO.

While at it, also fix a memory leak that was introduced by an earlier fix for a similar syzbot warning situation, and add a check for one case that historically wasn't handled at all (ie neither comment nor subsequent WARNON).

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

tracing/userevents: Ensure write index cannot be negative

The write index indicates which event the data is for and accesses a per-file array. The index is passed by user processes during write() calls as the first 4 bytes. Ensure that it cannot be negative by returning -EINVAL to prevent out of bounds accesses.

Update ftrace self-test to ensure this occurs properly.

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

serial: 8250: Fix oops for port->pm on uartchangepm()

Unloading a hardware specific 8250 driver can produce error "Unable to handle kernel paging request at virtual address" about ten seconds after unloading the driver. This happens on uarthangup() calling uartchangepm().

Turns out commit 04e82793f068 ("serial: 8250: Reinit port->pm on port specific driver unbind") was only a partial fix. If the hardware specific driver has initialized port->pm function, we need to clear port->pm too. Just reinitializing port->ops does not do this. Otherwise serial8250pm() will call port->pm() instead of serial8250dopm().

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

drm/ttm: Don't leak a resource on eviction error

On eviction errors other than -EMULTIHOP we were leaking a resource. Fix.

v2: - Avoid yet another goto (Andi Shyti)

ethtool: Avoid overflowing userspace buffer on stats query

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

iommu/mediatek: fix use-after-free on probe deferral

The driver is dropping the references taken to the larb devices during probe after successful lookup as well as on errors. This can potentially lead to a use-after-free in case a larb device has not yet been bound to its driver so that the iommu driver probe defers.

Fix this by keeping the references as expected while the iommu driver is bound.

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

Input: lkkbd - disable pending work before freeing device

lkkbdinterrupt() schedules lk->tq via schedulework(), and the work handler lkkbdreinit() dereferences the lkkbd structure and its serio/inputdev fields.

lkkbddisconnect() and error paths in lkkbdconnect() free the lkkbd structure without preventing the reinit work from being queued again until serioclose() returns. This can allow the work handler to run after the structure has been freed, leading to a potential use-after-free.

Use disableworksync() instead of cancelworksync() to ensure the reinit work cannot be re-queued, and call it both in lkkbddisconnect() and in lkkbdconnect() error paths after serioopen().

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

fou: Don't allow 0 for FOUATTRIPPROTO.

fouudprecv() has the same problem mentioned in the previous patch.

If FOUATTRIPPROTO is set to 0, skb is not freed by fouudprecv() nor "resubmit"-ted in ipprotocoldeliverrcu().

Let's forbid 0 for FOUATTRIPPROTO.

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

netfilter: nftables: fix use-after-free in nftablesaddchain()

nftablesaddchain() publishes the chain to table->chains via listaddtailrcu() (in nftchainadd()) before registering hooks. If nftablesregisterhook() then fails, the error path calls nftchaindel() (listdelrcu()) followed by nftableschaindestroy() with no RCU grace period in between.

This creates two use-after-free conditions:

1) Control-plane: nftablesdumpchains() traverses table->chains under rcureadlock(). A concurrent dump can still be walking the chain when the error path frees it.

2) Packet path: for NFPROTOINET, nfregisternethook() briefly installs the IPv4 hook before IPv6 registration fails. Packets entering nftdochain() via the transient IPv4 hook can still be dereferencing chain->blobgenX when the error path frees the chain.

Add synchronizercu() between nftchaindel() and the chain destroy so that all RCU readers -- both dump threads and in-flight packet evaluation -- have finished before the chain is freed.

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

ksmbd: close accepted socket when per-IP limit rejects connection

When the per-IP connection limit is exceeded in ksmbdkthreadfn(), the code sets ret = -EAGAIN and continues the accept loop without closing the just-accepted socket. That leaks one socket per rejected attempt from a single IP and enables a trivial remote DoS.

Release clientsk before continuing.

This bug was found with ZeroPath.

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

mptcp: fix NULL pointer dereference on fastopen early fallback

In case of early fallback to TCP, subflowsynrecvsock() deletes the subflow context before returning the newly allocated sock to the caller.

The fastopen path does not cope with the above unconditionally dereferencing the subflow context.

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

RDMA/rxe: Fix NULL-ptr-deref in rxeqpdocleanup() when socket create failed

There is a null-ptr-deref when mount.cifs over rdma:

BUG: KASAN: null-ptr-deref in rxeqpdocleanup+0x2f3/0x360 [rdmarxe] Read of size 8 at addr 0000000000000018 by task mount.cifs/3046

CPU: 2 PID: 3046 Comm: mount.cifs Not tainted 6.1.0-rc5+ #62 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc3 Call Trace: <TASK> dumpstacklvl+0x34/0x44 kasanreport+0xad/0x130 rxeqpdocleanup+0x2f3/0x360 [rdmarxe] executeinprocesscontext+0x25/0x90 rxecleanup+0x101/0x1d0 [rdmarxe] rxecreateqp+0x16a/0x180 [rdmarxe] createqp.part.0+0x27d/0x340 ibcreateqpkernel+0x73/0x160 rdmacreateqp+0x100/0x230 smbdgetconnection+0x752/0x20f0 smbdgetconnection+0x21/0x40 cifsgettcpsession+0x8ef/0xda0 mountgetconns+0x60/0x750 cifsmount+0x103/0xd00 cifssmb3domount+0x1dd/0xcb0 smb3gettree+0x1d5/0x300 vfsgettree+0x41/0xf0 pathmount+0x9b3/0xdd0 x64sysmount+0x190/0x1d0 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0

The root cause of the issue is the socket create failed in rxeqpinitreq().

So move the reset rxeqpdocleanup() after the NULL ptr check.

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

erspan: Initialize optionslen before referencing options.

The struct iptunnelinfo has a flexible array member named options that is protected by a countedby(optionslen) attribute.

The compiler will use this information to enforce runtime bounds checking deployed by FORTIFYSOURCE string helpers.

As laid out in the GCC documentation, the counter must be initialized before the first reference to the flexible array member.

After scanning through the files that use struct iptunnelinfo and also refer to options or optionslen, it appears the normal case is to use the iptunnelinfooptsset() helper.

Said helper would initialize optionslen properly before copying data into options, however in the GRE ERSPAN code a partial update is done, preventing the use of the helper function.

Before this change the handling of ERSPAN traffic in GRE tunnels would cause a kernel panic when the kernel is compiled with GCC 15+ and having FORTIFYSOURCE configured:

memcpy: detected buffer overflow: 4 byte write of buffer size 0

Call Trace: <IRQ> fortifypanic+0xd/0xf erspanrcv.cold+0x68/0x83 ? iprouteinputslow+0x816/0x9d0 grercv+0x1b2/0x1c0 grercv+0x8e/0x100 ? rawv4input+0x2a0/0x2b0 ipprotocoldeliverrcu+0x1ea/0x210 iplocaldeliverfinish+0x86/0x110 iplocaldeliver+0x65/0x110 ? iprcvfinishcore+0xd6/0x360 iprcv+0x186/0x1a0

Reported-at: https://launchpad.net/bugs/2129580

fbdev: smscufx: properly copy ioctl memory to kernelspace

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

crypto: qat - fix out-of-bounds read

When preparing an AER-CTR request, the driver copies the key provided by the user into a data structure that is accessible by the firmware. If the target device is QAT GEN4, the key size is rounded up by 16 since a rounded up size is expected by the device. If the key size is rounded up before the copy, the size used for copying the key might be bigger than the size of the region containing the key, causing an out-of-bounds read.

Fix by doing the copy first and then update the keylen.

This is to fix the following warning reported by KASAN:

[ 138.150574] BUG: KASAN: global-out-of-bounds in qatalgskcipherinitcom.isra.0+0x197/0x250 [intelqat] [ 138.150641] Read of size 32 at addr ffffffff88c402c0 by task cryptomgrtest/2340

[ 138.150651] CPU: 15 PID: 2340 Comm: cryptomgrtest Not tainted 6.2.0-rc1+ #45 [ 138.150659] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.86B.0087.D13.2208261706 08/26/2022 [ 138.150663] Call Trace: [ 138.150668] <TASK> [ 138.150922] kasancheckrange+0x13a/0x1c0 [ 138.150931] memcpy+0x1f/0x60 [ 138.150940] qatalgskcipherinitcom.isra.0+0x197/0x250 [intelqat] [ 138.151006] qatalgskcipherinitsessions+0xc1/0x240 [intelqat] [ 138.151073] cryptoskciphersetkey+0x82/0x160 [ 138.151085] ? preparekeybuf+0xa2/0xd0 [ 138.151095] testskcipherveccfg+0x2b8/0x800

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

macintosh/machid: fix race condition in machidtoggleemumouse

The following warning appears when running syzkaller, and this issue also exists in the mainline code.

------------[ cut here ]------------ listadd double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/listdebug.c:35 listaddvalidorreport+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:listaddvalidorreport+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> inputregisterhandler+0xb3/0x210 machidstartemulation+0x1c5/0x290 machidtoggleemumouse+0x20a/0x240 procsyscallhandler+0x4c2/0x6e0 newsyncwrite+0x1b1/0x2d0 vfswrite+0x709/0x950 ksyswrite+0x12a/0x250 dosyscall64+0x5a/0x110 entrySYSCALL64afterhwframe+0x78/0xe2

The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in machidtoggleemumouse(). Both processes read oldval=0, then both try to register the input handler, leading to a double listadd of the same handler.

CPU0 CPU1 ------------------------- ------------------------- vfswrite() //write 1 vfswrite() //write 1 procsyswrite() procsyswrite() machidtoggleemumouse() machidtoggleemumouse() oldval = valp // oldval=0 oldval = valp // oldval=0 mutexlockkillable() procdointvec() // valp=1 machidstartemulation() inputregisterhandler() mutexunlock() mutexlockkillable() procdointvec() machidstartemulation() inputregisterhandler() //Trigger Warning mutexunlock()

Fix this by moving the oldval read inside the mutex lock region.

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

net: ethernet: ti: netcp: Standardize knavdmaopenchannel to return NULL on error

Make knavdmaopenchannel consistently return NULL on error instead of ERRPTR. Currently the header include/linux/soc/ti/knavdma.h returns NULL when the driver is disabled, but the driver implementation does not even return NULL or ERRPTR on failure, causing inconsistency in the users. This results in a crash in netcpfreenavigatorresources as followed (trimmed):

Unhandled fault: alignment exception (0x221) at 0xfffffff2 [fffffff2] pgd=80000800207003, pmd=82ffda003, pte=00000000 Internal error: : 221 [#1] SMP ARM Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc7 #1 NONE Hardware name: Keystone PC is at knavdmaclosechannel+0x30/0x19c LR is at netcpfreenavigatorresources+0x2c/0x28c

[... TRIM...]

Call trace: knavdmaclosechannel from netcpfreenavigatorresources+0x2c/0x28c netcpfreenavigatorresources from netcpndoopen+0x430/0x46c netcpndoopen from devopen+0x114/0x29c devopen from devchangeflags+0x190/0x208 devchangeflags from netifchangeflags+0x1c/0x58 netifchangeflags from devchangeflags+0x38/0xa0 devchangeflags from ipautoconfig+0x2c4/0x11f0 ipautoconfig from dooneinitcall+0x58/0x200 dooneinitcall from kernelinitfreeable+0x1cc/0x238 kernelinitfreeable from kernelinit+0x1c/0x12c kernelinit from retfromfork+0x14/0x38 [... TRIM...]

Standardize the error handling by making the function return NULL on all error conditions. The API is used in just the netcpcore.c so the impact is limited.

Note, this change, in effect reverts commit 5b6cb43b4d62 ("net: ethernet: ti: netcpcore: return error while dma channel open issue"), but provides a less error prone implementation.