Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ker_thread+0x10/0x10 [ 1987.414019] kthread+0x107/0x140 [ 1987.417693] ? __pfx_kthread+0x10/0x10 [ 1987.421954] ret_from_fork+0x3d/0x60 [ 1987.426019] ? __pfx_kthread+0x10/0x10 [ 1987.430281] ret_from_fork_asm+0x1b/0x30 [ 1987.434744] </TASK> The issue arises because event log cache is created using kmem_cache_create() which is not suitable for user copy. Fix the issue by creating event log cache with kmem_cache_create_usercopy(), ensuring safe user copy. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/5e3022ea42e490a36ec6f2cfa6fc603deb0bace4 - https://git.kernel.org/stable/c/bb71e040323175e18c233a9afef32ba14fa64eb7 -
c/5e3022ea42e490a36ec6f2cfa6fc603deb0bace4 - https://git.kernel.org/stable/c/bb71e040323175e18c233a9afef32ba14fa64eb7 - https://git.kernel.org/stable/c/d3ea125df37dc37972d581b74a5d3785c3f283ab
CVE ID: CVE-2024-26747 State: PUBLISHED Published: 2024-04-03T17:00:34.066Z Last Updated: 2025-05-07T19:59:49.971Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: roles: fix NULL pointer issue when put module's reference In current design, usb role class driver will get usb_role_switch parent's module reference after the user get usb_role_switch device and put the reference after the user put the usb_role_switch device. However, the parent device of usb_role_switch may be removed before the user put the usb_role_switch. If so, then, NULL pointer issue will be met when the user put the parent module's reference. This will sa
b_role_switch. If so, then, NULL pointer issue will be met when the user put the parent module's reference. This will save the module pointer in structure of usb_role_switch. Then, we don't need to find module by iterating long relations. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/e279bf8e51893e1fe160b3d8126ef2dd00f661e1 - https://git.kernel.org/stable/c/ef982fc41055fcebb361a92288d3225783d12913 - https://git.kernel.org/stable/c/0158216805ca7e498d07de38840d2732166ae5fa - https://git.kernel.org/stable/c/4b45829440b1b208948b39cc71f77a37a2536734 - https://git.kernel.org/stable/c/01f82de440f2ab07c259b7573371e1c42e5565d
ble/c/4b45829440b1b208948b39cc71f77a37a2536734 - https://git.kernel.org/stable/c/01f82de440f2ab07c259b7573371e1c42e5565db - https://git.kernel.org/stable/c/1c9be13846c0b2abc2480602f8ef421360e1ad9e
CVE ID: CVE-2024-26748 State: PUBLISHED Published: 2024-04-03T17:00:35.087Z Last Updated: 2025-05-04T08:55:36.651Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fix memory double free when handle zero packet 829 if (request->complete) { 830 spin_unlock(&priv_dev->lock); 831 usb_gadget_giveback_request(&priv_ep->endpoint, 832 request); 833 spin_lock(&priv_dev->lock); 834 } 835 836 if (request->buf == priv_dev->zlp_buf) 837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request); Driver append an additional zero packet request when queue a packet, which length mod max packet size is 0. When transfer complete, run t
additional zero packet request when queue a packet, which length mod max packet size is 0. When transfer complete, run to line 831, usb_gadget_giveback_request() will free this requestion. 836 condition is true, so cdns3_gadget_ep_free_request() free this request again. Log: [ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.140696][ T150] [ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36): [ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3] [ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3] Add check at line 829, skip call usb_gadget_giveback_request() if it is additional zero le
completed+0x438/0x5f8 [cdns3] Add check at line 829, skip call usb_gadget_giveback_request() if it is additional zero length packet request. Needn't call usb_gadget_giveback_request() because it is allocated in this driver. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/aad6132ae6e4809e375431f8defd1521985e44e7 - https://git.kernel.org/stable/c/1e204a8e9eb514e22a6567fb340ebb47df3f3a48 - https://git.kernel.org/stable/c/3a2a909942b5335b7ea66366d84261b3ed5f89c8 - https://git.kernel.org/stable/c/9a52b694b066f299d8b9800854a8503457a8b64c - https://git.kernel.org/stable/c/70e8038813f9d3e72df966748ebbc40efe466019 - https://git
066f299d8b9800854a8503457a8b64c - https://git.kernel.org/stable/c/70e8038813f9d3e72df966748ebbc40efe466019 - https://git.kernel.org/stable/c/92d20406a3d4ff3e8be667c79209dc9ed31df5b3 - https://git.kernel.org/stable/c/5fd9e45f1ebcd57181358af28506e8a661a260b3
CVE ID: CVE-2024-26749 State: PUBLISHED Published: 2024-04-03T17:00:35.762Z Last Updated: 2025-05-04T08:55:37.922Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable() ... cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request); list_del_init(&priv_req->list); ... 'priv_req' actually free at cdns3_gadget_ep_free_request(). But list_del_init() use priv_req->list after it. [ 1542.642868][ T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4 [ 1542.642868][ T534] [ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfen
del_entry_valid+0x10/0xd4 [ 1542.642868][ T534] [ 1542.653162][ T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3): [ 1542.660311][ T534] __list_del_entry_valid+0x10/0xd4 [ 1542.665375][ T534] cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3] [ 1542.671571][ T534] usb_ep_disable+0x44/0xe4 [ 1542.675948][ T534] ffs_func_eps_disable+0x64/0xc8 [ 1542.680839][ T534] ffs_func_set_alt+0x74/0x368 [ 1542.685478][ T534] ffs_func_disable+0x18/0x28 Move list_del_init() before cdns3_gadget_ep_free_request() to resolve this problem. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/cfa9abb5570c489dabf6f7fb3a066cc576fc8824 - htt
r: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/cfa9abb5570c489dabf6f7fb3a066cc576fc8824 - https://git.kernel.org/stable/c/b40328eea93c75a5645891408010141a0159f643 - https://git.kernel.org/stable/c/4e5c73b15d95452c1ba9c771dd013a3fbe052ff3 - https://git.kernel.org/stable/c/2134e9906e17b1e5284300fab547869ebacfd7d9 - https://git.kernel.org/stable/c/29e42e1578a10c611b3f1a38f3229b2d664b5d16 - https://git.kernel.org/stable/c/9a07244f614bc417de527b799da779dcae780b5d - https://git.kernel.org/stable/c/cd45f99034b0c8c9cb346dd0d6407a95ca3d36f6
CVE ID: CVE-2024-26750 State: PUBLISHED Published: 2024-04-04T08:20:14.494Z Last Updated: 2025-05-04T08:55:39.291Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: af_unix: Drop oob_skb ref before purging queue in GC. syzbot reported another task hung in __unix_gc(). [0] The current while loop assumes that all of the left candidates have oob_skb and calling kfree_skb(oob_skb) releases the remaining candidates. However, I missed a case that oob_skb has self-referencing fd and another fd and the latter sk is placed before the former in the candidate list. Then, the while loop never proceeds, resulting the task hung. __unix_gc() has
d before the former in the candidate list. Then, the while loop never proceeds, resulting the task hung. __unix_gc() has the same loop just before purging the collected skb, so we can call kfree_skb(oob_skb) there and let __skb_queue_purge() release all inflight sockets. [0]: Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 2784 Comm: kworker/u4:8 Not tainted 6.8.0-rc4-syzkaller-01028-g71b605d32017 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Workqueue: events_unbound __unix_gc RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:200 Code: 89 fb e8 23 00 00 00 48 8b 3d 84 f5 1a 0c 48 89 de 5b e9 43 26 57 00 0f 1f 00 90
ace_pc+0x0/0x70 kernel/kcov.c:200 Code: 89 fb e8 23 00 00 00 48 8b 3d 84 f5 1a 0c 48 89 de 5b e9 43 26 57 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 <f3> 0f 1e fa 48 8b 04 24 65 48 8b 0d 90 52 70 7e 65 8b 15 91 52 70 RSP: 0018:ffffc9000a17fa78 EFLAGS: 00000287 RAX: ffffffff8a0a6108 RBX: ffff88802b6c2640 RCX: ffff88802c0b3b80 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffc9000a17fbf0 R08: ffffffff89383f1d R09: 1ffff1100ee5ff84 R10: dffffc0000000000 R11: ffffed100ee5ff85 R12: 1ffff110056d84ee R13: ffffc9000a17fae0 R14: 0000000000000000 R15: ffffffff8f47b840 FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 000
00000 R15: ffffffff8f47b840 FS: 0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffef5687ff8 CR3: 0000000029b34000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <TASK> __unix_gc+0xe69/0xf40 net/unix/garbage.c:343 process_one_work kernel/workqueue.c:2633 [inline] process_scheduled_works+0x913/0x1420 kernel/workqueue.c:2706 worker_thread+0xa5f/0x1000 kernel/workqueue.c:2787 kthread+0x2ef/0x390 kernel/kthread.c:388 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_a
ue.c:2787 kthread+0x2ef/0x390 kernel/kthread.c:388 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242 </TASK> Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/6c480d0f131862645d172ca9e25dc152b1a5c3a6 - https://git.kernel.org/stable/c/c4c795b21dd23d9514ae1c6646c3fb2c78b5be60 - https://git.kernel.org/stable/c/e9eac260369d0cf57ea53df95427125725507a0d - https://git.kernel.org/stable/c/43ba9e331559a30000c862eea313248707afa787 - https://git.kernel.org/stable/c/aa82ac51d63328714645c827775d64dbfd9941f3
CVE ID: CVE-2024-26751 State: PUBLISHED Published: 2024-04-03T17:00:36.523Z Last Updated: 2025-05-04T08:55:40.678Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ARM: ep93xx: Add terminator to gpiod_lookup_table Without the terminator, if a con_id is passed to gpio_find() that does not exist in the lookup table the function will not stop looping correctly, and eventually cause an oops. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/9e200a06ae2abb321939693008290af32b33dd6e - https://git.kernel.org/stable/c/999a8bb70da2946336327b4480824d1691cae1fa - https:
0a06ae2abb321939693008290af32b33dd6e - https://git.kernel.org/stable/c/999a8bb70da2946336327b4480824d1691cae1fa - https://git.kernel.org/stable/c/70d92abbe29692a3de8697ae082c60f2d21ab482 - https://git.kernel.org/stable/c/eec6cbbfa1e8d685cc245cfd5626d0715a127a48 - https://git.kernel.org/stable/c/786f089086b505372fb3f4f008d57e7845fff0d8 - https://git.kernel.org/stable/c/97ba7c1f9c0a2401e644760d857b2386aa895997 - https://git.kernel.org/stable/c/6abe0895b63c20de06685c8544b908c7e413efa8 - https://git.kernel.org/stable/c/fdf87a0dc26d0550c60edc911cda42f9afec3557
CVE ID: CVE-2024-26752 State: PUBLISHED Published: 2024-04-03T17:00:37.340Z Last Updated: 2025-05-04T12:54:40.861Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: l2tp: pass correct message length to ip6_append_data l2tp_ip6_sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff. To manage this, we check whether the skbuff contains data using skb_queue_empty when deciding how much data to append using ip6_append_data. However, the code which performed the calculation was incorrect: ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0; ...d
which performed the calculation was incorrect: ulen = len + skb_queue_empty(&sk->sk_write_queue) ? transhdrlen : 0; ...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire. Add parentheses to correct the calculation in line with the original intent. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/4c3ce64bc9d36ca9164dd6c77ff144c121011aae - https://git.kernel.org/stable/c/c1d3a84a67db910ce28a871273c992c3d7f9efb5 - https://git.kernel.org/stable/c/dcb4d14268595065c85dc5528056713928e17243 - https://git.kernel.org/stable/c/0
3d7f9efb5 - https://git.kernel.org/stable/c/dcb4d14268595065c85dc5528056713928e17243 - https://git.kernel.org/stable/c/0da15a70395182ee8cb75716baf00dddc0bea38d - https://git.kernel.org/stable/c/13cd1daeea848614e585b2c6ecc11ca9c8ab2500 - https://git.kernel.org/stable/c/804bd8650a3a2bf3432375f8c97d5049d845ce56 - https://git.kernel.org/stable/c/83340c66b498e49353530e41542500fc8a4782d6 - https://git.kernel.org/stable/c/359e54a93ab43d32ee1bff3c2f9f10cb9f6b6e79
CVE ID: CVE-2024-26753 State: PUBLISHED Published: 2024-04-03T17:00:38.148Z Last Updated: 2025-05-04T08:55:44.222Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: virtio/akcipher - Fix stack overflow on memcpy sizeof(struct virtio_crypto_akcipher_session_para) is less than sizeof(struct virtio_crypto_op_ctrl_req::u), copying more bytes from stack variable leads stack overflow. Clang reports this issue by commands: make -j CC=clang-14 mrproper >/dev/null 2>&1 make -j O=/tmp/crypto-build CC=clang-14 allmodconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtio_crypto_akcipher_algs.o
dconfig >/dev/null 2>&1 make -j O=/tmp/crypto-build W=1 CC=clang-14 drivers/crypto/virtio/ virtio_crypto_akcipher_algs.o Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/37077ed16c7793e21b005979d33f8a61565b7e86 - https://git.kernel.org/stable/c/62f361bfea60c6afc3df09c1ad4152e6507f6f47 - https://git.kernel.org/stable/c/b0365460e945e1117b47cf7329d86de752daff63 - https://git.kernel.org/stable/c/ef1e47d50324e232d2da484fe55a54274eeb9bc1 - https://git.kernel.org/stable/c/c0ec2a712daf133d9996a8a1b7ee2d4996080363
CVE ID: CVE-2024-26754 State: PUBLISHED Published: 2024-04-03T17:00:39.079Z Last Updated: 2025-05-04T08:55:45.919Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp() The gtp_net_ops pernet operations structure for the subsystem must be registered before registering the generic netlink family. Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 5826 Comm: gtp
REEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp] Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74 RSP: 0018:ffff888014107220 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 000000000000
00000000000000 RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000 FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? show_regs+0x90/0xa0 ? die_addr+0x50/0xd0 ? exc_general_protection+0x148/0x220 ? asm_exc_general_protection+0x22/0x30 ? gtp_genl_dump_pdp+0x1be/0x800 [gtp] ? __alloc_skb+0x1dd/0x350 ? __pfx___all
220 ? asm_exc_general_protection+0x22/0x30 ? gtp_genl_dump_pdp+0x1be/0x800 [gtp] ? __alloc_skb+0x1dd/0x350 ? __pfx___alloc_skb+0x10/0x10 genl_dumpit+0x11d/0x230 netlink_dump+0x5b9/0xce0 ? lockdep_hardirqs_on_prepare+0x253/0x430 ? __pfx_netlink_dump+0x10/0x10 ? kasan_save_track+0x10/0x40 ? __kasan_kmalloc+0x9b/0xa0 ? genl_start+0x675/0x970 __netlink_dump_start+0x6fc/0x9f0 genl_family_rcv_msg_dumpit+0x1bb/0x2d0 ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10 ? genl_op_from_small+0x2a/0x440 ? cap_capable+0x1d0/0x240 ? __pfx_genl_start+0x10/0x10 ? __pfx_genl_dumpit+0x10/0x10 ? __pfx_genl_done+0x10/0x10 ? security_capable+0x9d/0xe0 Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnri
fx_genl_done+0x10/0x10 ? security_capable+0x9d/0xe0 Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f0ecdfa679189d26aedfe24212d4e69e42c2c861 - https://git.kernel.org/stable/c/f8cbd1791900b5d96466eede8e9439a5b9ca4de7 - https://git.kernel.org/stable/c/2e534fd15e5c2ca15821c897352cf0e8a3e30dca - https://git.kernel.org/stable/c/a576308800be28f2eaa099e7caad093b97d66e77 - https://git.kernel.org/stable/c/3963f16cc7643b461271989b712329520374ad2a - https://git.kernel.org/stable/c/ba6b8b02a3314e62571a540efa96560888c5f03e - https://git.kernel.org/stable/c/5013bd54d283eda5262c9ae3bcc966d01daf8576 - https://git.kernel.org/stable/c/1
888c5f03e - https://git.kernel.org/stable/c/5013bd54d283eda5262c9ae3bcc966d01daf8576 - https://git.kernel.org/stable/c/136cfaca22567a03bbb3bf53a43d8cb5748b80ec
CVE ID: CVE-2024-26755 State: PUBLISHED Published: 2024-04-03T17:00:39.888Z Last Updated: 2025-05-04T08:55:47.216Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: md: Don't suspend the array for interrupted reshape md_start_sync() will suspend the array if there are spares that can be added or removed from conf, however, if reshape is still in progress, this won't happen at all or data will be corrupted(remove_and_add_spares won't be called from md_choose_sync_action for reshape), hence there is no need to suspend the array if reshape is not done yet. Meanwhile, there is a potential deadlock for raid456: 1) reshape is interrupte
end the array if reshape is not done yet. Meanwhile, there is a potential deadlock for raid456: 1) reshape is interrupted; 2) set one of the disk WantReplacement, and add a new disk to the array, however, recovery won't start until the reshape is finished; 3) then issue an IO across reshpae position, this IO will wait for reshape to make progress; 4) continue to reshape, then md_start_sync() found there is a spare disk that can be added to conf, mddev_suspend() is called; Step 4 and step 3 is waiting for each other, deadlock triggered. Noted this problem is found by code review, and it's not reporduced yet. Fix this porblem by don't suspend the array for interrupted reshape, this is safe bec
view, and it's not reporduced yet. Fix this porblem by don't suspend the array for interrupted reshape, this is safe because conf won't be changed until reshape is done. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/60d6130d0ac1d883ed93c2a1e10aadb60967fd48 - https://git.kernel.org/stable/c/9e46c70e829bddc24e04f963471e9983a11598b7
CVE ID: CVE-2024-26756 State: PUBLISHED Published: 2024-04-03T17:00:40.814Z Last Updated: 2025-05-04T08:55:48.562Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: md: Don't register sync_thread for reshape directly Currently, if reshape is interrupted, then reassemble the array will register sync_thread directly from pers->run(), in this case 'MD_RECOVERY_RUNNING' is set directly, however, there is no guarantee that md_do_sync() will be executed, hence stop_sync_thread() will hang because 'MD_RECOVERY_RUNNING' can't be cleared. Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE, however, following hang can still be
can't be cleared. Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE, however, following hang can still be triggered by dm-raid test shell/lvconvert-raid-reshape.sh occasionally: [root@fedora ~]# cat /proc/1982/stack [<0>] stop_sync_thread+0x1ab/0x270 [md_mod] [<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod] [<0>] raid_presuspend+0x1e/0x70 [dm_raid] [<0>] dm_table_presuspend_targets+0x40/0xb0 [dm_mod] [<0>] __dm_destroy+0x2a5/0x310 [dm_mod] [<0>] dm_destroy+0x16/0x30 [dm_mod] [<0>] dev_remove+0x165/0x290 [dm_mod] [<0>] ctl_ioctl+0x4bb/0x7b0 [dm_mod] [<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod] [<0>] vfs_ioctl+0x21/0x60 [<0>] __x64_sys_ioctl+0xb9/0xe0 [<0>] do_syscall_64+0xc6/0x230 [<0>]
_ioctl+0x11/0x20 [dm_mod] [<0>] vfs_ioctl+0x21/0x60 [<0>] __x64_sys_ioctl+0xb9/0xe0 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 Meanwhile mddev->recovery is: MD_RECOVERY_RUNNING | MD_RECOVERY_INTR | MD_RECOVERY_RESHAPE | MD_RECOVERY_FROZEN Fix this problem by remove the code to register sync_thread directly from raid10 and raid5. And let md_check_recovery() to register sync_thread. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/13b520fb62b772e408f9b79c5fe18ad414e90417 - https://git.kernel.org/stable/c/ad39c08186f8a0f221337985036ba86731d6aafe
CVE ID: CVE-2024-26757 State: PUBLISHED Published: 2024-04-03T17:00:41.633Z Last Updated: 2025-05-04T08:55:49.729Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: md: Don't ignore read-only array in md_check_recovery() Usually if the array is not read-write, md_check_recovery() won't register new sync_thread in the first place. And if the array is read-write and sync_thread is registered, md_set_readonly() will unregister sync_thread before setting the array read-only. md/raid follow this behavior hence there is no problem. After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/
s no problem. After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh: 1) array is read-only. dm-raid update super block: rs_update_sbs ro = mddev->ro mddev->ro = 0 -> set array read-write md_update_sb 2) register new sync thread concurrently. 3) dm-raid set array back to read-only: rs_update_sbs mddev->ro = ro 4) stop the array: raid_dtr md_stop stop_sync_thread set_bit(MD_RECOVERY_INTR, &mddev->recovery); md_wakeup_thread_directly(mddev->sync_thread); wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery)) 5) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thre
ev->recovery)) 5) sync thread done: md_do_sync set_bit(MD_RECOVERY_DONE, &mddev->recovery); md_wakeup_thread(mddev->thread); 6) daemon thread can't unregister sync thread: md_check_recovery if (!md_is_rdwr(mddev) && !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery)) return; -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang; The root cause is that dm-raid manipulate 'mddev->ro' by itself, however, dm-raid really should stop sync thread before setting the array read-only. Unfortunately, I need to read more code before I can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix the problem the easy way for now to prevent dm-raid regression. Additional Analyst Notes: - CISA A