Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ario is that the main process spawns number of new threads, which then call setpriority(PRIO_PGRP, 0, -20), wait, and exit. For each of the new threads the copy_process() gets invoked, which adds the new task_struct and calls sched_post_fork() for it. In the above scenario there is a possibility that setpriority(PRIO_PGRP) and set_one_prio() will be called for a thread in the group that is just being created by copy_process(), and for which the sched_post_fork() has not been executed yet. This will trigger a null pointer dereference in reweight_entity(), as it will try to access the run queue pointer, which hasn't been set. Before the mentioned change the cfs_rq pointer for the task has been
ccess the run queue pointer, which hasn't been set. Before the mentioned change the cfs_rq pointer for the task has been set in sched_fork(), which is called much earlier in copy_process(), before the new task is added to the thread_group. Now it is done in the sched_post_fork(), which is called after that. To fix the issue the remove the update_load param from the update_load param() function and call reweight_task() only if the task flag doesn't have the TASK_NEW flag set. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/8f317cd888059c59e2fa924bf4b0957cfa53f78e - https://git.kernel.org/stable/c/e0bcd6b5779352aed88f2e538a82a39f1a7715bb - https
17cd888059c59e2fa924bf4b0957cfa53f78e - https://git.kernel.org/stable/c/e0bcd6b5779352aed88f2e538a82a39f1a7715bb - https://git.kernel.org/stable/c/589a954daab5e18399860b6c8ffaeaf79844eb20 - https://git.kernel.org/stable/c/13765de8148f71fa795e0a6607de37c49ea5915a
CVE ID: CVE-2022-48922 State: PUBLISHED Published: 2024-08-22T01:32:55.803Z Last Updated: 2025-05-04T08:26:09.859Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: riscv: fix oops caused by irqsoff latency tracer The trace_hardirqs_{on,off}() require the caller to setup frame pointer properly. This because these two functions use macro 'CALLER_ADDR1' (aka. __builtin_return_address(1)) to acquire caller info. If the $fp is used for other purpose, the code generated this macro (as below) could trigger memory access fault. 0xffffffff8011510e <+80>: ld a1,-16(s0) 0xffffffff80115112 <+84>: ld s2,-8(a1) # <-- paging fault here The oops
s fault. 0xffffffff8011510e <+80>: ld a1,-16(s0) 0xffffffff80115112 <+84>: ld s2,-8(a1) # <-- paging fault here The oops message during booting if compiled with 'irqoff' tracer enabled: [ 0.039615][ T0] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 [ 0.041925][ T0] Oops [#1] [ 0.042063][ T0] Modules linked in: [ 0.042864][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc1-00233-g9a20c48d1ed2 #29 [ 0.043568][ T0] Hardware name: riscv-virtio,qemu (DT) [ 0.044343][ T0] epc : trace_hardirqs_on+0x56/0xe2 [ 0.044601][ T0] ra : restore_all+0x12/0x6e [ 0.044721][ T0] epc : ffffffff80126a5c ra : ffffffff80003b94 sp : ffffffff81403db0 [ 0.044801][ T0] gp :
_all+0x12/0x6e [ 0.044721][ T0] epc : ffffffff80126a5c ra : ffffffff80003b94 sp : ffffffff81403db0 [ 0.044801][ T0] gp : ffffffff8163acd8 tp : ffffffff81414880 t0 : 0000000000000020 [ 0.044882][ T0] t1 : 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0 [ 0.044967][ T0] s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100 [ 0.045046][ T0] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000 [ 0.045124][ T0] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000054494d45 [ 0.045210][ T0] s2 : ffffffff80003b94 s3 : ffffffff81a8f1b0 s4 : ffffffff80e27b50 [ 0.045289][ T0] s5 : ffffffff81414880 s6 : ffffffff8160fa00 s7 : 00000000800120e8 [ 0.045389][ T0] s8
ffffffff80e27b50 [ 0.045289][ T0] s5 : ffffffff81414880 s6 : ffffffff8160fa00 s7 : 00000000800120e8 [ 0.045389][ T0] s8 : 0000000080013100 s9 : 000000000000007f s10: 0000000000000000 [ 0.045474][ T0] s11: 0000000000000000 t3 : 7fffffffffffffff t4 : 0000000000000000 [ 0.045548][ T0] t5 : 0000000000000000 t6 : ffffffff814aa368 [ 0.045620][ T0] status: 0000000200000100 badaddr: 00000000000000f8 cause: 000000000000000d [ 0.046402][ T0] [<ffffffff80003b94>] restore_all+0x12/0x6e This because the $fp(aka. $s0) register is not used as frame pointer in the assembly entry code. resume_kernel: REG_L s0, TASK_TI_PREEMPT_COUNT(tp) bnez s0, restore_all REG_L s0, TASK_TI_FLAGS(tp) andi s0, s0, _TIF_NEED_R
me_kernel: REG_L s0, TASK_TI_PREEMPT_COUNT(tp) bnez s0, restore_all REG_L s0, TASK_TI_FLAGS(tp) andi s0, s0, _TIF_NEED_RESCHED beqz s0, restore_all call preempt_schedule_irq j restore_all To fix above issue, here we add one extra level wrapper for function trace_hardirqs_{on,off}() so they can be safely called by low level entry code. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/9e2dbc31e367d08ee299a0d8aeb498cb2e12a1c3 - https://git.kernel.org/stable/c/1851b9a467065b18ec2cba156eea345206df1c8f - https://git.kernel.org/stable/c/b5e180490db4af8c0f80c4b65ee482d333d0e8ee - https://git.kernel.org/stable/c/22e2100b1b07d6f5acc71cc1acb53f680c677d77
CVE ID: CVE-2022-48923 State: PUBLISHED Published: 2024-08-22T01:32:58.084Z Last Updated: 2025-05-21T08:44:01.641Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: prevent copying too big compressed lzo segment Compressed length can be corrupted to be a lot larger than memory we have allocated for buffer. This will cause memcpy in copy_compressed_segment to write outside of allocated memory. This mostly results in stuck read syscall but sometimes when using btrfs send can get #GP kernel: general protection fault, probably for non-canonical address 0x841551d5c1000: 0000 [#1] PREEMPT SMP NOPTI kernel: CPU: 17 PID: 264 Comm:
n fault, probably for non-canonical address 0x841551d5c1000: 0000 [#1] PREEMPT SMP NOPTI kernel: CPU: 17 PID: 264 Comm: kworker/u256:7 Tainted: P OE 5.17.0-rc2-1 #12 kernel: Workqueue: btrfs-endio btrfs_work_helper [btrfs] kernel: RIP: 0010:lzo_decompress_bio (./include/linux/fortify-string.h:225 fs/btrfs/lzo.c:322 fs/btrfs/lzo.c:394) btrfs Code starting with the faulting instruction =========================================== 0:* 48 8b 06 mov (%rsi),%rax <-- trapping instruction 3: 48 8d 79 08 lea 0x8(%rcx),%rdi 7: 48 83 e7 f8 and $0xfffffffffffffff8,%rdi b: 48 89 01 mov %rax,(%rcx) e: 44 89 f0 mov %r14d,%eax 11: 48 8b 54 06 f8 mov -0x8(%rsi,%rax,1),%rdx kernel: RSP: 0018:ffffb110812efd50 E
rax,(%rcx) e: 44 89 f0 mov %r14d,%eax 11: 48 8b 54 06 f8 mov -0x8(%rsi,%rax,1),%rdx kernel: RSP: 0018:ffffb110812efd50 EFLAGS: 00010212 kernel: RAX: 0000000000001000 RBX: 000000009ca264c8 RCX: ffff98996e6d8ff8 kernel: RDX: 0000000000000064 RSI: 000841551d5c1000 RDI: ffffffff9500435d kernel: RBP: ffff989a3be856c0 R08: 0000000000000000 R09: 0000000000000000 kernel: R10: 0000000000000000 R11: 0000000000001000 R12: ffff98996e6d8000 kernel: R13: 0000000000000008 R14: 0000000000001000 R15: 000841551d5c1000 kernel: FS: 0000000000000000(0000) GS:ffff98a09d640000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 00001e9f984d9ea8 CR3: 000000014971a000 C
000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 00001e9f984d9ea8 CR3: 000000014971a000 CR4: 00000000003506e0 kernel: Call Trace: kernel: <TASK> kernel: end_compressed_bio_read (fs/btrfs/compression.c:104 fs/btrfs/compression.c:1363 fs/btrfs/compression.c:323) btrfs kernel: end_workqueue_fn (fs/btrfs/disk-io.c:1923) btrfs kernel: btrfs_work_helper (fs/btrfs/async-thread.c:326) btrfs kernel: process_one_work (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:212 ./include/trace/events/workqueue.h:108 kernel/workqueue.c:2312) kernel: worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2455) kernel: ? process_one_work (kernel/workqueue.c
ernel: worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2455) kernel: ? process_one_work (kernel/workqueue.c:2397) kernel: kthread (kernel/kthread.c:377) kernel: ? kthread_complete_and_exit (kernel/kthread.c:332) kernel: ret_from_fork (arch/x86/entry/entry_64.S:301) kernel: </TASK> Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/8df508b7a44cd8110c726057cd28e8f8116885eb - https://git.kernel.org/stable/c/e326bd06cdde46df952361456232022298281d16 - https://git.kernel.org/stable/c/741b23a970a79d5d3a1db2d64fa2c7b375a4febb
CVE ID: CVE-2022-48924 State: PUBLISHED Published: 2024-08-22T01:33:05.770Z Last Updated: 2025-05-04T08:26:12.248Z Vendors: Linux Products: Linux Description: 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 [<ffffffff9c7b7c
b 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. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f0ddc5184b0127038d05
y. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f0ddc5184b0127038d05008e2a69f89d1e13f980 - https://git.kernel.org/stable/c/c3fa6d1937a8d0828131a04ae2cd2c30d0668693 - https://git.kernel.org/stable/c/2e798814e01827871938ff172d2b2ccf1e74b355 - https://git.kernel.org/stable/c/e098933866f9e1dd3ef4eebbe2e3d504f970f599 - https://git.kernel.org/stable/c/ba9efbbf6745750d34c1e87c9539ce9db645ca0a - https://git.kernel.org/stable/c/33c73a4d7e7b19313a6b417152f5365016926418 - https://git.kernel.org/stable/c/3abea10e6a8f0e7804ed4c124bea2d15aca977c8
CVE ID: CVE-2022-48925 State: PUBLISHED Published: 2024-08-22T01:33:11.172Z Last Updated: 2025-05-04T08:26:13.379Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/cma: Do not change route.addr.src_addr outside state checks If the state is not idle then resolve_prepare_src() should immediately fail and no change to global state should happen. However, it unconditionally overwrites the src_addr trying to build a temporary any address. For instance if the state is already RDMA_CM_LISTEN then this will corrupt the src_addr and would cause the test in cma_cancel_operation(): if (cma_any_addr(cma_src_addr(id_priv)) && !id_priv->c
the src_addr and would cause the test in cma_cancel_operation(): if (cma_any_addr(cma_src_addr(id_priv)) && !id_priv->cma_dev) Which would manifest as this trace from syzkaller: BUG: KASAN: use-after-free in __list_add_valid+0x93/0xa0 lib/list_debug.c:26 Read of size 8 at addr ffff8881546491e0 by task syz-executor.1/32204 CPU: 1 PID: 32204 Comm: syz-executor.1 Not tainted 5.12.0-rc8-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399
k.c:120 print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232 __kasan_report mm/kasan/report.c:399 [inline] kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416 __list_add_valid+0x93/0xa0 lib/list_debug.c:26 __list_add include/linux/list.h:67 [inline] list_add_tail include/linux/list.h:100 [inline] cma_listen_on_all drivers/infiniband/core/cma.c:2557 [inline] rdma_listen+0x787/0xe00 drivers/infiniband/core/cma.c:3751 ucma_listen+0x16a/0x210 drivers/infiniband/core/ucma.c:1102 ucma_write+0x259/0x350 drivers/infiniband/core/ucma.c:1732 vfs_write+0x28e/0xa30 fs/read_write.c:603 ksys_write+0x1ee/0x250 fs/read_write.c:658 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry
fs/read_write.c:603 ksys_write+0x1ee/0x250 fs/read_write.c:658 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae This is indicating that an rdma_id_private was destroyed without doing cma_cancel_listens(). Instead of trying to re-use the src_addr memory to indirectly create an any address derived from the dst build one explicitly on the stack and bind to that as any other normal flow would do. rdma_bind_addr() will copy it over the src_addr once it knows the state is valid. This is similar to commit bc0bdc5afaa7 ("RDMA/cma: Do not change route.addr.src_addr.ss_family") Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kern
change route.addr.src_addr.ss_family") Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/5b1cef5798b4fd6e4fd5522e7b8a26248beeacaa - https://git.kernel.org/stable/c/00265efbd3e5705038c9492a434fda8cf960c8a2 - https://git.kernel.org/stable/c/d350724795c7a48b05bf921d94699fbfecf7da0b - https://git.kernel.org/stable/c/22e9f71072fa605cbf033158db58e0790101928d
CVE ID: CVE-2022-48926 State: PUBLISHED Published: 2024-08-22T03:31:18.572Z Last Updated: 2025-05-04T08:26:14.492Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: gadget: rndis: add spinlock for rndis response list There's no lock for rndis response list. It could cause list corruption if there're two different list_add at the same time like below. It's better to add in rndis_add_response / rndis_free_response / rndis_get_next_response to prevent any race condition on response list. [ 361.894299] [1: irq/191-dwc3:16979] list_add corruption. next->prev should be prev (ffffff80651764d0), but was ffffff883dc36f80. (next=ffffff
91-dwc3:16979] list_add corruption. next->prev should be prev (ffffff80651764d0), but was ffffff883dc36f80. (next=ffffff80651764d0). [ 361.904380] [1: irq/191-dwc3:16979] Call trace: [ 361.904391] [1: irq/191-dwc3:16979] __list_add_valid+0x74/0x90 [ 361.904401] [1: irq/191-dwc3:16979] rndis_msg_parser+0x168/0x8c0 [ 361.904409] [1: irq/191-dwc3:16979] rndis_command_complete+0x24/0x84 [ 361.904417] [1: irq/191-dwc3:16979] usb_gadget_giveback_request+0x20/0xe4 [ 361.904426] [1: irq/191-dwc3:16979] dwc3_gadget_giveback+0x44/0x60 [ 361.904434] [1: irq/191-dwc3:16979] dwc3_ep0_complete_data+0x1e8/0x3a0 [ 361.904442] [1: irq/191-dwc3:16979] dwc3_ep0_interrupt+0x29c/0x3dc [ 361.904450] [1: irq/191-d
mplete_data+0x1e8/0x3a0 [ 361.904442] [1: irq/191-dwc3:16979] dwc3_ep0_interrupt+0x29c/0x3dc [ 361.904450] [1: irq/191-dwc3:16979] dwc3_process_event_entry+0x78/0x6cc [ 361.904457] [1: irq/191-dwc3:16979] dwc3_process_event_buf+0xa0/0x1ec [ 361.904465] [1: irq/191-dwc3:16979] dwc3_thread_interrupt+0x34/0x5c Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/9f5d8ba538ef81cd86ea587ca3f8c77e26bea405 - https://git.kernel.org/stable/c/669c2b178956718407af5631ccbc61c24413f038 - https://git.kernel.org/stable/c/9f688aadede6b862a0a898792b1a35421c93636f - https://git.kernel.org/stable/c/9ab652d41deab49848673c3dadb57ad338485376 - https://git.kernel.org/sta
2b1a35421c93636f - https://git.kernel.org/stable/c/9ab652d41deab49848673c3dadb57ad338485376 - https://git.kernel.org/stable/c/4ce247af3f30078d5b97554f1ae6200a0222c15a - https://git.kernel.org/stable/c/da514063440b53a27309a4528b726f92c3cfe56f - https://git.kernel.org/stable/c/33222d1571d7ce8c1c75f6b488f38968fa93d2d9 - https://git.kernel.org/stable/c/aaaba1c86d04dac8e49bf508b492f81506257da3
CVE ID: CVE-2022-48927 State: PUBLISHED Published: 2024-08-22T03:31:19.861Z Last Updated: 2025-05-04T08:26:15.611Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iio: adc: tsc2046: fix memory corruption by preventing array overflow On one side we have indio_dev->num_channels includes all physical channels + timestamp channel. On other side we have an array allocated only for physical channels. So, fix memory corruption by ARRAY_SIZE() instead of num_channels variable. Note the first case is a cleanup rather than a fix as the software timestamp channel bit in active_scanmask is never set by the IIO core. Additional Analyst Notes
an a fix as the software timestamp channel bit in active_scanmask is never set by the IIO core. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0cb9b2f73c182d242a640e512f4785c7c504512f - https://git.kernel.org/stable/c/082d2c047b0d305bb0b6e9f9d671a09470e2db2d - https://git.kernel.org/stable/c/b7a78a8adaa8849c02f174d707aead0f85dca0da
CVE ID: CVE-2022-48928 State: PUBLISHED Published: 2024-08-22T03:31:21.098Z Last Updated: 2025-05-04T08:26:16.689Z Vendors: Linux Products: Linux Description: 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. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0f88722313645a903f4d420ba61ddc690ec2481d - https://git.kernel.org/stable/c/c5723b422f564af15f2e3bc0592fd6376a0a6c45 - https://
2313645a903f4d420ba61ddc690ec2481d - https://git.kernel.org/stable/c/c5723b422f564af15f2e3bc0592fd6376a0a6c45 - https://git.kernel.org/stable/c/53d43a9c8dd224e66559fe86af1e473802c7130e - https://git.kernel.org/stable/c/ce1076b33e299dc8d270e4450a420a18bfb3e190 - https://git.kernel.org/stable/c/1aa12ecfdcbafebc218910ec47acf6262e600cf5 - https://git.kernel.org/stable/c/fe73477802981bd0d0d70f2b22f109bcca801bdb - https://git.kernel.org/stable/c/d6ed5426a7fad36cf928c244483ba24e72359638 - https://git.kernel.org/stable/c/e0a2e37f303828d030a83f33ffe14b36cb88d563
CVE ID: CVE-2022-48929 State: PUBLISHED Published: 2024-08-22T03:31:22.329Z Last Updated: 2025-05-04T08:26:17.781Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix crash due to out of bounds access into reg2btf_ids. When commit e6ac2450d6de ("bpf: Support bpf program calling kernel function") added kfunc support, it defined reg2btf_ids as a cheap way to translate the verifier reg type to the appropriate btf_vmlinux BTF ID, however commit c25b2ae13603 ("bpf: Replace PTR_TO_XXX_OR_NULL with PTR_TO_XXX | PTR_MAYBE_NULL") moved the __BPF_REG_TYPE_MAX from the last member of bpf_reg_type enum to after the base register types,
TR_MAYBE_NULL") moved the __BPF_REG_TYPE_MAX from the last member of bpf_reg_type enum to after the base register types, and defined other variants using type flag composition. However, now, the direct usage of reg->type to index into reg2btf_ids may no longer fall into __BPF_REG_TYPE_MAX range, and hence lead to out of bounds access and kernel crash on dereference of bad pointer. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/8c39925e98d498b9531343066ef82ae39e41adae - https://git.kernel.org/stable/c/f0ce1bc9e0235dd7412240be493d7ea65ed9eadc - https://git.kernel.org/stable/c/45ce4b4f9009102cd9f581196d480a59208690c1
CVE ID: CVE-2022-48930 State: PUBLISHED Published: 2024-08-22T03:31:23.582Z Last Updated: 2025-05-04T08:26:18.842Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/ib_srp: Fix a deadlock Remove the flush_workqueue(system_long_wq) call since flushing system_long_wq is deadlock-prone and since that call is redundant with a preceding cancel_work_sync() Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/8cc342508f9e7fdccd2e9758ae9d52aff72dab7f - https://git.kernel.org/stable/c/4752fafb461821f8c8581090c923ababba68c5bd - https://git.kernel.org/stable/c/d7997d19dfa7001ca41e971cd9efd091b
rg/stable/c/4752fafb461821f8c8581090c923ababba68c5bd - https://git.kernel.org/stable/c/d7997d19dfa7001ca41e971cd9efd091bb195b51 - https://git.kernel.org/stable/c/901206f71e6ad2b2e7accefc5199a438d173c25f - https://git.kernel.org/stable/c/99eb8d694174c777558dc902d575d1997d5ca650 - https://git.kernel.org/stable/c/c8b56e51aa91b8e7df3a98388dce3fdabd15c1d4 - https://git.kernel.org/stable/c/98d056603ce55ceb90631b3927151c190dfb1b27 - https://git.kernel.org/stable/c/081bdc9fe05bb23248f5effb6f811da3da4b8252
CVE ID: CVE-2022-48931 State: PUBLISHED Published: 2024-08-22T03:31:24.823Z Last Updated: 2025-05-04T08:26:20.045Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: configfs: fix a race in configfs_{,un}register_subsystem() When configfs_register_subsystem() or configfs_unregister_subsystem() is executing link_group() or unlink_group(), it is possible that two processes add or delete list concurrently. Some unfortunate interleavings of them can cause kernel panic. One of cases is: A --> B --> C --> D A <-- B <-- C <-- D delete list_head *B | delete list_head *C --------------------------------|----------------------------------- c
C <-- D delete list_head *B | delete list_head *C --------------------------------|----------------------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = next Fix this by adding mutex when calling link_group() or unlink_group(), but parent configfs_subsystem is NULL when config_item is root. So I create a mutex configfs_subsystem_mutex. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org
mutex configfs_subsystem_mutex. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/40805099af11f68c5ca7dbcfacf455da8f99f622 - https://git.kernel.org/stable/c/d1654de19d42f513b6cfe955cc77e7f427e05a77 - https://git.kernel.org/stable/c/a37024f7757c25550accdebf49e497ad6ae239fe - https://git.kernel.org/stable/c/b7e2b91fcb5c78c414e33dc8d50642e307ca0c5a - https://git.kernel.org/stable/c/a7ab53d3c27dfe83bb594456b9f38a37796ec39b - https://git.kernel.org/stable/c/e7a66dd2687758718eddd79b542a95cf3aa488cc - https://git.kernel.org/stable/c/3aadfd46858b1f64d4d6a0654b863e21aabff975 - https://git.kernel.org/stable/c/84ec758fb2daa236026506868c8796b0500c047d
CVE ID: CVE-2022-48932 State: PUBLISHED Published: 2024-08-22T03:31:25.989Z Last Updated: 2025-05-04T08:26:21.081Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5: DR, Fix slab-out-of-bounds in mlx5_cmd_dr_create_fte When adding a rule with 32 destinations, we hit the following out-of-band access issue: BUG: KASAN: slab-out-of-bounds in mlx5_cmd_dr_create_fte+0x18ee/0x1e70 This patch fixes the issue by both increasing the allocated buffers to accommodate for the needed actions and by checking the number of actions to prevent this issue when a rule with too many actions is provided. Additional Analyst Notes: - CISA ADP V
r of actions to prevent this issue when a rule with too many actions is provided. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/4ad319cdfbe555b4ff67bc608736c46a6930c848 - https://git.kernel.org/stable/c/0aec12d97b2036af0946e3d582144739860ac07b