OESA-2024-2109

Source
https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-2109
Import Source
https://repo.openeuler.org/security/data/osv/OESA-2024-2109.json
JSON Data
https://api.osv.dev/v1/vulns/OESA-2024-2109
Upstream
Published
2024-09-06T11:09:04Z
Modified
2025-09-03T06:18:43.520670Z
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

f2fs: let's avoid panic if extent_tree is not created

This patch avoids the below panic.

pc : _lookupextenttree+0xd8/0x760 lr : f2fsdowritedatapage+0x104/0x87c sp : ffffffc010cbb3c0 x29: ffffffc010cbb3e0 x28: 0000000000000000 x27: ffffff8803e7f020 x26: ffffff8803e7ed40 x25: ffffff8803e7f020 x24: ffffffc010cbb460 x23: ffffffc010cbb480 x22: 0000000000000000 x21: 0000000000000000 x20: ffffffff22e90900 x19: 0000000000000000 x18: ffffffc010c5d080 x17: 0000000000000000 x16: 0000000000000020 x15: ffffffdb1acdbb88 x14: ffffff888759e2b0 x13: 0000000000000000 x12: ffffff802da49000 x11: 000000000a001200 x10: ffffff8803e7ed40 x9 : ffffff8023195800 x8 : ffffff802da49078 x7 : 0000000000000001 x6 : 0000000000000000 x5 : 0000000000000006 x4 : ffffffc010cbba28 x3 : 0000000000000000 x2 : ffffffc010cbb480 x1 : 0000000000000000 x0 : ffffff8803e7ed40 Call trace: _lookupextenttree+0xd8/0x760 f2fsdowritedatapage+0x104/0x87c f2fswritesingledatapage+0x420/0xb60 f2fswritecachepages+0x418/0xb1c _f2fswritedatapages+0x428/0x58c f2fswritedatapages+0x30/0x40 dowritepages+0x88/0x190 _writebacksingleinode+0x48/0x448 writebacksbinodes+0x468/0x9e8 _writebackinodeswb+0xb8/0x2a4 wbwriteback+0x33c/0x740 wbdowriteback+0x2b4/0x400 wbworkfn+0xe4/0x34c processonework+0x24c/0x5bc workerthread+0x3e8/0xa50 kthread+0x150/0x1b4(CVE-2022-48877)

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

regulator: da9211: Use irq handler when ready

If the system does not come from reset (like when it is kexec()), the regulator might have an IRQ waiting for us.

If we enable the IRQ handler before its structures are ready, we crash.

This patch fixes:

[ 1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078 [ 1.316096] Call trace: [ 1.316101] blockingnotifiercallchain+0x20/0xa8 [ 1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests [ 1.327823] regulatornotifiercallchain+0x1c/0x2c [ 1.327825] da9211irqhandler+0x68/0xf8 [ 1.327829] irq_thread+0x11c/0x234 [ 1.327833] kthread+0x13c/0x154(CVE-2022-48891)

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

net: arcnet: com20020: Fix null-ptr-deref in com20020pci_probe()

During driver initialization, the pointer of card info, i.e. the variable 'ci' is required. However, the definition of 'com20020pciidtable' reveals that this field is empty for some devices, which will cause null pointer dereference when initializing these devices.

The following log reveals it:

[ 3.973806] KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] [ 3.973819] RIP: 0010:com20020pciprobe+0x18d/0x13e0 [com20020pci] [ 3.975181] Call Trace: [ 3.976208] localpciprobe+0x13f/0x210 [ 3.977248] pcideviceprobe+0x34c/0x6d0 [ 3.977255] ? pciuevent+0x470/0x470 [ 3.978265] reallyprobe+0x24c/0x8d0 [ 3.978273] _driverprobedevice+0x1b3/0x280 [ 3.979288] driverprobe_device+0x50/0x370

Fix this by checking whether the 'ci' is a null pointer first.(CVE-2022-48908)

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

iouring: add a schedule point in ioadd_buffers()

Looping ~65535 times doing kmalloc() calls can trigger soft lockups, especially with DEBUG features (like KASAN).

[ 253.536212] watchdog: BUG: soft lockup - CPU#64 stuck for 26s! [b219417889:12575] [ 253.544433] Modules linked in: vfat fat i2cmuxpca954x i2cmux spidev cdcacm xhcipci xhcihcd sha3generic gq(O) [ 253.544451] CPU: 64 PID: 12575 Comm: b219417889 Tainted: G S O 5.17.0-smp-DEV #801 [ 253.544457] RIP: 0010:kerneltextaddress (./include/asm-generic/sections.h:192 ./include/linux/kallsyms.h:29 kernel/extable.c:67 kernel/extable.c:98) [ 253.544464] Code: 0f 93 c0 48 c7 c1 e0 63 d7 a4 48 39 cb 0f 92 c1 20 c1 0f b6 c1 5b 5d c3 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 53 48 89 fb <48> c7 c0 00 00 80 a0 41 be 01 00 00 00 48 39 c7 72 0c 48 c7 c0 40 [ 253.544468] RSP: 0018:ffff8882d8baf4c0 EFLAGS: 00000246 [ 253.544471] RAX: 1ffff1105b175e00 RBX: ffffffffa13ef09a RCX: 00000000a13ef001 [ 253.544474] RDX: ffffffffa13ef09a RSI: ffff8882d8baf558 RDI: ffffffffa13ef09a [ 253.544476] RBP: ffff8882d8baf4d8 R08: ffff8882d8baf5e0 R09: 0000000000000004 [ 253.544479] R10: ffff8882d8baf5e8 R11: ffffffffa0d59a50 R12: ffff8882eab20380 [ 253.544481] R13: ffffffffa0d59a50 R14: dffffc0000000000 R15: 1ffff1105b175eb0 [ 253.544483] FS: 00000000016d3380(0000) GS:ffff88af48c00000(0000) knlGS:0000000000000000 [ 253.544486] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 253.544488] CR2: 00000000004af0f0 CR3: 00000002eabfa004 CR4: 00000000003706e0 [ 253.544491] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 253.544492] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 253.544494] Call Trace: [ 253.544496] <TASK> [ 253.544498] ? ioqueuesqe (fs/iouring.c:7143) [ 253.544505] kerneltextaddress (kernel/extable.c:78) [ 253.544508] unwindgetreturnaddress (arch/x86/kernel/unwindframe.c:19) [ 253.544514] archstackwalk (arch/x86/kernel/stacktrace.c:27) [ 253.544517] ? ioqueuesqe (fs/iouring.c:7143) [ 253.544521] stacktracesave (kernel/stacktrace.c:123) [ 253.544527] _kasankmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515) [ 253.544531] ? __kasankmalloc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:515) [ 253.544533] ? _kasankmalloc (mm/kasan/common.c:524) [ 253.544535] ? kmemcachealloctrace (./include/linux/kasan.h:270 mm/slab.c:3567) [ 253.544541] ? ioissuesqe (fs/iouring.c:4556 fs/iouring.c:4589 fs/iouring.c:6828) [ 253.544544] ? _ioqueuesqe (fs/iouring.c:?) [ 253.544551] _kasankmalloc (mm/kasan/common.c:524) [ 253.544553] kmemcachealloctrace (./include/linux/kasan.h:270 mm/slab.c:3567) [ 253.544556] ? ioissuesqe (fs/iouring.c:4556 fs/iouring.c:4589 fs/iouring.c:6828) [ 253.544560] ioissuesqe (fs/iouring.c:4556 fs/iouring.c:4589 fs/iouring.c:6828) [ 253.544564] ? _kasanslaballoc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469) [ 253.544567] ? _kasanslaballoc (mm/kasan/common.c:39 mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469) [ 253.544569] ? kmemcacheallocbulk (mm/slab.h:732 mm/slab.c:3546) [ 253.544573] ? _ioallocreqrefill (fs/iouring.c:2078) [ 253.544578] ? iosubmitsqes (fs/iouring.c:7441) [ 253.544581] ? _sesysiouringenter (fs/iouring.c:10154 fs/iouring.c:10096) [ 253.544584] ? _x64sysiouringenter (fs/iouring.c:10096) [ 253.544587] ? dosyscall64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) [ 253.544590] ? entrySYSCALL64afterhwframe (??:?) [ 253.544596] _ioqueuesqe (fs/iouring.c:?) [ 253.544600] ioqueuesqe (fs/iouring.c:7143) [ 253.544603] iosubmitsqe (fs/iouring.c:?) [ 253.544608] iosubmitsqes (fs/iouring.c:?) [ 253.544612] _sesysiouringenter (fs/iouring.c:10154 fs/io_uri ---truncated---(CVE-2022-48937)

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

Add exception protection processing for vd in axichanhandle_err function

Since there is no protection for vd, a kernel panic will be triggered here in exceptional cases.

You can refer to the processing of axichanblockxfercomplete function

The triggered kernel panic is as follows:

[ 67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 [ 67.848447] Mem abort info: [ 67.848449] ESR = 0x96000004 [ 67.848451] EC = 0x25: DABT (current EL), IL = 32 bits [ 67.848454] SET = 0, FnV = 0 [ 67.848456] EA = 0, S1PTW = 0 [ 67.848458] Data abort info: [ 67.848460] ISV = 0, ISS = 0x00000004 [ 67.848462] CM = 0, WnR = 0 [ 67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000 [ 67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000 [ 67.848472] Internal error: Oops: 96000004 [#1] SMP [ 67.848475] Modules linked in: dmatest [ 67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emux2rc+ #11 [ 67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--) [ 67.848487] pc : axichanhandleerr+0xc4/0x230 [ 67.848491] lr : axichanhandleerr+0x30/0x230 [ 67.848493] sp : ffff0803fe55ae50 [ 67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200 [ 67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080 [ 67.848504] x25: ffff800010d33880 x24: ffff80001139d850 [ 67.848508] x23: ffff0800c097c168 x22: 0000000000000000 [ 67.848512] x21: 0000000000000080 x20: 0000000000002000 [ 67.848517] x19: ffff0800c097c080 x18: 0000000000000000 [ 67.848521] x17: 0000000000000000 x16: 0000000000000000 [ 67.848525] x15: 0000000000000000 x14: 0000000000000000 [ 67.848529] x13: 0000000000000000 x12: 0000000000000040 [ 67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a [ 67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270 [ 67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0 [ 67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480 [ 67.848550] x3 : dead000000000100 x2 : dead000000000122 [ 67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168 [ 67.848559] Call trace: [ 67.848562] axichanhandleerr+0xc4/0x230 [ 67.848566] dwaxidmainterrupt+0xf4/0x590 [ 67.848569] _handleirqeventpercpu+0x60/0x220 [ 67.848573] handleirqevent+0x64/0x120 [ 67.848576] handlefasteoiirq+0xc4/0x220 [ 67.848580] _handledomainirq+0x80/0xe0 [ 67.848583] gichandleirq+0xc0/0x138 [ 67.848585] el1irq+0xc8/0x180 [ 67.848588] archcpuidle+0x14/0x2c [ 67.848591] defaultidlecall+0x40/0x16c [ 67.848594] doidle+0x1f0/0x250 [ 67.848597] cpustartupentry+0x2c/0x60 [ 67.848600] restinit+0xc0/0xcc [ 67.848603] archcallrestinit+0x14/0x1c [ 67.848606] start_kernel+0x4cc/0x500 [ 67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1) [ 67.848613] ---[ end trace 585a97036f88203a ]---(CVE-2023-52899)

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

scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory

There is a potential out-of-bounds access when using testbit() on a single word. The testbit() and set_bit() functions operate on long values, and when testing or setting a single word, they can exceed the word boundary. KASAN detects this issue and produces a dump:

 BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas

 Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965

For full log, please look at [1].

Make the allocation at least the size of sizeof(unsigned long) so that setbit() and testbit() have sufficient room for read/write operations without overwriting unallocated memory.

[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/(CVE-2024-40901)

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

mm: avoid overflows in dirty throttling logic

The dirty throttling logic is interspersed with assumptions that dirty limits in PAGESIZE units fit into 32-bit (so that various multiplications fit into 64-bits). If limits end up being larger, we will hit overflows, possible divisions by 0 etc. Fix these problems by never allowing so large dirty limits as they have dubious practical value anyway. For dirtybytes / dirtybackgroundbytes interfaces we can just refuse to set so large limits. For dirtyratio / dirtybackgroundratio it isn't so simple as the dirty limit is computed from the amount of available memory which can change due to memory hotplug etc. So when converting dirty limits from ratios to numbers of pages, we just don't allow the result to exceed UINTMAX.

This is root-only triggerable problem which occurs when the operator sets dirty limits to >16 TB.(CVE-2024-42131)

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

scsi: qla2xxx: validate nvmelocalport correctly

The driver load failed with error message,

qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef

and with a kernel crash,

BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
Workqueue: events_unbound qla_register_fcport_fn [qla2xxx]
RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]
RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000
RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000
RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030
R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4
R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8
FS:  0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0
Call Trace:
qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]
? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]
qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]
qla_register_fcport_fn+0x54/0xc0 [qla2xxx]

Exit the qlanvmeregisterremote() function when qlanvmeregisterhba() fails and correctly validate nvmelocalport.(CVE-2024-42286)

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

kobjectuevent: Fix OOB access within zapmodalias_env()

zapmodaliasenv() wrongly calculates size of memory block to move, so will cause OOB memory access issue if variable MODALIAS is not the last one within its @env parameter, fixed by correcting size to memmove.(CVE-2024-42292)

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

hfs: fix to initialize fields of hfsinodeinfo after hfsallocinode()

Syzbot reports uninitialized value access issue as below:

loop0: detected capacity change from 0 to 64

BUG: KMSAN: uninit-value in hfsrevalidatedentry+0x307/0x3f0 fs/hfs/sysdep.c:30 hfsrevalidatedentry+0x307/0x3f0 fs/hfs/sysdep.c:30 drevalidate fs/namei.c:862 [inline] lookupfast+0x89e/0x8e0 fs/namei.c:1649 walkcomponent fs/namei.c:2001 [inline] linkpathwalk+0x817/0x1480 fs/namei.c:2332 pathlookupat+0xd9/0x6f0 fs/namei.c:2485 filenamelookup+0x22e/0x740 fs/namei.c:2515 userpathatempty+0x8b/0x390 fs/namei.c:2924 userpathat include/linux/namei.h:57 [inline] domount fs/namespace.c:3689 [inline] _dosysmount fs/namespace.c:3898 [inline] _sesysmount+0x66b/0x810 fs/namespace.c:3875 _x64sysmount+0xe4/0x140 fs/namespace.c:3875 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

BUG: KMSAN: uninit-value in hfsextreadextent fs/hfs/extent.c:196 [inline] BUG: KMSAN: uninit-value in hfsgetblock+0x92d/0x1620 fs/hfs/extent.c:366 hfsextreadextent fs/hfs/extent.c:196 [inline] hfsgetblock+0x92d/0x1620 fs/hfs/extent.c:366 blockreadfullfolio+0x4ff/0x11b0 fs/buffer.c:2271 hfsreadfolio+0x55/0x60 fs/hfs/inode.c:39 filemapreadfolio+0x148/0x4f0 mm/filemap.c:2426 doreadcachefolio+0x7c8/0xd90 mm/filemap.c:3553 doreadcachepage mm/filemap.c:3595 [inline] readcachepage+0xfb/0x2f0 mm/filemap.c:3604 readmappingpage include/linux/pagemap.h:755 [inline] hfsbtreeopen+0x928/0x1ae0 fs/hfs/btree.c:78 hfsmdbget+0x260c/0x3000 fs/hfs/mdb.c:204 hfsfillsuper+0x1fb1/0x2790 fs/hfs/super.c:406 mountbdev+0x628/0x920 fs/super.c:1359 hfsmount+0xcd/0xe0 fs/hfs/super.c:456 legacygettree+0x167/0x2e0 fs/fscontext.c:610 vfsgettree+0xdc/0x5d0 fs/super.c:1489 donewmount+0x7a9/0x16f0 fs/namespace.c:3145 pathmount+0xf98/0x26a0 fs/namespace.c:3475 domount fs/namespace.c:3488 [inline] _dosysmount fs/namespace.c:3697 [inline] _sesysmount+0x919/0x9e0 fs/namespace.c:3674 _ia32sysmount+0x15b/0x1b0 fs/namespace.c:3674 dosyscall32irqson arch/x86/entry/common.c:112 [inline] _dofastsyscall32+0xa2/0x100 arch/x86/entry/common.c:178 dofastsyscall32+0x37/0x80 arch/x86/entry/common.c:203 doSYSENTER32+0x1f/0x30 arch/x86/entry/common.c:246 entrySYSENTERcompatafterhwframe+0x70/0x82

Uninit was created at: allocpages+0x9a6/0xe00 mm/pagealloc.c:4590 _allocpagesnode include/linux/gfp.h:238 [inline] allocpagesnode include/linux/gfp.h:261 [inline] allocslabpage mm/slub.c:2190 [inline] allocateslab mm/slub.c:2354 [inline] newslab+0x2d7/0x1400 mm/slub.c:2407 _slaballoc+0x16b5/0x3970 mm/slub.c:3540 _slaballoc mm/slub.c:3625 [inline] _slaballocnode mm/slub.c:3678 [inline] slaballocnode mm/slub.c:3850 [inline] kmemcachealloclru+0x64d/0xb30 mm/slub.c:3879 allocinodesb include/linux/fs.h:3018 [inline] hfsallocinode+0x5a/0xc0 fs/hfs/super.c:165 allocinode+0x83/0x440 fs/inode.c:260 newinodepseudo fs/inode.c:1005 [inline] newinode+0x38/0x4f0 fs/inode.c:1031 hfsnewinode+0x61/0x1010 fs/hfs/inode.c:186 hfsmkdir+0x54/0x250 fs/hfs/dir.c:228 vfsmkdir+0x49a/0x700 fs/namei.c:4126 domkdirat+0x529/0x810 fs/namei.c:4149 _dosysmkdirat fs/namei.c:4164 [inline] _sesysmkdirat fs/namei.c:4162 [inline] _x64sysmkdirat+0xc8/0x120 fs/namei.c:4162 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b

It missed to initialize .tzsecondswest, .cachedstart and .cachedblocks fields in struct hfsinodeinfo after hfsalloc_inode(), fix it.(CVE-2024-42311)

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

sysctl: always initialize iuid/igid

Always initialize iuid/igid inside the sysfs core so set_ownership() can safely skip setting them.

Commit 5ec27ec735ba ("fs/proc/procsysctl.c: fix the default values of iuid/igid on /proc/sys inodes.") added defaults for iuid/igid when setownership() was not implemented. It also missed adjusting netctlset_ownership() to use the same default values in case the computation of a better value failed.(CVE-2024-42312)

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

usb: vhci-hcd: Do not drop references before new references are gained

At a few places the driver carries stale pointers to references that can still be used. Make sure that does not happen. This strictly speaking closes ZDI-CAN-22273, though there may be similar races in the driver.(CVE-2024-43883)

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

tracing: Fix overflow in getfreeelt()

"tracingmap->nextelt" in getfreeelt() is at risk of overflowing.

Once it overflows, new elements can still be inserted into the tracingmap even though the maximum number of elements (max_elts) has been reached. Continuing to insert elements after the overflow could result in the tracingmap containing "tracingmap->maxsize" elements, leaving no empty entries. If any attempt is made to insert an element into a full tracing_map using __tracing_map_insert(), it will cause an infinite loop with preemption disabled, leading to a CPU hang problem.

Fix this by preventing any further increments to "tracingmap->nextelt" once it reaches "tracingmap->maxelt".(CVE-2024-43890)

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

media: xc2028: avoid use-after-free in loadfirmwarecb()

syzkaller reported use-after-free in loadfirmwarecb() [1]. The reason is because the module allocated a struct tuner in tuner_probe(), and then the module initialization failed, the struct tuner was released. A worker which created during module initialization accesses this struct tuner later, it caused use-after-free.

The process is as follows:

task-6504 workerthread tunerprobe <= alloc dvbfrontend [2] ... requestfirmwarenowait <= create a worker ... tunerremove <= free dvbfrontend ... requestfirmwareworkfunc <= the firmware is ready loadfirmwarecb <= but now the dvb_frontend has been freed

To fix the issue, check the dvdfrontend in loadfirmware_cb(), if it is null, report a warning and just return.

 BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0
 Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504

 Call trace:
  load_firmware_cb+0x1310/0x17a0
  request_firmware_work_func+0x128/0x220
  process_one_work+0x770/0x1824
  worker_thread+0x488/0xea0
  kthread+0x300/0x430
  ret_from_fork+0x10/0x20

 Allocated by task 6504:
  kzalloc
  tuner_probe+0xb0/0x1430
  i2c_device_probe+0x92c/0xaf0
  really_probe+0x678/0xcd0
  driver_probe_device+0x280/0x370
  __device_attach_driver+0x220/0x330
  bus_for_each_drv+0x134/0x1c0
  __device_attach+0x1f4/0x410
  device_initial_probe+0x20/0x30
  bus_probe_device+0x184/0x200
  device_add+0x924/0x12c0
  device_register+0x24/0x30
  i2c_new_device+0x4e0/0xc44
  v4l2_i2c_new_subdev_board+0xbc/0x290
  v4l2_i2c_new_subdev+0xc8/0x104
  em28xx_v4l2_init+0x1dd0/0x3770

 Freed by task 6504:
  kfree+0x238/0x4e4
  tuner_remove+0x144/0x1c0
  i2c_device_remove+0xc8/0x290
  __device_release_driver+0x314/0x5fc
  device_release_driver+0x30/0x44
  bus_remove_device+0x244/0x490
  device_del+0x350/0x900
  device_unregister+0x28/0xd0
  i2c_unregister_device+0x174/0x1d0
  v4l2_device_unregister+0x224/0x380
  em28xx_v4l2_init+0x1d90/0x3770

 The buggy address belongs to the object at ffff8000d7ca2000
  which belongs to the cache kmalloc-2k of size 2048
 The buggy address is located 776 bytes inside of
  2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)
 The buggy address belongs to the page:
 page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0
 flags: 0x7ff800000000100(slab)
 raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000
 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000
 page dumped because: kasan: bad access detected

 Memory state around the buggy address:
  ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 &gt;ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                       ^
  ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
  ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ==================================================================

[2] Actually, it is allocated for struct tuner, and dvb_frontend is inside.(CVE-2024-43900)

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

netfilter: ctnetlink: use helper function to calculate expect ID

Delete expectation path is missing a call to the nfexpectget_id() helper function to calculate the expectation ID, otherwise LSB of the expectation object address is leaked to userspace.(CVE-2024-44944)

Database specific
{
    "severity": "High"
}
References

Affected packages

openEuler:20.03-LTS-SP4 / kernel

Package

Name
kernel
Purl
pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
4.19.90-2409.1.0.0293.oe2003sp4

Ecosystem specific

{
    "src": [
        "kernel-4.19.90-2409.1.0.0293.oe2003sp4.src.rpm"
    ],
    "x86_64": [
        "bpftool-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm",
        "bpftool-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm",
        "kernel-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm",
        "kernel-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm",
        "kernel-debugsource-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm",
        "kernel-devel-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm",
        "kernel-source-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm",
        "kernel-tools-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm",
        "kernel-tools-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm",
        "kernel-tools-devel-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm",
        "perf-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm",
        "perf-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm",
        "python2-perf-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm",
        "python2-perf-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm",
        "python3-perf-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm",
        "python3-perf-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.x86_64.rpm"
    ],
    "aarch64": [
        "bpftool-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm",
        "bpftool-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm",
        "kernel-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm",
        "kernel-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm",
        "kernel-debugsource-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm",
        "kernel-devel-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm",
        "kernel-source-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm",
        "kernel-tools-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm",
        "kernel-tools-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm",
        "kernel-tools-devel-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm",
        "perf-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm",
        "perf-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm",
        "python2-perf-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm",
        "python2-perf-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm",
        "python3-perf-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm",
        "python3-perf-debuginfo-4.19.90-2409.1.0.0293.oe2003sp4.aarch64.rpm"
    ]
}