OESA-2025-1317

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ubi: Fix race condition between ctrlcdevioctl and ubicdevioctl

Hulk Robot reported a KASAN report about use-after-free: ================================================================== BUG: KASAN: use-after-free in _listdelentryvalid+0x13d/0x160 Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385 [...] Call Trace: klistdecanddel+0xa7/0x4a0 klistput+0xc7/0x1a0 devicedel+0x4d4/0xed0 cdevdevicedel+0x1a/0x80 ubiattachmtddev+0x2951/0x34b0 [ubi] ctrlcdevioctl+0x286/0x2f0 [ubi]

Allocated by task 1414: deviceadd+0x60a/0x18b0 cdevdeviceadd+0x103/0x170 ubicreatevolume+0x1118/0x1a10 [ubi] ubicdev_ioctl+0xb7f/0x1ba0 [ubi]

Freed by task 1385: cdevdevicedel+0x1a/0x80 ubiremovevolume+0x438/0x6c0 [ubi] ubicdevioctl+0xbf4/0x1ba0 [ubi] [...] ==================================================================

The lock held by ctrlcdevioctl is ubidevicesmutex, but the lock held by ubicdevioctl is ubi->device_mutex. Therefore, the two locks can be concurrent.

ctrlcdevioctl contains two operations: ubiattach and ubidetach. ubidetach is bug-free because it uses reference counting to prevent concurrency. However, uifinit and uifclose in ubiattach may race with ubicdevioctl.

uifinit will race with ubicdevioctl as in the following stack. cpu1 cpu2 cpu3 |_|_ ctrlcdevioctl ubiattachmtddev uifinit ubicdevioctl ubicreatevolume cdevdeviceadd ubiaddvolume // sysfs exist killvolumes ubicdevioctl ubiremovevolume cdevdevicedel // first free ubifreevolume cdevdel // double free cdevdevicedel

And uifclose will race with ubicdevioctl as in the following stack. cpu1 cpu2 cpu3 |_|_ ctrlcdevioctl ubiattachmtddev uifinit ubicdevioctl ubicreatevolume cdevdeviceadd ubidebugfsinitdev //error goto outuif; uifclose killvolumes ubicdevioctl ubiremovevolume cdevdevicedel // first free ubifreevolume // double free

The cause of this problem is that commit 714fb87e8bc0 make device "available" before it becomes accessible via sysfs. Therefore, we roll back the modification. We will fix the race condition between ubi device creation and udev by removing ubigetdevice in volattributeshow and devattributeshow.This avoids accessing uninitialized ubidevices[ubinum].

ubigetdevice is used to prevent devices from being deleted during sysfs execution. However, now kernfs ensures that devices will not be deleted before all reference counting are released. The key process is shown in the following stack.

devicedel deviceremoveattrs deviceremovegroups sysfsremovegroups sysfsremovegroup removefiles kernfsremovebyname kernfsremovebynamens _kernfsremove kernfsdrain(CVE-2021-47634)

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

jffs2: fix use-after-free in jffs2clearxattr_subsystem

When we mount a jffs2 image, assume that the first few blocks of the image are normal and contain at least one xattr-related inode, but the next block is abnormal. As a result, an error is returned in jffs2scaneraseblock(). jffs2clearxattrsubsystem() is then called in jffs2buildfilesystem() and then again in jffs2dofillsuper().

Finally we can observe the following report: ================================================================== BUG: KASAN: use-after-free in jffs2clearxattr_subsystem+0x95/0x6ac Read of size 8 at addr ffff8881243384e0 by task mount/719

Call Trace: dumpstack+0x115/0x16b jffs2clearxattrsubsystem+0x95/0x6ac jffs2dofillsuper+0x84f/0xc30 jffs2fillsuper+0x2ea/0x4c0 mtdgetsb+0x254/0x400 mtdgetsbbynr+0x4f/0xd0 gettreemtd+0x498/0x840 jffs2gettree+0x25/0x30 vfsgettree+0x8d/0x2e0 pathmount+0x50f/0x1e50 domount+0x107/0x130 _sesysmount+0x1c5/0x2f0 _x64sysmount+0xc7/0x160 dosyscall64+0x45/0x70 entrySYSCALL64after_hwframe+0x44/0xa9

Allocated by task 719: kasansavestack+0x23/0x60 _kasankmalloc.constprop.0+0x10b/0x120 kasanslaballoc+0x12/0x20 kmemcachealloc+0x1c0/0x870 jffs2allocxattrref+0x2f/0xa0 jffs2scanmedium.cold+0x3713/0x4794 jffs2domountfs.cold+0xa7/0x2253 jffs2dofillsuper+0x383/0xc30 jffs2fill_super+0x2ea/0x4c0 [...]

Freed by task 719: kmemcachefree+0xcc/0x7b0 jffs2freexattrref+0x78/0x98 jffs2clearxattrsubsystem+0xa1/0x6ac jffs2domountfs.cold+0x5e6/0x2253 jffs2dofillsuper+0x383/0xc30 jffs2fillsuper+0x2ea/0x4c0 [...]

The buggy address belongs to the object at ffff8881243384b8 which belongs to the cache jffs2xattrref of size 48 The buggy address is located 40 bytes inside of 48-byte region [ffff8881243384b8, ffff8881243384e8) [...] ==================================================================

The triggering of the BUG is shown in the following stack:

jffs2fillsuper jffs2dofillsuper jffs2domountfs jffs2buildfilesystem jffs2scanmedium jffs2scaneraseblock <--- ERROR jffs2clearxattr_subsystem <--- free

jffs2clearxattr_subsystem <--- free again

An error is returned in jffs2domountfs(). If the error is returned by jffs2suminit(), the jffs2clearxattrsubsystem() does not need to be executed. If the error is returned by jffs2buildfilesystem(), the jffs2clearxattrsubsystem() also does not need to be executed again. So move jffs2clearxattrsubsystem() from 'outinohash' to 'outroot' to fix this UAF problem.(CVE-2021-47656)

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

mm: fix unexpected zeroed page mapping with zram swap

Two processes under CLONE_VM cloning, user process can be corrupted by seeing zeroed page unexpectedly.

  CPU A                        CPU B

doswappage doswappage SWPSYNCHRONOUSIO path SWPSYNCHRONOUSIO path swapreadpage valid data swapslotfreenotify delete zram entry swapreadpage zeroed(invalid) data ptelock map the zero data to userspace pteunlock ptelock if (!ptesame) goto outnomap; pte_unlock return and next refault will read zeroed data

The swapslotfreenotify is bogus for CLONEVM case since it doesn't increase the refcount of swap slot at copymm so it couldn't catch up whether it's safe or not to discard data from backing device. In the case, only the lock it could rely on to synchronize swap slot freeing is page table lock. Thus, this patch gets rid of the swapslotfreenotify function. With this patch, CPU A will see correct data.

  CPU A                        CPU B

doswappage doswappage SWPSYNCHRONOUSIO path SWPSYNCHRONOUSIO path swapreadpage original data ptelock map the original data swapfree swaprangefree bddisk->fops->swapslotfreenotify swapreadpage read zeroed data pteunlock ptelock if (!ptesame) goto outnomap; pte_unlock return on next refault will see mapped data by CPU B

The concern of the patch would increase memory consumption since it could keep wasted memory with compressed form in zram as well as uncompressed form in address space. However, most of cases of zram uses no readahead and doswappage is followed by swap_free so it will free the compressed form from in zram quickly.(CVE-2022-49052)

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

rxrpc: fix a race in rxrpcexitnet()

Current code can lead to the following race:

CPU0 CPU1

rxrpcexitnet() rxrpcpeerkeepalive_worker() if (rxnet->live)

rxnet->live = false; deltimersync(&rxnet->peerkeepalivetimer);

                                                         timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay);

cancelworksync(&rxnet->peerkeepalivework);

rxrpcexitnet() exits while peerkeepalivetimer is still armed, leading to use-after-free.

syzbot report was:

ODEBUG: free active (active state 0) object type: timerlist hint: rxrpcpeerkeepalivetimeout+0x0/0xb0 WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debugprintobject+0x16e/0x250 lib/debugobjects.c:505 Modules linked in: CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: netns cleanupnet RIP: 0010:debugprintobject+0x16e/0x250 lib/debugobjects.c:505 Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3 RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082 RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0 R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> _debugchecknoobjfreed lib/debugobjects.c:992 [inline] debugchecknoobjfreed+0x301/0x420 lib/debugobjects.c:1023 kfree+0xd6/0x310 mm/slab.c:3809 opsfreelist.part.0+0x119/0x370 net/core/netnamespace.c:176 opsfreelist net/core/netnamespace.c:174 [inline] cleanupnet+0x591/0xb00 net/core/netnamespace.c:598 processonework+0x996/0x1610 kernel/workqueue.c:2289 workerthread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:298 </TASK>(CVE-2022-49087)

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

scsi: qla2xxx: Suppress a kernel complaint in qlacreateqpair()

[ 12.323788] BUG: using smpprocessorid() in preemptible [00000000] code: systemd-udevd/1020 [ 12.332297] caller is qla2xxxcreateqpair+0x32a/0x5d0 [qla2xxx] [ 12.338417] CPU: 7 PID: 1020 Comm: systemd-udevd Tainted: G I --------- --- 5.14.0-29.el9.x8664 #1 [ 12.348827] Hardware name: Dell Inc. PowerEdge R610/0F0XJ6, BIOS 6.6.0 05/22/2018 [ 12.356356] Call Trace: [ 12.358821] dumpstacklvl+0x34/0x44 [ 12.362514] checkpreemptiondisabled+0xd9/0xe0 [ 12.367164] qla2xxxcreateqpair+0x32a/0x5d0 [qla2xxx] [ 12.372481] qla2x00probeone+0xa3a/0x1b80 [qla2xxx] [ 12.377617] ? _rawspinlockirqsave+0x19/0x40 [ 12.384284] localpciprobe+0x42/0x80 [ 12.390162] ? pcimatchdevice+0xd7/0x110 [ 12.396366] pcideviceprobe+0xfd/0x1b0 [ 12.402372] reallyprobe+0x1e7/0x3e0 [ 12.408114] _driverprobedevice+0xfe/0x180 [ 12.414544] driverprobedevice+0x1e/0x90 [ 12.420685] _driverattach+0xc0/0x1c0 [ 12.426536] ? _deviceattachdriver+0xe0/0xe0 [ 12.433061] ? _deviceattachdriver+0xe0/0xe0 [ 12.439538] busforeachdev+0x78/0xc0 [ 12.445294] busadddriver+0x12b/0x1e0 [ 12.451021] driverregister+0x8f/0xe0 [ 12.456631] ? 0xffffffffc07bc000 [ 12.461773] qla2x00moduleinit+0x1be/0x229 [qla2xxx] [ 12.468776] dooneinitcall+0x44/0x200 [ 12.474401] ? loadmodule+0xad3/0xba0 [ 12.479908] ? kmemcachealloctrace+0x45/0x410 [ 12.486268] doinitmodule+0x5c/0x280 [ 12.491730] _dosysinitmodule+0x12e/0x1b0 [ 12.497785] dosyscall64+0x3b/0x90 [ 12.503029] entrySYSCALL64afterhwframe+0x44/0xae [ 12.509764] RIP: 0033:0x7f554f73ab2e(CVE-2022-49155)

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

ALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction

AV/C deferred transaction was supported at a commit 00a7bb81c20f ("ALSA: firewire-lib: Add support for deferred transaction") while 'deferrable' flag can be uninitialized for non-control/notify AV/C transactions. UBSAN reports it:

kernel: ================================================================================ kernel: UBSAN: invalid-load in /build/linux-aa0B4d/linux-5.15.0/sound/firewire/fcp.c:363:9 kernel: load of value 158 is not a valid value for type 'Bool' kernel: CPU: 3 PID: 182227 Comm: irq/35-firewire Tainted: P OE 5.15.0-18-generic #18-Ubuntu kernel: Hardware name: Gigabyte Technology Co., Ltd. AX370-Gaming 5/AX370-Gaming 5, BIOS F42b 08/01/2019 kernel: Call Trace: kernel: <IRQ> kernel: showstack+0x52/0x58 kernel: dumpstacklvl+0x4a/0x5f kernel: dumpstack+0x10/0x12 kernel: ubsanepilogue+0x9/0x45 kernel: _ubsanhandleloadinvalidvalue.cold+0x44/0x49 kernel: fcpresponse.part.0.cold+0x1a/0x2b [sndfirewirelib] kernel: fcpresponse+0x28/0x30 [sndfirewirelib] kernel: fwcorehandlerequest+0x230/0x3d0 [firewirecore] kernel: handlearpacket+0x1d9/0x200 [firewireohci] kernel: ? handlearpacket+0x1d9/0x200 [firewireohci] kernel: ? transmitcompletecallback+0x9f/0x120 [firewirecore] kernel: arcontexttasklet+0xa8/0x2e0 [firewireohci] kernel: taskletactioncommon.constprop.0+0xea/0xf0 kernel: taskletaction+0x22/0x30 kernel: _dosoftirq+0xd9/0x2e3 kernel: ? irqfinalizeoneshot.part.0+0xf0/0xf0 kernel: dosoftirq+0x75/0xa0 kernel: </IRQ> kernel: <TASK> kernel: _localbhenableip+0x50/0x60 kernel: irqforcedthreadfn+0x7e/0x90 kernel: irqthread+0xba/0x190 kernel: ? irqthreadfn+0x60/0x60 kernel: kthread+0x11e/0x140 kernel: ? irqthreadcheckaffinity+0xf0/0xf0 kernel: ? setkthreadstruct+0x50/0x50 kernel: retfromfork+0x22/0x30 kernel: </TASK> kernel: ================================================================================

This commit fixes the bug. The bug has no disadvantage for the non- control/notify AV/C transactions since the flag has an effect for AV/C response with INTERIM (0x0f) status which is not used for the transactions in AV/C general specification.(CVE-2022-49248)

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

jffs2: fix memory leak in jffs2scanmedium

If an error is returned in jffs2scaneraseblock() and some memory has been added to the jffs2_summary *s, we can observe the following kmemleak report:

unreferenced object 0xffff88812b889c40 (size 64): comm "mount", pid 692, jiffies 4294838325 (age 34.288s) hex dump (first 32 bytes): 40 48 b5 14 81 88 ff ff 01 e0 31 00 00 00 50 00 @H........1...P. 00 00 01 00 00 00 01 00 00 00 02 00 00 00 09 08 ................ backtrace: [<ffffffffae93a3a3>] _kmalloc+0x613/0x910 [<ffffffffaf423b9c>] jffs2sumadddirentmem+0x5c/0xa0 [<ffffffffb0f3afa8>] jffs2scanmedium.cold+0x36e5/0x4794 [<ffffffffb0f3dbe1>] jffs2domountfs.cold+0xa7/0x2267 [<ffffffffaf40acf3>] jffs2dofillsuper+0x383/0xc30 [<ffffffffaf40c00a>] jffs2fillsuper+0x2ea/0x4c0 [<ffffffffb0315d64>] mtdgetsb+0x254/0x400 [<ffffffffb0315f5f>] mtdgetsbbynr+0x4f/0xd0 [<ffffffffb0316478>] gettreemtd+0x498/0x840 [<ffffffffaf40bd15>] jffs2gettree+0x25/0x30 [<ffffffffae9f358d>] vfsgettree+0x8d/0x2e0 [<ffffffffaea7a98f>] pathmount+0x50f/0x1e50 [<ffffffffaea7c3d7>] domount+0x107/0x130 [<ffffffffaea7c5c5>] _sesysmount+0x1c5/0x2f0 [<ffffffffaea7c917>] _x64sysmount+0xc7/0x160 [<ffffffffb10142f5>] dosyscall64+0x45/0x70 unreferenced object 0xffff888114b54840 (size 32): comm "mount", pid 692, jiffies 4294838325 (age 34.288s) hex dump (first 32 bytes): c0 75 b5 14 81 88 ff ff 02 e0 02 00 00 00 02 00 .u.............. 00 00 84 00 00 00 44 00 00 00 6b 6b 6b 6b 6b a5 ......D...kkkkk. backtrace: [<ffffffffae93be24>] kmemcachealloctrace+0x584/0x880 [<ffffffffaf423b04>] jffs2sumaddinodemem+0x54/0x90 [<ffffffffb0f3bd44>] jffs2scanmedium.cold+0x4481/0x4794 [...] unreferenced object 0xffff888114b57280 (size 32): comm "mount", pid 692, jiffies 4294838393 (age 34.357s) hex dump (first 32 bytes): 10 d5 6c 11 81 88 ff ff 08 e0 05 00 00 00 01 00 ..l............. 00 00 38 02 00 00 28 00 00 00 6b 6b 6b 6b 6b a5 ..8...(...kkkkk. backtrace: [<ffffffffae93be24>] kmemcachealloctrace+0x584/0x880 [<ffffffffaf423c34>] jffs2sumaddxattrmem+0x54/0x90 [<ffffffffb0f3a24f>] jffs2scanmedium.cold+0x298c/0x4794 [...] unreferenced object 0xffff8881116cd510 (size 16): comm "mount", pid 692, jiffies 4294838395 (age 34.355s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 09 e0 60 02 00 00 6b a5 ..........`...k. backtrace: [<ffffffffae93be24>] kmemcachealloctrace+0x584/0x880 [<ffffffffaf423cc4>] jffs2sumaddxrefmem+0x54/0x90 [<ffffffffb0f3b2e3>] jffs2scanmedium.cold+0x3a20/0x4794

[...]

Therefore, we should call jffs2sumresetcollected(s) on exit to release the memory added in s. In addition, a new tag "outbuf" is added to prevent the NULL pointer reference caused by s being NULL. (thanks to Zhang Yi for this analysis)(CVE-2022-49276)

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

jffs2: fix memory leak in jffs2domount_fs

If jffs2buildfilesystem() in jffs2domount_fs() returns an error, we can observe the following kmemleak report:

unreferenced object 0xffff88811b25a640 (size 64): comm "mount", pid 691, jiffies 4294957728 (age 71.952s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffffa493be24>] kmemcachealloctrace+0x584/0x880 [<ffffffffa5423a06>] jffs2suminit+0x86/0x130 [<ffffffffa5400e58>] jffs2domountfs+0x798/0xac0 [<ffffffffa540acf3>] jffs2dofillsuper+0x383/0xc30 [<ffffffffa540c00a>] jffs2fillsuper+0x2ea/0x4c0 [...] unreferenced object 0xffff88812c760000 (size 65536): comm "mount", pid 691, jiffies 4294957728 (age 71.952s) hex dump (first 32 bytes): bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb ................ backtrace: [<ffffffffa493a449>] _kmalloc+0x6b9/0x910 [<ffffffffa5423a57>] jffs2suminit+0xd7/0x130 [<ffffffffa5400e58>] jffs2domountfs+0x798/0xac0 [<ffffffffa540acf3>] jffs2dofillsuper+0x383/0xc30 [<ffffffffa540c00a>] jffs2fillsuper+0x2ea/0x4c0

[...]

This is because the resources allocated in jffs2suminit() are not released. Call jffs2sumexit() to release these resources to solve the problem.(CVE-2022-49277)

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

drivers: staging: rtl8192e: Fix deadlock in rtllibbeaconsstop()

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

(Thread 1) | (Thread 2) | rtllibsendbeacon() rtllibbeaconsstop() | modtimer() spinlockirqsave() //(1) | (wait a time) ... | rtllibsendbeaconcb() deltimersync() | spinlockirqsave() //(2) (wait timer to stop) | ...

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

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

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

mips: cpc: Fix refcount leak in mipscpcdefaultphysbase

Add the missing ofnodeput() to release the refcount incremented by offindcompatible_node().(CVE-2022-49324)

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

nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling

Error paths do not free previously allocated memory. Add devm_kfree() to those failure paths.(CVE-2022-49331)

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

rtc: mt6397: check return value after calling platformgetresource()

It will cause null-ptr-deref if platformgetresource() returns NULL, we need check the return value.(CVE-2022-49375)

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

ext4: fix race condition between ext4write and ext4convertinlinedata

Hulk Robot reported a BUGON: ================================================================== EXT4-fs error (device loop3): ext4mbgeneratebuddy:805: group 0, block bitmap and bg descriptor inconsistent: 25 vs 31513 free clusters kernel BUG at fs/ext4/ext4jbd2.c:53! invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1 RIP: 0010:ext4putnojournal fs/ext4/ext4jbd2.c:53 [inline] RIP: 0010:_ext4journalstop+0x10e/0x110 fs/ext4/ext4jbd2.c:116 [...] Call Trace: ext4writeinlinedataend+0x59a/0x730 fs/ext4/inline.c:795 genericperformwrite+0x279/0x3c0 mm/filemap.c:3344 ext4bufferedwriteiter+0x2e3/0x3d0 fs/ext4/file.c:270 ext4filewriteiter+0x30a/0x11c0 fs/ext4/file.c:520 doiterreadvwritev+0x339/0x3c0 fs/readwrite.c:732 doiterwrite+0x107/0x430 fs/readwrite.c:861 vfswritev fs/readwrite.c:934 [inline] dopwritev+0x1e5/0x380 fs/read_write.c:1031 [...] ==================================================================

Above issue may happen as follows: cpu1 cpu2 _|_ dopwritev vfswritev doiterwrite ext4filewriteiter ext4bufferedwriteiter genericperformwrite ext4dawritebegin vfsfallocate ext4fallocate ext4convertinlinedata ext4convertinlinedatanolock ext4destroyinlinedatanolock clear EXT4STATEMAYINLINEDATA ext4mapblocks ext4extmapblocks ext4mbnewblocks ext4mbregularallocator ext4mbgoodgroupnolock ext4mbinitgroup ext4mbinitcache ext4mbgeneratebuddy --> error ext4testinodestate(inode, EXT4STATEMAYINLINEDATA) ext4restoreinlinedata set EXT4STATEMAYINLINEDATA ext4blockwritebegin ext4dawriteend ext4testinodestate(inode, EXT4STATEMAYINLINEDATA) ext4writeinlinedataend handle=NULL ext4journalstop(handle) _ext4journalstop ext4putnojournal(handle) refcnt = (unsigned long)handle BUGON(refcnt == 0) ---> BUGON

The lock held by ext4convertinlinedata is xattrsem, but the lock held by genericperformwrite is i_rwsem. Therefore, the two locks can be concurrent.

To solve above issue, we add inodelock() for ext4convertinlinedata(). At the same time, move ext4convertinlinedata() in front of ext4punchhole(), remove similar handling from ext4punch_hole().(CVE-2022-49414)

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

drm/msm/mdp5: Return error code in mdp5mixerrelease when deadlock is detected

There is a possibility for mdp5getglobalstate to return -EDEADLK when acquiring the modeset lock, but currently globalstate in mdp5mixerrelease doesn't check for if an error is returned.

To avoid a NULL dereference error, let's have mdp5mixerrelease check if an error is returned and propagate that error.

Patchwork: https://patchwork.freedesktop.org/patch/485181/(CVE-2022-49488)

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

drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume

BUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3

Call trace: dpuvbifinitmemtypes+0x40/0xb8 dpuruntimeresume+0xcc/0x1c0 pmgenericruntimeresume+0x30/0x44 _genpdruntimeresume+0x68/0x7c genpdruntimeresume+0x134/0x258 _rpmcallback+0x98/0x138 rpmcallback+0x30/0x88 rpmresume+0x36c/0x49c _pmruntimeresume+0x80/0xb0 dpucoreirquninstall+0x30/0xb0 dpuirquninstall+0x18/0x24 msmdrm_uninit+0xd8/0x16c

Patchwork: https://patchwork.freedesktop.org/patch/483255/ DB: fixed Fixes tag

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

cpufreq: governor: Use kobject release() method to free dbs_data

The struct dbsdata embeds a struct govattrset and the struct govattrset embeds a kobject. Since every kobject must have a release() method and we can't use kfree() to free it directly, so introduce cpufreqdbsdatarelease() to release the dbs_data via the kobject::release() method. This fixes the calltrace like below:

ODEBUG: free active (active state 0) object type: timerlist hint: delayedworktimerfn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debugprintobject+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debugprintobject+0xb8/0x100 lr : debugprintobject+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debugprintobject+0xb8/0x100 _debugchecknoobjfreed+0x1d0/0x25c debugchecknoobjfreed+0x24/0xa0 kfree+0x11c/0x440 cpufreqdbsgovernorexit+0xa8/0xac cpufreqexitgovernor+0x44/0x90 cpufreqsetpolicy+0x29c/0x570 storescalinggovernor+0x110/0x154 store+0xb0/0xe0 sysfskfwrite+0x58/0x84 kernfsfopwriteiter+0x12c/0x1c0 newsyncwrite+0xf0/0x18c vfswrite+0x1cc/0x220 ksyswrite+0x74/0x100 _arm64syswrite+0x28/0x3c invokesyscall.constprop.0+0x58/0xf0 doel0svc+0x70/0x170 el0svc+0x54/0x190 el0t64synchandler+0xa4/0x130 el0t64sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [<ffff8000080849d0>] finishtaskswitch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [<ffff8000090667a4>] el1dbg+0x24/0xa0 softirqs last enabled at (188966): [<ffff8000080106d0>] _dosoftirq+0x4b0/0x6a0 softirqs last disabled at (188957): [<ffff80000804a618>] _irqexit_rcu+0x108/0x1a4

rjw: Because can be freed by the govattrsetput() in cpufreqdbsgovernorexit() now, it is also necessary to put the invocation of the governor ->exit() callback into the new cpufreqdbsdata_release() function.

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

ASoC: mediatek: Fix error handling in mt8173max98090dev_probe

Call ofnodeput(platform_node) to avoid refcount leak in the error path.(CVE-2022-49514)

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

media: venus: hfi: avoid null dereference in deinit

If venusprobe fails at pmruntimeputsync the error handling first calls hfidestroy and afterwards hficoredeinit. As hfidestroy sets core->ops to NULL, hficoredeinit cannot call the core_deinit function anymore.

Avoid this null pointer derefence by skipping the call when necessary.(CVE-2022-49527)

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

drm/virtio: fix NULL pointer dereference in virtiogpuconngetmodes

drmcvtmode may return NULL and we should check it.

This bug is found by syzkaller:

FAULTINJECTION stacktrace: [ 168.567394] FAULTINJECTION: forcing a failure. name failslab, interval 1, probability 0, space 0, times 1 [ 168.567403] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567406] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567408] Call trace: [ 168.567414] dumpbacktrace+0x0/0x310 [ 168.567418] showstack+0x28/0x38 [ 168.567423] dumpstack+0xec/0x15c [ 168.567427] shouldfail+0x3ac/0x3d0 [ 168.567437] _shouldfailslab+0xb8/0x120 [ 168.567441] shouldfailslab+0x28/0xc0 [ 168.567445] kmemcachealloctrace+0x50/0x640 [ 168.567454] drmmodecreate+0x40/0x90 [ 168.567458] drmcvtmode+0x48/0xc78 [ 168.567477] virtiogpuconngetmodes+0xa8/0x140 [virtiogpu] [ 168.567485] drmhelperprobesingleconnectormodes+0x3a4/0xd80 [ 168.567492] drmmodegetconnector+0x2e0/0xa70 [ 168.567496] drmioctlkernel+0x11c/0x1d8 [ 168.567514] drmioctl+0x558/0x6d0 [ 168.567522] dovfsioctl+0x160/0xf30 [ 168.567525] ksysioctl+0x98/0xd8 [ 168.567530] _arm64sysioctl+0x50/0xc8 [ 168.567536] el0svccommon+0xc8/0x320 [ 168.567540] el0svchandler+0xf8/0x160 [ 168.567544] el0svc+0x10/0x218

KASAN stacktrace: [ 168.567561] BUG: KASAN: null-ptr-deref in virtiogpuconngetmodes+0xb4/0x140 [virtiogpu] [ 168.567565] Read of size 4 at addr 0000000000000054 by task syz/6425 [ 168.567566] [ 168.567571] CPU: 1 PID: 6425 Comm: syz Kdump: loaded Not tainted 4.19.90-vhulk2201.1.0.h1035.kasan.eulerosv2r10.aarch64 #1 [ 168.567573] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 [ 168.567575] Call trace: [ 168.567578] dumpbacktrace+0x0/0x310 [ 168.567582] showstack+0x28/0x38 [ 168.567586] dumpstack+0xec/0x15c [ 168.567591] kasanreport+0x244/0x2f0 [ 168.567594] _asanload4+0x58/0xb0 [ 168.567607] virtiogpuconngetmodes+0xb4/0x140 [virtiogpu] [ 168.567612] drmhelperprobesingleconnectormodes+0x3a4/0xd80 [ 168.567617] drmmodegetconnector+0x2e0/0xa70 [ 168.567621] drmioctlkernel+0x11c/0x1d8 [ 168.567624] drmioctl+0x558/0x6d0 [ 168.567628] dovfsioctl+0x160/0xf30 [ 168.567632] ksysioctl+0x98/0xd8 [ 168.567636] _arm64sysioctl+0x50/0xc8 [ 168.567641] el0svccommon+0xc8/0x320 [ 168.567645] el0svchandler+0xf8/0x160 [ 168.567649] el0_svc+0x10/0x218(CVE-2022-49532)

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

ipw2x00: Fix potential NULL dereference in libipw_xmit()

crypt and crypt->ops could be null, so we need to checking null before dereference(CVE-2022-49544)

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

be2net: Fix buffer overflow in begetmodule_eeprom

becmdreadporttransceiverdata assumes that it is given a buffer that is at least PAGEDATA_LEN long, or twice that if the module supports SFF 8472. However, this is not always the case.

Fix this by passing the desired offset and length to becmdreadporttransceiver_data so that we only copy the bytes once.(CVE-2022-49581)

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

pinctrl: ralink: Check for null return of devm_kcalloc

Because of the possible failure of the allocation, data->domains might be NULL pointer and will cause the dereference of the NULL pointer later. Therefore, it might be better to check it and directly return -ENOMEM without releasing data manually if fails, because the comment of the devm_kmalloc() says "Memory allocated with this function is automatically freed on driver detach.".(CVE-2022-49608)

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

xtensa: Fix refcount leak bug in time.c

In calibrateccount(), offindcompatiblenode() will return a node pointer with refcount incremented. We should use ofnodeput() when it is not used anymore.(CVE-2022-49682)

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

i40e: Fix call trace in setuptxdescriptors

After PF reset and ethtool -t there was call trace in dmesg sometimes leading to panic. When there was some time, around 5 seconds, between reset and test there were no errors.

Problem was that pf reset calls i40evsiclose in prepforreset and ethtool -t calls i40evsiclose in diagtest. If there was not enough time between those commands the second i40evsiclose starts before previous i40evsi_close was done which leads to crash.

Add check to diagtest if pf is in reset and don't start offline tests if it is true. Add netifinfo("testing failed") into unhappy path of i40ediagtest()(CVE-2022-49725)

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

nfc: nfcmrvl: Fix memory leak in nfcmrvlplaydeferred

Similar to the handling of playdeferred in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in playdeferred"), we thought a patch might be needed here as well.

Currently usbsubmiturb is called directly to submit deferred tx urbs after unanchor them.

So the usbgivebackurbbh would failed to unref it in usbunanchor_urb and cause memory leak.

Put those urbs in tx_anchor to avoid the leak, and also fix the error handling.(CVE-2022-49729)

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

Bluetooth: L2CAP: handle NULL sock pointer in l2capsockalloc

A NULL sock pointer is passed into l2capsockalloc() when it is called from l2capsocknewconnectioncb() and the error handling paths should also be aware of it.

Seemingly a more elegant solution would be to swap btsockalloc() and l2capchancreate() calls since they are not interdependent to that moment but then l2capchancreate() adds the soon to be deallocated and still dummy-initialized channel to the global list accessible by many L2CAP paths. The channel would be removed from the list in short period of time but be a bit more straight-forward here and just check for NULL instead of changing the order of function calls.

Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool.(CVE-2024-58009)

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

vrf: use RCU protection in l3mdevl3out()

l3mdevl3out() can be called without RCU being held:

rawsendmsg() ippushpendingframes() ipsendskb() iplocalout() _iplocalout() l3mdevip_out()

Add rcureadlock() / rcureadunlock() pair to avoid a potential UAF.(CVE-2025-21791)