OESA-2024-2079 (CVE-2022-48795)
Vulnerability from osv_openeuler – Published: 2024-08-30 11:07 – Updated: 2026-08-06 11:07 – Source websiteThe Linux Kernel, the operating system core itself.
Security Fix(es):
In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix data TLB miss in sba_unmap_sg
Rolf Eike Beer reported the following bug:
[1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018 [1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4 [1274934.746891] Hardware name: 9000/785/C8000 [1274934.746891] [1274934.746891] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [1274934.746891] PSW: 00001000000001001111111000001110 Not tainted [1274934.746891] r00-03 000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000 [1274934.746891] r04-07 0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001 [1274934.746891] r08-11 0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001 [1274934.746891] r12-15 0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0 [1274934.746891] r16-19 0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007 [1274934.746891] r20-23 0000000000000006 000000004a368950 0000000000000000 0000000000000001 [1274934.746891] r24-27 0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0 [1274934.746891] r28-31 0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118 [1274934.746891] sr00-03 00000000066e5800 0000000000000000 0000000000000000 00000000066e5800 [1274934.746891] sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [1274934.746891] [1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec [1274934.746891] IIR: 48780030 ISR: 0000000000000000 IOR: 0000004140000018 [1274934.746891] CPU: 3 CR30: 00000040e3a9c000 CR31: ffffffffffffffff [1274934.746891] ORIG_R28: 0000000040acdd58 [1274934.746891] IAOQ[0]: sba_unmap_sg+0xb0/0x118 [1274934.746891] IAOQ[1]: sba_unmap_sg+0xb4/0x118 [1274934.746891] RP(r2): sba_unmap_sg+0xac/0x118 [1274934.746891] Backtrace: [1274934.746891] [<00000000402740cc>] dma_unmap_sg_attrs+0x6c/0x70 [1274934.746891] [<000000004074d6bc>] scsi_dma_unmap+0x54/0x60 [1274934.746891] [<00000000407a3488>] mptscsih_io_done+0x150/0xd70 [1274934.746891] [<0000000040798600>] mpt_interrupt+0x168/0xa68 [1274934.746891] [<0000000040255a48>] __handle_irq_event_percpu+0xc8/0x278 [1274934.746891] [<0000000040255c34>] handle_irq_event_percpu+0x3c/0xd8 [1274934.746891] [<000000004025ecb4>] handle_percpu_irq+0xb4/0xf0 [1274934.746891] [<00000000402548e0>] generic_handle_irq+0x50/0x70 [1274934.746891] [<000000004019a254>] call_on_stack+0x18/0x24 [1274934.746891] [1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?)
The bug is caused by overrunning the sglist and incorrectly testing sg_dma_len(sglist) before nents. Normally this doesn't cause a crash, but in this case sglist crossed a page boundary. This occurs in the following code:
while (sg_dma_len(sglist) && nents--) {
The fix is simply to test nents first and move the decrement of nents into the loop.(CVE-2022-48795)
In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: Fix GEM handle creation UAF
Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done after we are done dereferencing the object.(CVE-2022-48899)
In the Linux kernel, the following vulnerability has been resolved:
thermal: int340x: fix memory leak in int3400_notify()
It is easy to hit the below memory leaks in my TigerLake platform:
unreferenced object 0xffff927c8b91dbc0 (size 32): comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s) hex dump (first 32 bytes): 4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The 72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk. backtrace: [<ffffffff9c502c3e>] __kmalloc_track_caller+0x2fe/0x4a0 [<ffffffff9c7b7c15>] kvasprintf+0x65/0xd0 [<ffffffff9c7b7d6e>] kasprintf+0x4e/0x70 [<ffffffffc04cb662>] int3400_notify+0x82/0x120 [int3400_thermal] [<ffffffff9c8b7358>] acpi_ev_notify_dispatch+0x54/0x71 [<ffffffff9c88f1a7>] acpi_os_execute_deferred+0x17/0x30 [<ffffffff9c2c2c0a>] process_one_work+0x21a/0x3f0 [<ffffffff9c2c2e2a>] worker_thread+0x4a/0x3b0 [<ffffffff9c2cb4dd>] kthread+0xfd/0x130 [<ffffffff9c201c1f>] ret_from_fork+0x1f/0x30
Fix it by calling kfree() accordingly.(CVE-2022-48924)
In the Linux kernel, the following vulnerability has been resolved:
iio: adc: men_z188_adc: Fix a resource leak in an error handling path
If iio_device_register() fails, a previous ioremap() is left unbalanced.
Update the error handling path and add the missing iounmap() call, as already done in the remove function.(CVE-2022-48928)
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: make apf token non-zero to fix bug
In current async pagefault logic, when a page is ready, KVM relies on kvm_arch_can_dequeue_async_page_present() to determine whether to deliver a READY event to the Guest. This function test token value of struct kvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when a READY event is finished by Guest. If value is zero meaning that a READY event is done, so the KVM can deliver another. But the kvm_arch_setup_async_pf() may produce a valid token with zero value, which is confused with previous mention and may lead the loss of this READY event.
This bug may cause task blocked forever in Guest: INFO: task stress:7532 blocked for more than 1254 seconds. Not tainted 5.10.0 #16 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:stress state:D stack: 0 pid: 7532 ppid: 1409 flags:0x00000080 Call Trace: __schedule+0x1e7/0x650 schedule+0x46/0xb0 kvm_async_pf_task_wait_schedule+0xad/0xe0 ? exit_to_user_mode_prepare+0x60/0x70 __kvm_handle_async_pf+0x4f/0xb0 ? asm_exc_page_fault+0x8/0x30 exc_page_fault+0x6f/0x110 ? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 RIP: 0033:0x402d00 RSP: 002b:00007ffd31912500 EFLAGS: 00010206 RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0 RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0 RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086 R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000 R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000(CVE-2022-48943)
In the Linux kernel, the following vulnerability has been resolved:
gsmi: fix null-deref in gsmi_get_variable
We can get EFI variables without fetching the attribute, so we must allow for that in gsmi.
commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi.(CVE-2023-52893)
In the Linux kernel, the following vulnerability has been resolved:
xhci: Fix null pointer dereference when host dies
Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race and cause null pointer dereference when host suddenly dies.
Usb core may call xhci_free_dev() which frees the xhci->devs[slot_id] virt device at the same time that xhci_kill_endpoint_urbs() tries to loop through all the device's endpoints, checking if there are any cancelled urbs left to give back.
hold the xhci spinlock while freeing the virt device(CVE-2023-52898)
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix general protection fault in nilfs_btree_insert()
If nilfs2 reads a corrupted disk image and tries to reads a b-tree node block by calling __nilfs_btree_get_block() against an invalid virtual block address, it returns -ENOENT because conversion of the virtual block address to a disk block address fails. However, this return value is the same as the internal code that b-tree lookup routines return to indicate that the block being searched does not exist, so functions that operate on that b-tree may misbehave.
When nilfs_btree_insert() receives this spurious 'not found' code from nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was successful and continues the insert operation using incomplete lookup path data, causing the following crash:
general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] ... RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline] RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline] RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238 Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02 ... Call Trace: <TASK> nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline] nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147 nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101 __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991 __block_write_begin fs/buffer.c:2041 [inline] block_write_begin+0x93/0x1e0 fs/buffer.c:2102 nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261 generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772 __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900 generic_file_write_iter+0xab/0x310 mm/filemap.c:3932 call_write_iter include/linux/fs.h:2186 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... </TASK>
This patch fixes the root cause of this problem by replacing the error code that __nilfs_btree_get_block() returns on block address conversion failure from -ENOENT to another internal code -EINVAL which means that the b-tree metadata is corrupted.
By returning -EINVAL, it propagates without glitches, and for all relevant b-tree operations, functions in the upper bmap layer output an error message indicating corrupted b-tree metadata via nilfs_bmap_convert_error(), and code -EIO will be eventually returned as it should be.(CVE-2023-52900)
In the Linux kernel, the following vulnerability has been resolved:
drivers: core: synchronize really_probe() and dev_uevent()
Synchronize the dev->driver usage in really_probe() and dev_uevent(). These can run in different threads, what can result in the following race condition for dev->driver uninitialization:
Thread #1:
really_probe() { ... probe_failed: ... device_unbind_cleanup(dev) { ... dev->driver = NULL; // <= Failed probe sets dev->driver to NULL ... } ... }
Thread #2:
dev_uevent() { ... if (dev->driver) // If dev->driver is NULLed from really_probe() from here on, // after above check, the system crashes add_uevent_var(env, "DRIVER=%s", dev->driver->name); ... }
really_probe() holds the lock, already. So nothing needs to be done there. dev_uevent() is called with lock held, often, too. But not always. What implies that we can't add any locking in dev_uevent() itself. So fix this race by adding the lock to the non-protected path. This is the path where above race is observed:
dev_uevent+0x235/0x380 uevent_show+0x10c/0x1f0 <= Add lock here dev_attr_show+0x3a/0xa0 sysfs_kf_seq_show+0x17c/0x250 kernfs_seq_show+0x7c/0x90 seq_read_iter+0x2d7/0x940 kernfs_fop_read_iter+0xc6/0x310 vfs_read+0x5bc/0x6b0 ksys_read+0xeb/0x1b0 __x64_sys_read+0x42/0x50 x64_sys_call+0x27ad/0x2d30 do_syscall_64+0xcd/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Similar cases are reported by syzkaller in
https://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a
But these are regarding the initialization of dev->driver
dev->driver = drv;
As this switches dev->driver to non-NULL these reports can be considered to be false-positives (which should be "fixed" by this commit, as well, though).
The same issue was reported and tried to be fixed back in 2015 in
https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/
already.(CVE-2024-39501)
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: add bounds checking to ocfs2_check_dir_entry()
This adds sanity checks for ocfs2_dir_entry to make sure all members of ocfs2_dir_entry don't stray beyond valid memory region.(CVE-2024-41015)
In the Linux kernel, the following vulnerability has been resolved:
s390/sclp: Fix sclp_init() cleanup on failure
If sclp_init() fails it only partially cleans up: if there are multiple failing calls to sclp_init() sclp_state_change_event will be added several times to sclp_reg_list, which results in the following warning:
------------[ cut here ]------------ list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10. WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3 Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 ... Call Trace: [<000003ffe0d6076a>] __list_add_valid_or_report+0xe2/0xf8 ([<000003ffe0d60766>] __list_add_valid_or_report+0xde/0xf8) [<000003ffe0a8d37e>] sclp_init+0x40e/0x450 [<000003ffe00009f2>] do_one_initcall+0x42/0x1e0 [<000003ffe15b77a6>] do_initcalls+0x126/0x150 [<000003ffe15b7a0a>] kernel_init_freeable+0x1ba/0x1f8 [<000003ffe0d6650e>] kernel_init+0x2e/0x180 [<000003ffe000301c>] __ret_from_fork+0x3c/0x60 [<000003ffe0d759ca>] ret_from_fork+0xa/0x30
Fix this by removing sclp_state_change_event from sclp_reg_list when sclp_init() fails.(CVE-2024-41068)
In the Linux kernel, the following vulnerability has been resolved:
i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr
When del_timer_sync() is called in an interrupt context it throws a warning because of potential deadlock. The timer is used only to exit from wait_for_completion() after a timeout so replacing the call with wait_for_completion_timeout() allows to remove the problematic timer and its related functions altogether.(CVE-2024-42153)
In the Linux kernel, the following vulnerability has been resolved:
protect the fetch of ->fd[fd] in do_dup2() from mispredictions
both callers have verified that fd is not greater than ->max_fds; however, misprediction might end up with tofree = fdt->fd[fd]; being speculatively executed. That's wrong for the same reasons why it's wrong in close_fd()/file_close_fd_locked(); the same solution applies - array_index_nospec(fd, fdt->max_fds) could differ from fd only in case of speculative execution on mispredicted path.(CVE-2024-42265)
In the Linux kernel, the following vulnerability has been resolved:
net/iucv: fix use after free in iucv_sock_close()
iucv_sever_path() is called from process context and from bh context. iucv->path is used as indicator whether somebody else is taking care of severing the path (or it is already removed / never existed). This needs to be done with atomic compare and swap, otherwise there is a small window where iucv_sock_close() will try to work with a path that has already been severed and freed by iucv_callback_connrej() called by iucv_tasklet_fn().
Example: [452744.123844] Call Trace: [452744.123845] ([<0000001e87f03880>] 0x1e87f03880) [452744.123966] [<00000000d593001e>] iucv_path_sever+0x96/0x138 [452744.124330] [<000003ff801ddbca>] iucv_sever_path+0xc2/0xd0 [af_iucv] [452744.124336] [<000003ff801e01b6>] iucv_sock_close+0xa6/0x310 [af_iucv] [452744.124341] [<000003ff801e08cc>] iucv_sock_release+0x3c/0xd0 [af_iucv] [452744.124345] [<00000000d574794e>] __sock_release+0x5e/0xe8 [452744.124815] [<00000000d5747a0c>] sock_close+0x34/0x48 [452744.124820] [<00000000d5421642>] __fput+0xba/0x268 [452744.124826] [<00000000d51b382c>] task_work_run+0xbc/0xf0 [452744.124832] [<00000000d5145710>] do_notify_resume+0x88/0x90 [452744.124841] [<00000000d5978096>] system_call+0xe2/0x2c8 [452744.125319] Last Breaking-Event-Address: [452744.125321] [<00000000d5930018>] iucv_path_sever+0x90/0x138 [452744.125324] [452744.125325] Kernel panic - not syncing: Fatal exception in interrupt
Note that bh_lock_sock() is not serializing the tasklet context against process context, because the check for sock_owned_by_user() and corresponding handling is missing.
Ideas for a future clean-up patch: A) Correct usage of bh_lock_sock() in tasklet context, as described in Re-enqueue, if needed. This may require adding return values to the tasklet functions and thus changes to all users of iucv.
B) Change iucv tasklet into worker and use only lock_sock() in af_iucv.(CVE-2024-42271)
In the Linux kernel, the following vulnerability has been resolved:
mISDN: Fix a use after free in hfcmulti_tx()
Don't dereference sp after calling dev_kfree_skb(sp).(CVE-2024-42280)
In the Linux kernel, the following vulnerability has been resolved:
tipc: Return non-zero value from tipc_udp_addr2str() on error
tipc_udp_addr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP media address.(CVE-2024-42284)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/iwcm: Fix a use-after-free related to destroying CM IDs
iw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with an existing struct iw_cm_id (cm_id) as follows:
conn_id->cm_id.iw = cm_id;
cm_id->context = conn_id;
cm_id->cm_handler = cma_iw_handler;
rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make sure that cm_work_handler() does not trigger a use-after-free by only freeing of the struct rdma_id_private after all pending work has finished.(CVE-2024-42285)
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: During vport delete send async logout explicitly
During vport delete, it is observed that during unload we hit a crash because of stale entries in outstanding command array. For all these stale I/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but I/Os could not complete while vport delete is in process of deleting.
BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI Workqueue: qla2xxx_wq qla_do_work [qla2xxx] RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0 RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8 R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0 Call Trace: <TASK> qla2xxx_qpair_sp_free_dma+0x417/0x4e0 ? qla2xxx_qpair_sp_compl+0x10d/0x1a0 ? qla2x00_status_entry+0x768/0x2830 ? newidle_balance+0x2f0/0x430 ? dequeue_entity+0x100/0x3c0 ? qla24xx_process_response_queue+0x6a1/0x19e0 ? __schedule+0x2d5/0x1140 ? qla_do_work+0x47/0x60 ? process_one_work+0x267/0x440 ? process_one_work+0x440/0x440 ? worker_thread+0x2d/0x3d0 ? process_one_work+0x440/0x440 ? kthread+0x156/0x180 ? set_kthread_struct+0x50/0x50 ? ret_from_fork+0x22/0x30 </TASK>
Send out async logout explicitly for all the ports during vport delete.(CVE-2024-42289)
In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to don't dirty inode for readonly filesystem
syzbot reports f2fs bug as below:
kernel BUG at fs/f2fs/inode.c:933! RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933 Call Trace: evict+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [inline] evict_inodes+0x5f8/0x690 fs/inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 deactivate_locked_super+0xc1/0x130 fs/super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h:411 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] syscall_exit_work kernel/entry/common.c:251 [inline] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6b
The root cause is: - do_sys_open - f2fs_lookup - __f2fs_find_entry - f2fs_i_depth_write - f2fs_mark_inode_dirty_sync - f2fs_dirty_inode - set_inode_flag(inode, FI_DIRTY_INODE)
- umount
- kill_f2fs_super
- kill_block_super
- generic_shutdown_super
- sync_filesystem : sb is readonly, skip sync_filesystem()
- evict_inodes
- iput
- f2fs_evict_inode
- f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) : trigger kernel panic
When we try to repair i_current_depth in readonly filesystem, let's skip dirty inode to avoid panic in later f2fs_evict_inode().(CVE-2024-42297)
In the Linux kernel, the following vulnerability has been resolved:
ext4: check dot and dotdot of dx_root before making dir indexed
Syzbot reports a issue as follows:
BUG: unable to handle page fault for address: ffffed11022e24fe PGD 23ffee067 P4D 23ffee067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0 Call Trace: <TASK> make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [inline] ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214 [...] ============================================
The immediate cause of this problem is that there is only one valid dentry for the block to be split during do_split, so split==0 results in out of bounds accesses to the map triggering the issue.
do_split
unsigned split
dx_make_map
count = 1
split = count/2 = 0;
continued = hash2 == map[split - 1].hash;
---> map[4294967295]
The maximum length of a filename is 255 and the minimum block size is 1024, so it is always guaranteed that the number of entries is greater than or equal to 2 when do_split() is called.
But syzbot's crafted image has no dot and dotdot in dir, and the dentry distribution in dirblock is as follows:
bus dentry1 hole dentry2 free |xx--|xx-------------|...............|xx-------------|...............| 0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024
So when renaming dentry1 increases its name_len length by 1, neither hole nor free is sufficient to hold the new dentry, and make_indexed_dir() is called.
In make_indexed_dir() it is assumed that the first two entries of the dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root because they are treated as dot and dotdot, and only dentry2 is moved to the new leaf block. That's why count is equal to 1.
Therefore add the ext4_check_dx_root() helper function to add more sanity checks to dot and dotdot before starting the conversion to avoid the above issue.(CVE-2024-42305)
In the Linux kernel, the following vulnerability has been resolved:
net: usb: qmi_wwan: fix memory leak for not ip packets
Free the unused skb when not ip packets arrive.(CVE-2024-43861)
In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()
Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning:
kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]
Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.(CVE-2024-43879)
In the Linux kernel, the following vulnerability has been resolved:
exec: Fix ToCToU between perm check and set-uid/gid usage
When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges.
For example, if a file could change permissions from executable and not set-id:
---------x 1 root root 16048 Aug 7 13:16 target
to set-id and non-executable:
---S------ 1 root root 16048 Aug 7 13:16 target
it is possible to gain root privileges when execution should have been disallowed.
While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root:
-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target
becomes:
-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target
But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root".
Re-check that we still have execute permissions in case the metadata has changed. It would be better to keep a copy from the perm-check time, but until we can do that refactoring, the least-bad option is to do a full inode_permission() call (under inode lock). It is understood that this is safe against dead-locks, but hardly optimal.(CVE-2024-43882)
{
"affected": [
{
"ecosystem_specific": {
"aarch64": [
"bpftool-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"bpftool-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"kernel-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"kernel-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"kernel-debugsource-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"kernel-devel-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"kernel-source-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"kernel-tools-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"kernel-tools-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"kernel-tools-devel-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"perf-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"python2-perf-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"python2-perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"python3-perf-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
"python3-perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm"
],
"src": [
"kernel-4.19.90-2408.5.0.0292.oe2003sp4.src.rpm"
],
"x86_64": [
"bpftool-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"bpftool-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"kernel-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"kernel-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"kernel-debugsource-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"kernel-devel-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"kernel-source-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"kernel-tools-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"kernel-tools-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"kernel-tools-devel-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"perf-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"python2-perf-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"python2-perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"python3-perf-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
"python3-perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm"
]
},
"package": {
"ecosystem": "openEuler:20.03-LTS-SP4",
"name": "kernel",
"purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.19.90-2408.5.0.0292.oe2003sp4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"severity": "High"
},
"details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nparisc: Fix data TLB miss in sba_unmap_sg\r\n\r\nRolf Eike Beer reported the following bug:\r\n\r\n[1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018\n[1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4\n[1274934.746891] Hardware name: 9000/785/C8000\n[1274934.746891]\n[1274934.746891] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI\n[1274934.746891] PSW: 00001000000001001111111000001110 Not tainted\n[1274934.746891] r00-03 000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000\n[1274934.746891] r04-07 0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001\n[1274934.746891] r08-11 0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001\n[1274934.746891] r12-15 0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0\n[1274934.746891] r16-19 0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007\n[1274934.746891] r20-23 0000000000000006 000000004a368950 0000000000000000 0000000000000001\n[1274934.746891] r24-27 0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0\n[1274934.746891] r28-31 0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118\n[1274934.746891] sr00-03 00000000066e5800 0000000000000000 0000000000000000 00000000066e5800\n[1274934.746891] sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000\n[1274934.746891]\n[1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec\n[1274934.746891] IIR: 48780030 ISR: 0000000000000000 IOR: 0000004140000018\n[1274934.746891] CPU: 3 CR30: 00000040e3a9c000 CR31: ffffffffffffffff\n[1274934.746891] ORIG_R28: 0000000040acdd58\n[1274934.746891] IAOQ[0]: sba_unmap_sg+0xb0/0x118\n[1274934.746891] IAOQ[1]: sba_unmap_sg+0xb4/0x118\n[1274934.746891] RP(r2): sba_unmap_sg+0xac/0x118\n[1274934.746891] Backtrace:\n[1274934.746891] [\u0026lt;00000000402740cc\u0026gt;] dma_unmap_sg_attrs+0x6c/0x70\n[1274934.746891] [\u0026lt;000000004074d6bc\u0026gt;] scsi_dma_unmap+0x54/0x60\n[1274934.746891] [\u0026lt;00000000407a3488\u0026gt;] mptscsih_io_done+0x150/0xd70\n[1274934.746891] [\u0026lt;0000000040798600\u0026gt;] mpt_interrupt+0x168/0xa68\n[1274934.746891] [\u0026lt;0000000040255a48\u0026gt;] __handle_irq_event_percpu+0xc8/0x278\n[1274934.746891] [\u0026lt;0000000040255c34\u0026gt;] handle_irq_event_percpu+0x3c/0xd8\n[1274934.746891] [\u0026lt;000000004025ecb4\u0026gt;] handle_percpu_irq+0xb4/0xf0\n[1274934.746891] [\u0026lt;00000000402548e0\u0026gt;] generic_handle_irq+0x50/0x70\n[1274934.746891] [\u0026lt;000000004019a254\u0026gt;] call_on_stack+0x18/0x24\n[1274934.746891]\n[1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?)\r\n\r\nThe bug is caused by overrunning the sglist and incorrectly testing\nsg_dma_len(sglist) before nents. Normally this doesn\u0026apos;t cause a crash,\nbut in this case sglist crossed a page boundary. This occurs in the\nfollowing code:\r\n\r\n\twhile (sg_dma_len(sglist) \u0026amp;\u0026amp; nents--) {\r\n\r\nThe fix is simply to test nents first and move the decrement of nents\ninto the loop.(CVE-2022-48795)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/virtio: Fix GEM handle creation UAF\r\n\r\nUserspace can guess the handle value and try to race GEM object creation\nwith handle close, resulting in a use-after-free if we dereference the\nobject after dropping the handle\u0026apos;s reference. For that reason, dropping\nthe handle\u0026apos;s reference must be done *after* we are done dereferencing\nthe object.(CVE-2022-48899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthermal: int340x: fix memory leak in int3400_notify()\r\n\r\nIt is easy to hit the below memory leaks in my TigerLake platform:\r\n\r\nunreferenced object 0xffff927c8b91dbc0 (size 32):\n comm \u0026quot;kworker/0:2\u0026quot;, pid 112, jiffies 4294893323 (age 83.604s)\n hex dump (first 32 bytes):\n 4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The\n 72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk.\n backtrace:\n [\u0026lt;ffffffff9c502c3e\u0026gt;] __kmalloc_track_caller+0x2fe/0x4a0\n [\u0026lt;ffffffff9c7b7c15\u0026gt;] kvasprintf+0x65/0xd0\n [\u0026lt;ffffffff9c7b7d6e\u0026gt;] kasprintf+0x4e/0x70\n [\u0026lt;ffffffffc04cb662\u0026gt;] int3400_notify+0x82/0x120 [int3400_thermal]\n [\u0026lt;ffffffff9c8b7358\u0026gt;] acpi_ev_notify_dispatch+0x54/0x71\n [\u0026lt;ffffffff9c88f1a7\u0026gt;] acpi_os_execute_deferred+0x17/0x30\n [\u0026lt;ffffffff9c2c2c0a\u0026gt;] process_one_work+0x21a/0x3f0\n [\u0026lt;ffffffff9c2c2e2a\u0026gt;] worker_thread+0x4a/0x3b0\n [\u0026lt;ffffffff9c2cb4dd\u0026gt;] kthread+0xfd/0x130\n [\u0026lt;ffffffff9c201c1f\u0026gt;] ret_from_fork+0x1f/0x30\r\n\r\nFix it by calling kfree() accordingly.(CVE-2022-48924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: adc: men_z188_adc: Fix a resource leak in an error handling path\r\n\r\nIf iio_device_register() fails, a previous ioremap() is left unbalanced.\r\n\r\nUpdate the error handling path and add the missing iounmap() call, as\nalready done in the remove function.(CVE-2022-48928)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: x86/mmu: make apf token non-zero to fix bug\r\n\r\nIn current async pagefault logic, when a page is ready, KVM relies on\nkvm_arch_can_dequeue_async_page_present() to determine whether to deliver\na READY event to the Guest. This function test token value of struct\nkvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when a\nREADY event is finished by Guest. If value is zero meaning that a READY\nevent is done, so the KVM can deliver another.\nBut the kvm_arch_setup_async_pf() may produce a valid token with zero\nvalue, which is confused with previous mention and may lead the loss of\nthis READY event.\r\n\r\nThis bug may cause task blocked forever in Guest:\n INFO: task stress:7532 blocked for more than 1254 seconds.\n Not tainted 5.10.0 #16\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:stress state:D stack: 0 pid: 7532 ppid: 1409\n flags:0x00000080\n Call Trace:\n __schedule+0x1e7/0x650\n schedule+0x46/0xb0\n kvm_async_pf_task_wait_schedule+0xad/0xe0\n ? exit_to_user_mode_prepare+0x60/0x70\n __kvm_handle_async_pf+0x4f/0xb0\n ? asm_exc_page_fault+0x8/0x30\n exc_page_fault+0x6f/0x110\n ? asm_exc_page_fault+0x8/0x30\n asm_exc_page_fault+0x1e/0x30\n RIP: 0033:0x402d00\n RSP: 002b:00007ffd31912500 EFLAGS: 00010206\n RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0\n RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0\n RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086\n R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000\n R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000(CVE-2022-48943)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngsmi: fix null-deref in gsmi_get_variable\r\n\r\nWe can get EFI variables without fetching the attribute, so we must\nallow for that in gsmi.\r\n\r\ncommit 859748255b43 (\u0026quot;efi: pstore: Omit efivars caching EFI varstore\naccess layer\u0026quot;) added a new get_variable call with attr=NULL, which\ntriggers panic in gsmi.(CVE-2023-52893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxhci: Fix null pointer dereference when host dies\r\n\r\nMake sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race\nand cause null pointer dereference when host suddenly dies.\r\n\r\nUsb core may call xhci_free_dev() which frees the xhci-\u0026gt;devs[slot_id]\nvirt device at the same time that xhci_kill_endpoint_urbs() tries to\nloop through all the device\u0026apos;s endpoints, checking if there are any\ncancelled urbs left to give back.\r\n\r\nhold the xhci spinlock while freeing the virt device(CVE-2023-52898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix general protection fault in nilfs_btree_insert()\r\n\r\nIf nilfs2 reads a corrupted disk image and tries to reads a b-tree node\nblock by calling __nilfs_btree_get_block() against an invalid virtual\nblock address, it returns -ENOENT because conversion of the virtual block\naddress to a disk block address fails. However, this return value is the\nsame as the internal code that b-tree lookup routines return to indicate\nthat the block being searched does not exist, so functions that operate on\nthat b-tree may misbehave.\r\n\r\nWhen nilfs_btree_insert() receives this spurious \u0026apos;not found\u0026apos; code from\nnilfs_btree_do_lookup(), it misunderstands that the \u0026apos;not found\u0026apos; check was\nsuccessful and continues the insert operation using incomplete lookup path\ndata, causing the following crash:\r\n\r\n general protection fault, probably for non-canonical address\n 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN\n KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n ...\n RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]\n RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]\n RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238\n Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89\n ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 \u0026lt;42\u0026gt; 80 3c\n 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]\n nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147\n nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101\n __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991\n __block_write_begin fs/buffer.c:2041 [inline]\n block_write_begin+0x93/0x1e0 fs/buffer.c:2102\n nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261\n generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772\n __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900\n generic_file_write_iter+0xab/0x310 mm/filemap.c:3932\n call_write_iter include/linux/fs.h:2186 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x7dc/0xc50 fs/read_write.c:584\n ksys_write+0x177/0x2a0 fs/read_write.c:637\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n ...\n \u0026lt;/TASK\u0026gt;\r\n\r\nThis patch fixes the root cause of this problem by replacing the error\ncode that __nilfs_btree_get_block() returns on block address conversion\nfailure from -ENOENT to another internal code -EINVAL which means that the\nb-tree metadata is corrupted.\r\n\r\nBy returning -EINVAL, it propagates without glitches, and for all relevant\nb-tree operations, functions in the upper bmap layer output an error\nmessage indicating corrupted b-tree metadata via\nnilfs_bmap_convert_error(), and code -EIO will be eventually returned as\nit should be.(CVE-2023-52900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers: core: synchronize really_probe() and dev_uevent()\r\n\r\nSynchronize the dev-\u0026gt;driver usage in really_probe() and dev_uevent().\nThese can run in different threads, what can result in the following\nrace condition for dev-\u0026gt;driver uninitialization:\r\n\r\nThread #1:\n==========\r\n\r\nreally_probe() {\n...\nprobe_failed:\n...\ndevice_unbind_cleanup(dev) {\n ...\n dev-\u0026gt;driver = NULL; // \u0026lt;= Failed probe sets dev-\u0026gt;driver to NULL\n ...\n }\n...\n}\r\n\r\nThread #2:\n==========\r\n\r\ndev_uevent() {\n...\nif (dev-\u0026gt;driver)\n // If dev-\u0026gt;driver is NULLed from really_probe() from here on,\n // after above check, the system crashes\n add_uevent_var(env, \u0026quot;DRIVER=%s\u0026quot;, dev-\u0026gt;driver-\u0026gt;name);\n...\n}\r\n\r\nreally_probe() holds the lock, already. So nothing needs to be done\nthere. dev_uevent() is called with lock held, often, too. But not\nalways. What implies that we can\u0026apos;t add any locking in dev_uevent()\nitself. So fix this race by adding the lock to the non-protected\npath. This is the path where above race is observed:\r\n\r\n dev_uevent+0x235/0x380\n uevent_show+0x10c/0x1f0 \u0026lt;= Add lock here\n dev_attr_show+0x3a/0xa0\n sysfs_kf_seq_show+0x17c/0x250\n kernfs_seq_show+0x7c/0x90\n seq_read_iter+0x2d7/0x940\n kernfs_fop_read_iter+0xc6/0x310\n vfs_read+0x5bc/0x6b0\n ksys_read+0xeb/0x1b0\n __x64_sys_read+0x42/0x50\n x64_sys_call+0x27ad/0x2d30\n do_syscall_64+0xcd/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nSimilar cases are reported by syzkaller in\r\n\r\nhttps://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a\r\n\r\nBut these are regarding the *initialization* of dev-\u0026gt;driver\r\n\r\ndev-\u0026gt;driver = drv;\r\n\r\nAs this switches dev-\u0026gt;driver to non-NULL these reports can be considered\nto be false-positives (which should be \u0026quot;fixed\u0026quot; by this commit, as well,\nthough).\r\n\r\nThe same issue was reported and tried to be fixed back in 2015 in\r\n\r\nhttps://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/\r\n\r\nalready.(CVE-2024-39501)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: add bounds checking to ocfs2_check_dir_entry()\r\n\r\nThis adds sanity checks for ocfs2_dir_entry to make sure all members of\nocfs2_dir_entry don\u0026apos;t stray beyond valid memory region.(CVE-2024-41015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/sclp: Fix sclp_init() cleanup on failure\r\n\r\nIf sclp_init() fails it only partially cleans up: if there are multiple\nfailing calls to sclp_init() sclp_state_change_event will be added several\ntimes to sclp_reg_list, which results in the following warning:\r\n\r\n------------[ cut here ]------------\nlist_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.\nWARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8\nCPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3\nKrnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8)\n R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3\n...\nCall Trace:\n [\u0026lt;000003ffe0d6076a\u0026gt;] __list_add_valid_or_report+0xe2/0xf8\n([\u0026lt;000003ffe0d60766\u0026gt;] __list_add_valid_or_report+0xde/0xf8)\n [\u0026lt;000003ffe0a8d37e\u0026gt;] sclp_init+0x40e/0x450\n [\u0026lt;000003ffe00009f2\u0026gt;] do_one_initcall+0x42/0x1e0\n [\u0026lt;000003ffe15b77a6\u0026gt;] do_initcalls+0x126/0x150\n [\u0026lt;000003ffe15b7a0a\u0026gt;] kernel_init_freeable+0x1ba/0x1f8\n [\u0026lt;000003ffe0d6650e\u0026gt;] kernel_init+0x2e/0x180\n [\u0026lt;000003ffe000301c\u0026gt;] __ret_from_fork+0x3c/0x60\n [\u0026lt;000003ffe0d759ca\u0026gt;] ret_from_fork+0xa/0x30\r\n\r\nFix this by removing sclp_state_change_event from sclp_reg_list when\nsclp_init() fails.(CVE-2024-41068)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr\r\n\r\nWhen del_timer_sync() is called in an interrupt context it throws a warning\nbecause of potential deadlock. The timer is used only to exit from\nwait_for_completion() after a timeout so replacing the call with\nwait_for_completion_timeout() allows to remove the problematic timer and\nits related functions altogether.(CVE-2024-42153)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nprotect the fetch of -\u0026gt;fd[fd] in do_dup2() from mispredictions\r\n\r\nboth callers have verified that fd is not greater than -\u0026gt;max_fds;\nhowever, misprediction might end up with\n tofree = fdt-\u0026gt;fd[fd];\nbeing speculatively executed. That\u0026apos;s wrong for the same reasons\nwhy it\u0026apos;s wrong in close_fd()/file_close_fd_locked(); the same\nsolution applies - array_index_nospec(fd, fdt-\u0026gt;max_fds) could differ\nfrom fd only in case of speculative execution on mispredicted path.(CVE-2024-42265)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/iucv: fix use after free in iucv_sock_close()\r\n\r\niucv_sever_path() is called from process context and from bh context.\niucv-\u0026gt;path is used as indicator whether somebody else is taking care of\nsevering the path (or it is already removed / never existed).\nThis needs to be done with atomic compare and swap, otherwise there is a\nsmall window where iucv_sock_close() will try to work with a path that has\nalready been severed and freed by iucv_callback_connrej() called by\niucv_tasklet_fn().\r\n\r\nExample:\n[452744.123844] Call Trace:\n[452744.123845] ([\u0026lt;0000001e87f03880\u0026gt;] 0x1e87f03880)\n[452744.123966] [\u0026lt;00000000d593001e\u0026gt;] iucv_path_sever+0x96/0x138\n[452744.124330] [\u0026lt;000003ff801ddbca\u0026gt;] iucv_sever_path+0xc2/0xd0 [af_iucv]\n[452744.124336] [\u0026lt;000003ff801e01b6\u0026gt;] iucv_sock_close+0xa6/0x310 [af_iucv]\n[452744.124341] [\u0026lt;000003ff801e08cc\u0026gt;] iucv_sock_release+0x3c/0xd0 [af_iucv]\n[452744.124345] [\u0026lt;00000000d574794e\u0026gt;] __sock_release+0x5e/0xe8\n[452744.124815] [\u0026lt;00000000d5747a0c\u0026gt;] sock_close+0x34/0x48\n[452744.124820] [\u0026lt;00000000d5421642\u0026gt;] __fput+0xba/0x268\n[452744.124826] [\u0026lt;00000000d51b382c\u0026gt;] task_work_run+0xbc/0xf0\n[452744.124832] [\u0026lt;00000000d5145710\u0026gt;] do_notify_resume+0x88/0x90\n[452744.124841] [\u0026lt;00000000d5978096\u0026gt;] system_call+0xe2/0x2c8\n[452744.125319] Last Breaking-Event-Address:\n[452744.125321] [\u0026lt;00000000d5930018\u0026gt;] iucv_path_sever+0x90/0x138\n[452744.125324]\n[452744.125325] Kernel panic - not syncing: Fatal exception in interrupt\r\n\r\nNote that bh_lock_sock() is not serializing the tasklet context against\nprocess context, because the check for sock_owned_by_user() and\ncorresponding handling is missing.\r\n\r\nIdeas for a future clean-up patch:\nA) Correct usage of bh_lock_sock() in tasklet context, as described in\nRe-enqueue, if needed. This may require adding return values to the\ntasklet functions and thus changes to all users of iucv.\r\n\r\nB) Change iucv tasklet into worker and use only lock_sock() in af_iucv.(CVE-2024-42271)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmISDN: Fix a use after free in hfcmulti_tx()\r\n\r\nDon\u0026apos;t dereference *sp after calling dev_kfree_skb(*sp).(CVE-2024-42280)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: Return non-zero value from tipc_udp_addr2str() on error\r\n\r\ntipc_udp_addr2str() should return non-zero value if the UDP media\naddress is invalid. Otherwise, a buffer overflow access can occur in\ntipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP\nmedia address.(CVE-2024-42284)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/iwcm: Fix a use-after-free related to destroying CM IDs\r\n\r\niw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with\nan existing struct iw_cm_id (cm_id) as follows:\r\n\r\n conn_id-\u0026gt;cm_id.iw = cm_id;\n cm_id-\u0026gt;context = conn_id;\n cm_id-\u0026gt;cm_handler = cma_iw_handler;\r\n\r\nrdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make\nsure that cm_work_handler() does not trigger a use-after-free by only\nfreeing of the struct rdma_id_private after all pending work has finished.(CVE-2024-42285)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: During vport delete send async logout explicitly\r\n\r\nDuring vport delete, it is observed that during unload we hit a crash\nbecause of stale entries in outstanding command array. For all these stale\nI/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but\nI/Os could not complete while vport delete is in process of deleting.\r\n\r\n BUG: kernel NULL pointer dereference, address: 000000000000001c\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n Workqueue: qla2xxx_wq qla_do_work [qla2xxx]\n RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0\n RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046\n RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001\n RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0\n RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8\n R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000\n R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000\n FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0\n Call Trace:\n \u0026lt;TASK\u0026gt;\n qla2xxx_qpair_sp_free_dma+0x417/0x4e0\n ? qla2xxx_qpair_sp_compl+0x10d/0x1a0\n ? qla2x00_status_entry+0x768/0x2830\n ? newidle_balance+0x2f0/0x430\n ? dequeue_entity+0x100/0x3c0\n ? qla24xx_process_response_queue+0x6a1/0x19e0\n ? __schedule+0x2d5/0x1140\n ? qla_do_work+0x47/0x60\n ? process_one_work+0x267/0x440\n ? process_one_work+0x440/0x440\n ? worker_thread+0x2d/0x3d0\n ? process_one_work+0x440/0x440\n ? kthread+0x156/0x180\n ? set_kthread_struct+0x50/0x50\n ? ret_from_fork+0x22/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nSend out async logout explicitly for all the ports during vport delete.(CVE-2024-42289)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to don\u0026apos;t dirty inode for readonly filesystem\r\n\r\nsyzbot reports f2fs bug as below:\r\n\r\nkernel BUG at fs/f2fs/inode.c:933!\nRIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933\nCall Trace:\n evict+0x2a4/0x620 fs/inode.c:664\n dispose_list fs/inode.c:697 [inline]\n evict_inodes+0x5f8/0x690 fs/inode.c:747\n generic_shutdown_super+0x9d/0x2c0 fs/super.c:675\n kill_block_super+0x44/0x90 fs/super.c:1667\n kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894\n deactivate_locked_super+0xc1/0x130 fs/super.c:484\n cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256\n task_work_run+0x24a/0x300 kernel/task_work.c:180\n ptrace_notify+0x2cd/0x380 kernel/signal.c:2399\n ptrace_report_syscall include/linux/ptrace.h:411 [inline]\n ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline]\n syscall_exit_work kernel/entry/common.c:251 [inline]\n syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline]\n syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296\n do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nThe root cause is:\n- do_sys_open\n - f2fs_lookup\n - __f2fs_find_entry\n - f2fs_i_depth_write\n - f2fs_mark_inode_dirty_sync\n - f2fs_dirty_inode\n - set_inode_flag(inode, FI_DIRTY_INODE)\r\n\r\n- umount\n - kill_f2fs_super\n - kill_block_super\n - generic_shutdown_super\n - sync_filesystem\n : sb is readonly, skip sync_filesystem()\n - evict_inodes\n - iput\n - f2fs_evict_inode\n - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE))\n : trigger kernel panic\r\n\r\nWhen we try to repair i_current_depth in readonly filesystem, let\u0026apos;s\nskip dirty inode to avoid panic in later f2fs_evict_inode().(CVE-2024-42297)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: check dot and dotdot of dx_root before making dir indexed\r\n\r\nSyzbot reports a issue as follows:\n============================================\nBUG: unable to handle page fault for address: ffffed11022e24fe\nPGD 23ffee067 P4D 23ffee067 PUD 0\nOops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341\n ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451\n ext4_rename fs/ext4/namei.c:3936 [inline]\n ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214\n[...]\n============================================\r\n\r\nThe immediate cause of this problem is that there is only one valid dentry\nfor the block to be split during do_split, so split==0 results in out of\nbounds accesses to the map triggering the issue.\r\n\r\n do_split\n unsigned split\n dx_make_map\n count = 1\n split = count/2 = 0;\n continued = hash2 == map[split - 1].hash;\n ---\u0026gt; map[4294967295]\r\n\r\nThe maximum length of a filename is 255 and the minimum block size is 1024,\nso it is always guaranteed that the number of entries is greater than or\nequal to 2 when do_split() is called.\r\n\r\nBut syzbot\u0026apos;s crafted image has no dot and dotdot in dir, and the dentry\ndistribution in dirblock is as follows:\r\n\r\n bus dentry1 hole dentry2 free\n|xx--|xx-------------|...............|xx-------------|...............|\n0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024\r\n\r\nSo when renaming dentry1 increases its name_len length by 1, neither hole\nnor free is sufficient to hold the new dentry, and make_indexed_dir() is\ncalled.\r\n\r\nIn make_indexed_dir() it is assumed that the first two entries of the\ndirblock must be dot and dotdot, so bus and dentry1 are left in dx_root\nbecause they are treated as dot and dotdot, and only dentry2 is moved\nto the new leaf block. That\u0026apos;s why count is equal to 1.\r\n\r\nTherefore add the ext4_check_dx_root() helper function to add more sanity\nchecks to dot and dotdot before starting the conversion to avoid the above\nissue.(CVE-2024-42305)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: usb: qmi_wwan: fix memory leak for not ip packets\r\n\r\nFree the unused skb when not ip packets arrive.(CVE-2024-43861)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()\r\n\r\nCurrently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in\ncfg80211_calculate_bitrate_he(), leading to below warning:\r\n\r\nkernel: invalid HE MCS: bw:6, ru:6\nkernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]\r\n\r\nFix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.(CVE-2024-43879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nexec: Fix ToCToU between perm check and set-uid/gid usage\r\n\r\nWhen opening a file for exec via do_filp_open(), permission checking is\ndone against the file\u0026apos;s metadata at that moment, and on success, a file\npointer is passed back. Much later in the execve() code path, the file\nmetadata (specifically mode, uid, and gid) is used to determine if/how\nto set the uid and gid. However, those values may have changed since the\npermissions check, meaning the execution may gain unintended privileges.\r\n\r\nFor example, if a file could change permissions from executable and not\nset-id:\r\n\r\n---------x 1 root root 16048 Aug 7 13:16 target\r\n\r\nto set-id and non-executable:\r\n\r\n---S------ 1 root root 16048 Aug 7 13:16 target\r\n\r\nit is possible to gain root privileges when execution should have been\ndisallowed.\r\n\r\nWhile this race condition is rare in real-world scenarios, it has been\nobserved (and proven exploitable) when package managers are updating\nthe setuid bits of installed programs. Such files start with being\nworld-executable but then are adjusted to be group-exec with a set-uid\nbit. For example, \u0026quot;chmod o-x,u+s target\u0026quot; makes \u0026quot;target\u0026quot; executable only\nby uid \u0026quot;root\u0026quot; and gid \u0026quot;cdrom\u0026quot;, while also becoming setuid-root:\r\n\r\n-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target\r\n\r\nbecomes:\r\n\r\n-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target\r\n\r\nBut racing the chmod means users without group \u0026quot;cdrom\u0026quot; membership can\nget the permission to execute \u0026quot;target\u0026quot; just before the chmod, and when\nthe chmod finishes, the exec reaches brpm_fill_uid(), and performs the\nsetuid to root, violating the expressed authorization of \u0026quot;only cdrom\ngroup members can setuid to root\u0026quot;.\r\n\r\nRe-check that we still have execute permissions in case the metadata\nhas changed. It would be better to keep a copy from the perm-check time,\nbut until we can do that refactoring, the least-bad option is to do a\nfull inode_permission() call (under inode lock). It is understood that\nthis is safe against dead-locks, but hardly optimal.(CVE-2024-43882)",
"id": "OESA-2024-2079",
"modified": "2026-08-06T11:07:33Z",
"published": "2024-08-30T11:07:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2079"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48795"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48899"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48924"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48928"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48943"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52893"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52898"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52900"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39501"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41015"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41068"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42153"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42265"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42271"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42280"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42284"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42285"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42289"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42297"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42305"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43861"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43879"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43882"
}
],
"schema_version": "1.7.2",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "kernel security update",
"upstream": [
"CVE-2022-48795",
"CVE-2022-48899",
"CVE-2022-48924",
"CVE-2022-48928",
"CVE-2022-48943",
"CVE-2023-52893",
"CVE-2023-52898",
"CVE-2023-52900",
"CVE-2024-39501",
"CVE-2024-41015",
"CVE-2024-41068",
"CVE-2024-42153",
"CVE-2024-42265",
"CVE-2024-42271",
"CVE-2024-42280",
"CVE-2024-42284",
"CVE-2024-42285",
"CVE-2024-42289",
"CVE-2024-42297",
"CVE-2024-42305",
"CVE-2024-43861",
"CVE-2024-43879",
"CVE-2024-43882"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.