The Linux Kernel, the operating system core itself.

Security Fix(es):

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

nfc: nci: add flush_workqueue to prevent uaf

Our detector found a concurrent use-after-free bug when detaching an NCI device. The main reason for this bug is the unexpected scheduling between the used delayed mechanism (timer and workqueue).

The race can be demonstrated below:

Thread-1 Thread-2 | ncidevup() | nciopendevice() | _ncirequest(nciresetreq) | ncisendcmd | queuework(cmdwork) nciunregisterdevice() | nciclosedevice() | ... deltimersync(cmdtimer)[1] | ... | Worker ncifreedevice() | ncicmdwork() kfree(ndev)[3] | modtimer(cmd_timer)[2]

In short, the cleanup routine thought that the cmdtimer has already been detached by [1] but the modtimer can re-attach the timer [2], even it is already released [3], resulting in UAF.

This UAF is easy to trigger, crash trace by POC is like below

[ 66.703713] ================================================================== [ 66.703974] BUG: KASAN: use-after-free in enqueuetimer+0x448/0x490 [ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33 [ 66.703974] [ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5 [ 66.703974] Workqueue: nfc2ncicmdwq ncicmdwork [ 66.703974] Call Trace: [ 66.703974] <TASK> [ 66.703974] dumpstacklvl+0x57/0x7d [ 66.703974] printreport.cold+0x5e/0x5db [ 66.703974] ? enqueuetimer+0x448/0x490 [ 66.703974] kasanreport+0xbe/0x1c0 [ 66.703974] ? enqueuetimer+0x448/0x490 [ 66.703974] enqueuetimer+0x448/0x490 [ 66.703974] _modtimer+0x5e6/0xb80 [ 66.703974] ? markheldlocks+0x9e/0xe0 [ 66.703974] ? trytodeltimersync+0xf0/0xf0 [ 66.703974] ? lockdephardirqsonprepare+0x17b/0x410 [ 66.703974] ? queueworkon+0x61/0x80 [ 66.703974] ? lockdephardirqson+0xbf/0x130 [ 66.703974] processonework+0x8bb/0x1510 [ 66.703974] ? lockdephardirqsonprepare+0x410/0x410 [ 66.703974] ? pwqdecnrinflight+0x230/0x230 [ 66.703974] ? rwlockbug.part.0+0x90/0x90 [ 66.703974] ? rawspinlockirq+0x41/0x50 [ 66.703974] workerthread+0x575/0x1190 [ 66.703974] ? processonework+0x1510/0x1510 [ 66.703974] kthread+0x2a0/0x340 [ 66.703974] ? kthreadcompleteandexit+0x20/0x20 [ 66.703974] retfromfork+0x22/0x30 [ 66.703974] </TASK> [ 66.703974] [ 66.703974] Allocated by task 267: [ 66.703974] kasansavestack+0x1e/0x40 [ 66.703974] _kasankmalloc+0x81/0xa0 [ 66.703974] nciallocatedevice+0xd3/0x390 [ 66.703974] nfcmrvlnciregisterdev+0x183/0x2c0 [ 66.703974] nfcmrvlnciuartopen+0xf2/0x1dd [ 66.703974] nciuartttyioctl+0x2c3/0x4a0 [ 66.703974] ttyioctl+0x764/0x1310 [ 66.703974] _x64sysioctl+0x122/0x190 [ 66.703974] dosyscall64+0x3b/0x90 [ 66.703974] entrySYSCALL64afterhwframe+0x44/0xae [ 66.703974] [ 66.703974] Freed by task 406: [ 66.703974] kasansavestack+0x1e/0x40 [ 66.703974] kasansettrack+0x21/0x30 [ 66.703974] kasansetfreeinfo+0x20/0x30 [ 66.703974] _kasanslabfree+0x108/0x170 [ 66.703974] kfree+0xb0/0x330 [ 66.703974] nfcmrvlnciunregisterdev+0x90/0xd0 [ 66.703974] nciuartttyclose+0xdf/0x180 [ 66.703974] ttyldisckill+0x73/0x110 [ 66.703974] ttyldischangup+0x281/0x5b0 [ 66.703974] _ttyhangup.part.0+0x431/0x890 [ 66.703974] ttyrelease+0x3a8/0xc80 [ 66.703974] _fput+0x1f0/0x8c0 [ 66.703974] taskworkrun+0xc9/0x170 [ 66.703974] exittousermodeprepare+0x194/0x1a0 [ 66.703974] syscallexittousermode+0x19/0x50 [ 66.703974] dosyscall64+0x48/0x90 [ 66.703974] entrySYSCALL64after_hwframe+0x44/0x ---truncated---(CVE-2022-49059)

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

drbd: Fix five use after free bugs in getinitialstate

In getinitialstate, it calls notifyinitialstatedone(skb,..) if cb->args[5]==1. If genlmsgput() failed in notifyinitialstatedone(), the skb will be freed by nlmsgfree(skb). Then getinitialstate will goto out and the freed skb will be used by return value skb->len, which is a uaf bug.

What's worse, the same problem goes even further: skb can also be freed in the notify*statechange -> notify*_state calls below. Thus 4 additional uaf bugs happened.

My patch lets the problem callee functions: notifyinitialstatedone and notify*statechange return an error code if errors happen. So that the error codes could be propagated and the uaf bugs can be avoid.

v2 reports a compilation warning. This v3 fixed this warning and built successfully in my local environment with no additional warnings. v2: https://lore.kernel.org/patchwork/patch/1435218/(CVE-2022-49085)

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

virtioconsole: eliminate anonymous moduleinit & module_exit

Eliminate anonymous moduleinit() and moduleexit(), which can lead to confusion or ambiguity when reading System.map, crashes/oops/bugs, or an initcall_debug log.

Give each of these init and exit functions unique driver-specific names to eliminate the anonymous names.

Example 1: (System.map) ffffffff832fc78c t init ffffffff832fc79e t init ffffffff832fc8f8 t init

Example 2: (initcall_debug log) calling init+0x0/0x12 @ 1 initcall init+0x0/0x12 returned 0 after 15 usecs calling init+0x0/0x60 @ 1 initcall init+0x0/0x60 returned 0 after 2 usecs calling init+0x0/0x9a @ 1 initcall init+0x0/0x9a returned 0 after 74 usecs(CVE-2022-49100)

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

drivers: usb: host: Fix deadlock in oxubussuspend()

There is a deadlock in oxubussuspend(), which is shown below:

(Thread 1) | (Thread 2) | timeraction() oxubussuspend() | modtimer() spinlockirq() //(1) | (wait a time) ... | oxuwatchdog() deltimersync() | spinlock_irq() //(2) (wait timer to stop) | ...

We hold oxu->lock in position (1) of thread 1, and use deltimersync() to wait timer to stop, but timer handler also need oxu->lock in position (2) of thread 2. As a result, oxubussuspend() will block forever.

This patch extracts deltimersync() from the protection of spinlockirq(), which could let timer handler to obtain the needed lock.(CVE-2022-49313)

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

firmware: dmi-sysfs: Fix memory leak in dmisysfsregister_handle

kobjectinitandadd() takes reference even when it fails. According to the doc of kobjectinitandadd()

If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object.

Fix this issue by calling kobject_put().(CVE-2022-49370)

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

tipc: check attribute length for bearer name

syzbot reported uninit-value:

BUG: KMSAN: uninit-value in stringnocheck lib/vsprintf.c:644 [inline] BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725 stringnocheck lib/vsprintf.c:644 [inline] string+0x4f9/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 vprintkstore+0x537/0x2150 kernel/printk/printk.c:2158 vprintkemit+0x28b/0xab0 kernel/printk/printk.c:2256 vprintkdefault+0x86/0xa0 kernel/printk/printk.c:2283 vprintk+0x15f/0x180 kernel/printk/printksafe.c:50 printk+0x18d/0x1cf kernel/printk/printk.c:2293 tipcenablebearer net/tipc/bearer.c:371 [inline] _tipcnlbearerenable+0x2022/0x22a0 net/tipc/bearer.c:1033 tipcnlbearerenable+0x6c/0xb0 net/tipc/bearer.c:1042 genlfamilyrcvmsgdoit net/netlink/genetlink.c:731 [inline]

• Do sanity check the attribute length for TIPCNLABEARER_NAME.
• Do not use 'illegal name' in printing message.(CVE-2022-49374)

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

usb: usbip: fix a refcount leak in stub_probe()

usbgetdev() is called in stubdevicealloc(). When stubprobe() fails after that, usbput_dev() needs to be called to release the reference.

Fix this by moving usbputdev() to sdev_free error path handling.

Find this by code review.(CVE-2022-49389)

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

macsec: fix UAF bug for real_dev

Create a new macsec device but not get reference to realdev. That can not ensure that realdev is freed after macsec. That will trigger the UAF bug for real_dev as following:

================================================================== BUG: KASAN: use-after-free in macsecgetiflink+0x5f/0x70 drivers/net/macsec.c:3662 Call Trace: ... macsecgetiflink+0x5f/0x70 drivers/net/macsec.c:3662 devgetiflink+0x73/0xe0 net/core/dev.c:637 defaultoperstate net/core/linkwatch.c:42 [inline] rfc2863policy+0x233/0x2d0 net/core/linkwatch.c:54 linkwatchdodev+0x2a/0x150 net/core/link_watch.c:161

Allocated by task 22209: ... allocnetdevmqs+0x98/0x1100 net/core/dev.c:10549 rtnlcreatelink+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748

Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 devicerelease+0x9f/0x240 drivers/base/core.c:2229 kobjectcleanup lib/kobject.c:673 [inline] kobjectrelease lib/kobject.c:704 [inline] krefput include/linux/kref.h:65 [inline] kobjectput+0x1c8/0x540 lib/kobject.c:721 netdevrun_todo+0x72e/0x10b0 net/core/dev.c:10327

After commit faab39f63c1f ("net: allow out-of-order netdev unregistration") and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackholenetdev"), we can add devholdtrack() in macsecdevinit() and devputtrack() in macsecfree_netdev() to fix the problem.(CVE-2022-49390)

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

phy: qcom-qmp: fix reset-controller leak on probe errors

Make sure to release the lane reset controller in case of a late probe error (e.g. probe deferral).

Note that due to the reset controller being defined in devicetree in "lane" child nodes, devmresetcontrolgetexclusive() cannot be used directly.(CVE-2022-49396)

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

tty: fix deadlock caused by calling printk() under tty_port->lock

pty_write() invokes kmalloc() which may invoke a normal printk() to print failure message. This can cause a deadlock in the scenario reported by syz-bot below:

   CPU0              CPU1                    CPU2
   ----              ----                    ----
                     lock(console_owner);
                                             lock(&port_lock_key);

lock(&port->lock); lock(&portlockkey); lock(&port->lock); lock(console_owner);

As commit dbdda842fe96 ("printk: Add console owner and waiter logic to load balance console writes") said, such deadlock can be prevented by using printkdeferred() in kmalloc() (which is invoked in the section guarded by the port->lock). But there are too many printk() on the kmalloc() path, and kmalloc() can be called from anywhere, so changing printk() to printkdeferred() is too complicated and inelegant.

Therefore, this patch chooses to specify _GFPNOWARN to kmalloc(), so that printk() will not be called, and this deadlock problem can be avoided.

Syzbot reported the following lockdep error:

====================================================== WARNING: possible circular locking dependency detected

5.4.143-00237-g08ccc19a-dirty #10 Not tainted

syz-executor.4/29420 is trying to acquire lock: ffffffff8aedb2a0 (consoleowner){....}-{0:0}, at: consoletrylockspinning kernel/printk/printk.c:1752 [inline] ffffffff8aedb2a0 (consoleowner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023

but task is already holding lock: ffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&port->lock){-.-.}-{2:2}: _rawspinlockirqsave include/linux/spinlockapismp.h:110 [inline] rawspinlockirqsave+0x35/0x50 kernel/locking/spinlock.c:159 ttyportttyget drivers/tty/ttyport.c:288 [inline] <-- lock(&port->lock); ttyportdefaultwakeup+0x1d/0xb0 drivers/tty/ttyport.c:47 serial8250txchars+0x530/0xa80 drivers/tty/serial/8250/8250port.c:1767 serial8250handleirq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250port.c:1854 serial8250handleirq drivers/tty/serial/8250/8250port.c:1827 [inline] <-- lock(&portlockkey); serial8250defaulthandleirq+0xb2/0x220 drivers/tty/serial/8250/8250port.c:1870 serial8250interrupt+0xfd/0x200 drivers/tty/serial/8250/8250core.c:126 _handleirqevent_percpu+0x109/0xa50 kernel/irq/handle.c:156 [...]

-> #1 (&portlockkey){-.-.}-{2:2}: _rawspinlockirqsave include/linux/spinlockapismp.h:110 [inline] rawspinlockirqsave+0x35/0x50 kernel/locking/spinlock.c:159 serial8250consolewrite+0x184/0xa40 drivers/tty/serial/8250/8250port.c:3198 <-- lock(&portlockkey); callconsoledrivers kernel/printk/printk.c:1819 [inline] consoleunlock+0x8cb/0xd00 kernel/printk/printk.c:2504 vprintkemit+0x1b5/0x470 kernel/printk/printk.c:2024 <-- lock(consoleowner); vprintkfunc+0x8d/0x250 kernel/printk/printksafe.c:394 printk+0xba/0xed kernel/printk/printk.c:2084 registerconsole+0x8b3/0xc10 kernel/printk/printk.c:2829 univ8250consoleinit+0x3a/0x46 drivers/tty/serial/8250/8250core.c:681 consoleinit+0x49d/0x6d3 kernel/printk/printk.c:2915 startkernel+0x5e9/0x879 init/main.c:713 secondarystartup64+0xa4/0xb0 arch/x86/kernel/head_64.S:241

-> #0 (consoleowner){....}-{0:0}: [...] lockacquire+0x127/0x340 kernel/locking/lockdep.c:4734 consoletrylockspinning kernel/printk/printk.c:1773 ---truncated---(CVE-2022-49441)

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

rxrpc: Fix listen() setting the bar too high for the prealloc rings

AFRXRPC's listen() handler lets you set the backlog up to 32 (if you bump up the sysctl), but whilst the preallocation circular buffers have 32 slots in them, one of them has to be a dead slot because we're using CIRCCNT().

This means that listen(rxrpcsock, 32) will cause an oops when the socket is closed because rxrpcservicepreallocone() allocated one too many calls and rxrpcdiscardprealloc() won't then be able to get rid of them because it'll think the ring is empty. rxrpcreleasecallsonsocket() then tries to abort them, but oopses because call->peer isn't yet set.

Fix this by setting the maximum backlog to RXRPCBACKLOGMAX - 1 to match the ring capacity.

BUG: kernel NULL pointer dereference, address: 0000000000000086 ... RIP: 0010:rxrpcsendabortpacket+0x73/0x240 [rxrpc] Call Trace: <TASK> ? _wakeupcommonlock+0x7a/0x90 ? rxrpcnotifysocket+0x8e/0x140 [rxrpc] ? rxrpcabortcall+0x4c/0x60 [rxrpc] rxrpcreleasecallsonsocket+0x107/0x1a0 [rxrpc] rxrpcrelease+0xc9/0x1c0 [rxrpc] _sockrelease+0x37/0xa0 sockclose+0x11/0x20 _fput+0x89/0x240 taskworkrun+0x59/0x90 do_exit+0x319/0xaa0(CVE-2022-49450)

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

firmware: arm_scmi: Fix list protocols enumeration in the base protocol

While enumerating protocols implemented by the SCMI platform using BASEDISCOVERLISTPROTOCOLS, the number of returned protocols is currently validated in an improper way since the check employs a sum between unsigned integers that could overflow and cause the check itself to be silently bypassed if the returned value 'loopnum_ret' is big enough.

Fix the validation avoiding the addition.(CVE-2022-49451)

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

drm: msm: fix possible memory leak in mdp5crtccursor_set()

drmgemobjectlookup will call drmgemobjectget inside. So cursorbo needs to be put when msmgemgetandpiniova fails.(CVE-2022-49467)

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

regulator: pfuze100: Fix refcount leak in pfuzeparseregulators_dt

ofnodeget() returns a node with refcount incremented. Calling ofnodeput() to drop the reference when not needed anymore.(CVE-2022-49481)

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

drm/rockchip: vop: fix possible null-ptr-deref in vop_bind()

It will cause null-ptr-deref in resourcesize(), if platformgetresource() returns NULL, move calling resourcesize() after devmioremapresource() that will check 'res' to avoid null-ptr-deref.(CVE-2022-49491)

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

cpufreq: pmac32-cpufreq: Fix refcount leak bug

In pmaccpufreqinitMacRISC3(), we need to add corresponding ofnodeput() for the three node pointers whose refcount have been incremented by offindnodeby_name().(CVE-2022-49621)

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

bus: fsl-mc-bus: fix KASAN use-after-free in fslmcbus_remove()

In fslmcbusremove(), mc->rootmcbusdev->mcio is passed to fsldestroymcio(). However, mc->rootmcbusdev is already freed in fslmcdeviceremove(). Then reference to mc->rootmcbusdev->mcio triggers KASAN use-after-free. To avoid the use-after-free, keep the reference to mc->rootmcbusdev->mcio in a local variable and pass to fsldestroymc_io().

This patch needs rework to apply to kernels older than v5.15.(CVE-2022-49711)

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

dmaengine: imx-sdma: Fix a possible memory leak in sdmatransferinit

If the function sdmaloadcontext() fails, the sdma_desc will be freed, but the allocated desc->bd is forgot to be freed.

We already met the sdmaloadcontext() failure case and the log as below: [ 450.699064] imx-sdma 30bd0000.dma-controller: Timeout waiting for CH0 ready ...

In this case, the desc->bd will not be freed without this change.(CVE-2022-49746)

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

dmaengine: Fix double increment of clientcount in dmachan_get()

The first time dmachanget() is called for a channel the channel clientcount is incorrectly incremented twice for public channels, first in balancerefcount(), and again prior to returning. This results in an incorrect client count which will lead to the channel resources not being freed when they should be. A simple test of repeated module load and unload of asynctx on a Dell Power Edge R7425 also shows this resulting in a kref underflow warning.

[ 124.329662] asynctx: api initialized (async) [ 129.000627] asynctx: api initialized (async) [ 130.047839] ------------[ cut here ]------------ [ 130.052472] refcountt: underflow; use-after-free. [ 130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28 refcountwarnsaturate+0xba/0x110 [ 130.065811] Modules linked in: asynctx(-) rfkill intelraplmsr intelraplcommon amd64edac edacmceamd ipmissif kvmamd dcdbas kvm mgag200 drmshmemhelper acpiipmi irqbypass drmkmshelper ipmisi syscopyarea sysfillrect rapl pcspkr ipmidevintf sysimgblt fbsysfops k10temp i2cpiix4 ipmimsghandler acpipowermeter acpicpufreq vfat fat drm fuse xfs libcrc32c sdmod t10pi sg ahci crct10difpclmul libahci crc32pclmul crc32cintel ghashclmulniintel igb megaraidsas i40e libata i2calgobit ccp sp5100tco dca dmmirror dmregionhash dmlog dmmod [last unloaded: asynctx] [ 130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Not tainted 5.14.0-185.el9.x8664 #1 [ 130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS 1.18.0 01/17/2022 [ 130.133806] RIP: 0010:refcountwarnsaturate+0xba/0x110 [ 130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d 26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a bd 55 00 <0f> 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff 48 c7 [ 130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286 [ 130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000 [ 130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0 [ 130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff [ 130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970 [ 130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 130.198739] FS: 00007f646435c740(0000) GS:ffff9daf9de00000(0000) knlGS:0000000000000000 [ 130.206832] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0 [ 130.219729] Call Trace: [ 130.222192] <TASK> [ 130.224305] dmachanput+0x10d/0x110 [ 130.227988] dmaengineput+0x7a/0xa0 [ 130.231575] _dosysdeletemodule.constprop.0+0x178/0x280 [ 130.237157] ? syscalltraceenter.constprop.0+0x145/0x1d0 [ 130.242652] dosyscall64+0x5c/0x90 [ 130.246240] ? excpagefault+0x62/0x150 [ 130.250178] entrySYSCALL64afterhwframe+0x63/0xcd [ 130.255243] RIP: 0033:0x7f6463a3f5ab [ 130.258830] Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89 01 48 [ 130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab [ 130.292303] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8 [ 130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000 [ 130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8 [ 130.313731] R13: 0000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8 [ 130.320875] </TASK> [ 130.323081] ---[ end trace eff7156d56b5cf25 ]---

cat /sys/class/dma/dma0chan*/in_use would get the wrong result. 2 2 2

Test-by: Jie Hai <haijie1@huawei.com>(CVE-2022-49753)

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

EDAC/highbank: Fix memory leak in highbankmcprobe()

When devresopengroup() fails, it returns -ENOMEM without freeing memory allocated by edacmcalloc().

Call edacmcfree() on the error handling path to avoid a memory leak.

bp: Massage commit message.

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

ALSA: hda/via: Avoid potential array out-of-bound in addsecretdac_path()

sndhdaget_connections() can return a negative error code. It may lead to accessing 'conn' array at a negative index.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52988)

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

HID: betop: check shape of output reports

betopffinit() only checks the total sum of the report counts for each report field to be at least 4, but hidbetopffplay() expects 4 report fields. A device advertising an output report with one field and 4 report counts would pass the check but crash the kernel with a NULL pointer dereference in hidbetopff_play().(CVE-2023-53015)

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

bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation

To mitigate Spectre v4, 2039f26f3aca ("bpf: Fix leakage due to insufficient speculative store bypass mitigation") inserts lfence instructions after 1) initializing a stack slot and 2) spilling a pointer to the stack.

However, this does not cover cases where a stack slot is first initialized with a pointer (subject to sanitization) but then overwritten with a scalar (not subject to sanitization because the slot was already initialized). In this case, the second write may be subject to speculative store bypass (SSB) creating a speculative pointer-as-scalar type confusion. This allows the program to subsequently leak the numerical pointer value using, for example, a branch-based cache side channel.

To fix this, also sanitize scalars if they write a stack slot that previously contained a pointer. Assuming that pointer-spills are only generated by LLVM on register-pressure, the performance impact on most real-world BPF programs should be small.

The following unprivileged BPF bytecode drafts a minimal exploit and the mitigation:

[...] // r6 = 0 or 1 (skalar, unknown user input) // r7 = accessible ptr for side channel // r10 = frame pointer (fp), to be leaked // r9 = r10 # fp alias to encourage ssb *(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, to be leaked // lfence added here because of pointer spill to stack. // // Ommitted: Dummy bpfringbufoutput() here to train alias predictor // for no r9-r10 dependency. // *(u64 *)(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr // 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID, // store may be subject to SSB // // fix: also add an lfence when the slot contained a ptr // r8 = *(u64 *)(r9 - 8) // r8 = architecturally a scalar, speculatively a ptr // // leak ptr using branch-based cache side channel: r8 &= 1 // choose bit to leak if r8 == 0 goto SLOW // no mispredict // architecturally dead code if input r6 is 0, // only executes speculatively iff ptr bit is 1 r8 = *(u64 *)(r7 + 0) # encode bit in cache (0: slow, 1: fast) SLOW: [...]

After running this, the program can time the access to *(r7 + 0) to determine whether the chosen pointer bit was 0 or 1. Repeat this 64 times to recover the whole address on amd64.

In summary, sanitization can only be skipped if one scalar is overwritten with another scalar. Scalar-confusion due to speculative store bypass can not lead to invalid accesses because the pointer bounds deducted during verification are enforced using branchless logic. See 979d63d50c0c ("bpf: prevent out of bounds speculation on pointer arithmetic") for details.

Do not make the mitigation depend on !env->allow{uninitstack,ptr_leaks} because speculative leaks are likely unexpected if these were enabled. For example, leaking the address to a protected log file may be acceptable while disabling the mitigation might unintentionally leak the address into the cached-state of a map that is accessible to unprivileged processes.(CVE-2023-53024)

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

media: uvcvideo: Fix double free in error path

If the uvcstatusinit() function fails to allocate the inturb, it will free the dev->status pointer but doesn't reset the pointer to NULL. This results in the kfree() call in uvcstatus_cleanup() trying to double-free the memory. Fix it by resetting the dev->status pointer to NULL after freeing it.

Reviewed by: Ricardo Ribalda <ribalda@chromium.org>(CVE-2024-57980)

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

netsched: schsfq: don't allow 1 packet limit

The current implementation does not work correctly with a limit of 1. iproute2 actually checks for this and this patch adds the check in kernel as well.

This fixes the following syzkaller reported crash:

UBSAN: array-index-out-of-bounds in net/sched/schsfq.c:210:6 index 65535 is out of range for type 'struct sfqhead[128]' CPU: 0 PID: 2569 Comm: syz-executor101 Not tainted 5.10.0-smp-DEV #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: _dumpstack lib/dumpstack.c:79 [inline] dumpstack+0x125/0x19f lib/dumpstack.c:120 ubsanepilogue lib/ubsan.c:148 [inline] _ubsanhandleoutofbounds+0xed/0x120 lib/ubsan.c:347 sfqlink net/sched/schsfq.c:210 [inline] sfqdec+0x528/0x600 net/sched/schsfq.c:238 sfqdequeue+0x39b/0x9d0 net/sched/schsfq.c:500 sfqreset+0x13/0x50 net/sched/schsfq.c:525 qdiscreset+0xfe/0x510 net/sched/schgeneric.c:1026 tbfreset+0x3d/0x100 net/sched/schtbf.c:319 qdiscreset+0xfe/0x510 net/sched/schgeneric.c:1026 devresetqueue+0x8c/0x140 net/sched/schgeneric.c:1296 netdevforeachtxqueue include/linux/netdevice.h:2350 [inline] devdeactivatemany+0x6dc/0xc20 net/sched/schgeneric.c:1362 _devclosemany+0x214/0x350 net/core/dev.c:1468 devclosemany+0x207/0x510 net/core/dev.c:1506 unregisternetdevicemany+0x40f/0x16b0 net/core/dev.c:10738 unregisternetdevicequeue+0x2be/0x310 net/core/dev.c:10695 unregisternetdevice include/linux/netdevice.h:2893 [inline] _tundetach+0x6b6/0x1600 drivers/net/tun.c:689 tundetach drivers/net/tun.c:705 [inline] tunchrclose+0x104/0x1b0 drivers/net/tun.c:3640 _fput+0x203/0x840 fs/filetable.c:280 taskworkrun+0x129/0x1b0 kernel/taskwork.c:185 exittaskwork include/linux/taskwork.h:33 [inline] doexit+0x5ce/0x2200 kernel/exit.c:931 dogroupexit+0x144/0x310 kernel/exit.c:1046 _dosysexitgroup kernel/exit.c:1057 [inline] _sesysexitgroup kernel/exit.c:1055 [inline] _x64sysexitgroup+0x3b/0x40 kernel/exit.c:1055 dosyscall64+0x6c/0xd0 entrySYSCALL64afterhwframe+0x61/0xcb RIP: 0033:0x7fe5e7b52479 Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f. RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIGRAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0 R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270

The crash can be also be reproduced with the following (with a tc recompiled to allow for sfq limits of 1):

tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s ../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1 ifconfig dummy0 up ping -I dummy0 -f -c2 -W0.1 8.8.8.8 sleep 1

Scenario that triggers the crash:

• the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1

• TBF dequeues: it peeks from SFQ which moves the packet to the gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so it schedules itself for later.

• the second packet is sent and TBF tries to queues it to SFQ. qdisc qlen is now 2 and because the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however q->tail is not NULL.

At this point, assuming no more packets are queued, when sch_dequeue runs again it will decrement the qlen for the current empty slot causing an underflow and the subsequent out of bounds access.(CVE-2024-57996)

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

partitions: mac: fix handling of bogus partition table

Fix several issues in partition probing:

• The bailout for a bad partoffset must use putdevsector(), since the preceding readpartsector() succeeded.
• If the partition table claims a silly sector size like 0xfff bytes (which results in partition table entries straddling sector boundaries), bail out instead of accessing out-of-bounds memory.
• We must not assume that the partition table contains proper NUL termination - use strnlen() and strncmp() instead of strlen() and strcmp().(CVE-2025-21772)