xamxte/cve-to-cwe huggingface dataset:
CVE-2025-21801: In the Linux kernel, the following vulnerability has been resolved:  net: ravb: Fix missing rtnl lock in suspend/resume path  Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravb_open, ravb_close and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations.  Without this fix, the following warning is triggered: [   39.032969] ============================= [   39.032983] WARNING: suspicious RCU usage [   39.033019] ----------------------------- [   39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [   39.033597] stack backtrace: [   39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [   39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [   39.033628] Call trace: [   39.033633]  show_stack+0x14/0x1c (C) [   39.033652]  dump_stack_lvl+0xb4/0xc4 [   39.033664]  dump_stack+0x14/0x1c [   39.033671]  lockdep_rcu_suspicious+0x16c/0x22c [   39.033682]  phy_detach+0x160/0x190 [   39.033694]  phy_disconnect+0x40/0x54 [   39.033703]  ravb_close+0x6c/0x1cc [   39.033714]  ravb_suspend+0x48/0x120 [   39.033721]  dpm_run_callback+0x4c/0x14c [   39.033731]  device_suspend+0x11c/0x4dc [   39.033740]  dpm_suspend+0xdc/0x214 [   39.033748]  dpm_suspend_start+0x48/0x60 [   39.033758]  suspend_devices_and_enter+0x124/0x574 [   39.033769]  pm_suspend+0x1ac/0x274 [   39.033778]  state_store+0x88/0x124 [   39.033788]  kobj_attr_store+0x14/0x24 [   39.033798]  sysfs_kf_write+0x48/0x6c [   39.033808]  kernfs_fop_write_iter+0x118/0x1a8 [   39.033817]  vfs_write+0x27c/0x378 [   39.033825]  ksys_write+0x64/0xf4 [   39.033833]  __arm64_sys_write+0x18/0x20 [   39.033841]  invoke_syscall+0x44/0x104 [   39.033852]  el0_svc_common.constprop.0+0xb4/0xd4 [   39.033862]  do_el0_svc+0x18/0x20 [   39.033870]  el0_svc+0x3c/0xf0 [   39.033880]  el0t_64_sync_handler+0xc0/0xc4 [   39.033888]  el0t_64_sync+0x154/0x158 [   39.041274] ravb 11c30000.ethernet eth0: Link is Down
CVE-2025-21802: In the Linux kernel, the following vulnerability has been resolved:  net: hns3: fix oops when unload drivers paralleling  When unload hclge driver, it tries to disable sriov first for each ae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver at the time, because it removes all the ae_dev nodes, and it may cause oops.  But we can't simply use hnae3_common_lock for this. Because in the process flow of pci_disable_sriov(), it will trigger the remove flow of VF, which will also take hnae3_common_lock.  To fixes it, introduce a new mutex to protect the unload process.
CVE-2025-21822: In the Linux kernel, the following vulnerability has been resolved:  ptp: vmclock: Set driver data before its usage  If vmclock_ptp_register() fails during probing, vmclock_remove() is called to clean up the ptp clock and misc device. It uses dev_get_drvdata() to access the vmclock state. However the driver data is not yet set at this point.  Assign the driver data earlier.
CVE-2025-0288: Various Paragon Software products contain an arbitrary kernel memory vulnerability within biontdrv.sys, facilitated by the memmove function, which does not validate or sanitize user controlled input, allowing an attacker the ability to write arbitrary kernel memory and perform privilege escalation.
CVE-2025-1933: On 64-bit CPUs, when the JIT compiles WASM i32 return values they can pick up bits from left over memory. This can potentially cause them to be treated as a different type. This vulnerability affects Firefox < 136, Firefox ESR < 115.21, Firefox ESR < 128.8, Thunderbird < 136, and Thunderbird < 128.8.
CVE-2025-1934: It was possible to interrupt the processing of a RegExp bailout and run additional JavaScript, potentially triggering garbage collection when the engine was not expecting it. This vulnerability affects Firefox < 136, Firefox ESR < 128.8, Thunderbird < 136, and Thunderbird < 128.8.
CVE-2025-20903: Improper access control in SecSettingsIntelligence prior to SMR Mar-2025 Release 1 allows local attackers to launch privileged activities. User interaction is required for triggering this vulnerability.
CVE-2025-20908: Use of insufficiently random values in Auracast prior to SMR Mar-2025 Release 1 allows adjacent attackers to access Auracast broadcasting.
CVE-2025-20911: Improper access control in sem_wifi service prior to SMR Mar-2025 Release 1 allows privileged local attackers to update MAC address of Galaxy Watch.
CVE-2025-20923: Improper access control in Galaxy Wearable prior to version 2.2.61.24112961 allows local attackers to launch arbitrary activity with Galaxy Wearable privilege.
CVE-2025-20924: Improper access control in Samsung Notes prior to version 4.4.26.71 allows physical attackers to access data across multiple user profiles.
CVE-2025-20926: Improper export of Android application components in My Files prior to version 15.0.07.5 in Android 14 allows local attackers to access files with My Files' privilege.
CVE-2024-58054: In the Linux kernel, the following vulnerability has been resolved:  staging: media: max96712: fix kernel oops when removing module  The following kernel oops is thrown when trying to remove the max96712 module:  Unable to handle kernel paging request at virtual address 00007375746174db Mem abort info:   ESR = 0x0000000096000004   EC = 0x25: DABT (current EL), IL = 32 bits   SET = 0, FnV = 0   EA = 0, S1PTW = 0   FSC = 0x04: level 0 translation fault Data abort info:   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000   CM = 0, WnR = 0, TnD = 0, TagAccess = 0   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af89000 [00007375746174db] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: crct10dif_ce polyval_ce mxc_jpeg_encdec flexcan     snd_soc_fsl_sai snd_soc_fsl_asoc_card snd_soc_fsl_micfil dwc_mipi_csi2     imx_csi_formatter polyval_generic v4l2_jpeg imx_pcm_dma can_dev     snd_soc_imx_audmux snd_soc_wm8962 snd_soc_imx_card snd_soc_fsl_utils     max96712(C-) rpmsg_ctrl rpmsg_char pwm_fan fuse     [last unloaded: imx8_isi] CPU: 0 UID: 0 PID: 754 Comm: rmmod      Tainted: G         C    6.12.0-rc6-06364-g327fec852c31 #17 Tainted: [C]=CRAP Hardware name: NXP i.MX95 19X19 board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : led_put+0x1c/0x40 lr : v4l2_subdev_put_privacy_led+0x48/0x58 sp : ffff80008699bbb0 x29: ffff80008699bbb0 x28: ffff00008ac233c0 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 x23: ffff000080cf1170 x22: ffff00008b53bd00 x21: ffff8000822ad1c8 x20: ffff000080ff5c00 x19: ffff00008b53be40 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000004 x13: ffff0000800f8010 x12: 0000000000000000 x11: ffff000082acf5c0 x10: ffff000082acf478 x9 : ffff0000800f8010 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 0000000000000020 x3 : 00000000553a3dc1 x2 : ffff00008ac233c0 x1 : ffff00008ac233c0 x0 : ff00737574617473 Call trace:  led_put+0x1c/0x40  v4l2_subdev_put_privacy_led+0x48/0x58  v4l2_async_unregister_subdev+0x2c/0x1a4  max96712_remove+0x1c/0x38 [max96712]  i2c_device_remove+0x2c/0x9c  device_remove+0x4c/0x80  device_release_driver_internal+0x1cc/0x228  driver_detach+0x4c/0x98  bus_remove_driver+0x6c/0xbc  driver_unregister+0x30/0x60  i2c_del_driver+0x54/0x64  max96712_i2c_driver_exit+0x18/0x1d0 [max96712]  __arm64_sys_delete_module+0x1a4/0x290  invoke_syscall+0x48/0x10c  el0_svc_common.constprop.0+0xc0/0xe0  do_el0_svc+0x1c/0x28  el0_svc+0x34/0xd8  el0t_64_sync_handler+0x120/0x12c  el0t_64_sync+0x190/0x194 Code: f9000bf3 aa0003f3 f9402800 f9402000 (f9403400) ---[ end trace 0000000000000000 ]---  This happens because in v4l2_i2c_subdev_init(), the i2c_set_cliendata() is called again and the data is overwritten to point to sd, instead of priv. So, in remove(), the wrong pointer is passed to v4l2_async_unregister_subdev(), leading to a crash.
CVE-2024-58074: In the Linux kernel, the following vulnerability has been resolved:  drm/i915: Grab intel_display from the encoder to avoid potential oopsies  Grab the intel_display from 'encoder' rather than 'state' in the encoder hooks to avoid the massive footgun that is intel_sanitize_encoder(), which passes NULL as the 'state' argument to encoder .disable() and .post_disable().  TODO: figure out how to actually fix intel_sanitize_encoder()...
CVE-2024-58079: In the Linux kernel, the following vulnerability has been resolved:  media: uvcvideo: Fix crash during unbind if gpio unit is in use  We used the wrong device for the device managed functions. We used the usb device, when we should be using the interface device.  If we unbind the driver from the usb interface, the cleanup functions are never called. In our case, the IRQ is never disabled.  If an IRQ is triggered, it will try to access memory sections that are already free, causing an OOPS.  We cannot use the function devm_request_threaded_irq here. The devm_* clean functions may be called after the main structure is released by uvc_delete.  Luckily this bug has small impact, as it is only affected by devices with gpio units and the user has to unbind the device, a disconnect will not trigger this error.
CVE-2024-58082: In the Linux kernel, the following vulnerability has been resolved:  media: nuvoton: Fix an error check in npcm_video_ece_init()  When function of_find_device_by_node() fails, it returns NULL instead of an error code. So the corresponding error check logic should be modified to check whether the return value is NULL and set the error code to be returned as -ENODEV.
CVE-2024-58086: In the Linux kernel, the following vulnerability has been resolved:  drm/v3d: Stop active perfmon if it is being destroyed  If the active performance monitor (`v3d->active_perfmon`) is being destroyed, stop it first. Currently, the active perfmon is not stopped during destruction, leaving the `v3d->active_perfmon` pointer stale. This can lead to undefined behavior and instability.  This patch ensures that the active perfmon is stopped before being destroyed, aligning with the behavior introduced in commit 7d1fd3638ee3 ("drm/v3d: Stop the active perfmon before being destroyed").
CVE-2025-21835: In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: f_midi: fix MIDI Streaming descriptor lengths  While the MIDI jacks are configured correctly, and the MIDIStreaming endpoint descriptors are filled with the correct information, bNumEmbMIDIJack and bLength are set incorrectly in these descriptors.  This does not matter when the numbers of in and out ports are equal, but when they differ the host will receive broken descriptors with uninitialized stack memory leaking into the descriptor for whichever value is smaller.  The precise meaning of "in" and "out" in the port counts is not clearly defined and can be confusing.  But elsewhere the driver consistently uses this to match the USB meaning of IN and OUT viewed from the host, so that "in" ports send data to the host and "out" ports receive data from it.
CVE-2025-21836: In the Linux kernel, the following vulnerability has been resolved:  io_uring/kbuf: reallocate buf lists on upgrade  IORING_REGISTER_PBUF_RING can reuse an old struct io_buffer_list if it was created for legacy selected buffer and has been emptied. It violates the requirement that most of the field should stay stable after publish. Always reallocate it instead.
CVE-2025-21841: In the Linux kernel, the following vulnerability has been resolved:  cpufreq/amd-pstate: Fix cpufreq_policy ref counting  amd_pstate_update_limits() takes a cpufreq_policy reference but doesn't decrement the refcount in one of the exit paths, fix that.
CVE-2024-11638: The Gtbabel WordPress plugin before 6.6.9 does not ensure that the URL to perform code analysis upon belongs to the blog which could allow unauthenticated attackers to retrieve a logged in user (such as admin) cookies by making them open a crafted URL as the request made to analysed the URL contains such cookies.
CVE-2025-26695: When requesting an OpenPGP key from a WKD server, an incorrect padding size was used and a network observer could have learned the length of the requested email address. This vulnerability affects Thunderbird < 136 and Thunderbird < 128.8.
CVE-2025-21845: In the Linux kernel, the following vulnerability has been resolved:  mtd: spi-nor: sst: Fix SST write failure  'commit 18bcb4aa54ea ("mtd: spi-nor: sst: Factor out common write operation to `sst_nor_write_data()`")' introduced a bug where only one byte of data is written, regardless of the number of bytes passed to sst_nor_write_data(), causing a kernel crash during the write operation. Ensure the correct number of bytes are written as passed to sst_nor_write_data().  Call trace: [   57.400180] ------------[ cut here ]------------ [   57.404842] While writing 2 byte written 1 bytes [   57.409493] WARNING: CPU: 0 PID: 737 at drivers/mtd/spi-nor/sst.c:187 sst_nor_write_data+0x6c/0x74 [   57.418464] Modules linked in: [   57.421517] CPU: 0 UID: 0 PID: 737 Comm: mtd_debug Not tainted 6.12.0-g5ad04afd91f9 #30 [   57.429517] Hardware name: Xilinx Versal A2197 Processor board revA - x-prc-02 revA (DT) [   57.437600] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [   57.444557] pc : sst_nor_write_data+0x6c/0x74 [   57.448911] lr : sst_nor_write_data+0x6c/0x74 [   57.453264] sp : ffff80008232bb40 [   57.456570] x29: ffff80008232bb40 x28: 0000000000010000 x27: 0000000000000001 [   57.463708] x26: 000000000000ffff x25: 0000000000000000 x24: 0000000000000000 [   57.470843] x23: 0000000000010000 x22: ffff80008232bbf0 x21: ffff000816230000 [   57.477978] x20: ffff0008056c0080 x19: 0000000000000002 x18: 0000000000000006 [   57.485112] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80008232b580 [   57.492246] x14: 0000000000000000 x13: ffff8000816d1530 x12: 00000000000004a4 [   57.499380] x11: 000000000000018c x10: ffff8000816fd530 x9 : ffff8000816d1530 [   57.506515] x8 : 00000000fffff7ff x7 : ffff8000816fd530 x6 : 0000000000000001 [   57.513649] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [   57.520782] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0008049b0000 [   57.527916] Call trace: [   57.530354]  sst_nor_write_data+0x6c/0x74 [   57.534361]  sst_nor_write+0xb4/0x18c [   57.538019]  mtd_write_oob_std+0x7c/0x88 [   57.541941]  mtd_write_oob+0x70/0xbc [   57.545511]  mtd_write+0x68/0xa8 [   57.548733]  mtdchar_write+0x10c/0x290 [   57.552477]  vfs_write+0xb4/0x3a8 [   57.555791]  ksys_write+0x74/0x10c [   57.559189]  __arm64_sys_write+0x1c/0x28 [   57.563109]  invoke_syscall+0x54/0x11c [   57.566856]  el0_svc_common.constprop.0+0xc0/0xe0 [   57.571557]  do_el0_svc+0x1c/0x28 [   57.574868]  el0_svc+0x30/0xcc [   57.577921]  el0t_64_sync_handler+0x120/0x12c [   57.582276]  el0t_64_sync+0x190/0x194 [   57.585933] ---[ end trace 0000000000000000 ]---  [pratyush@kernel.org: add Cc stable tag]
CVE-2024-13617: The aoa-downloadable WordPress plugin through 0.1.0 doesn't validate a parameter in its download function, allowing unauthenticated attackers to download arbitrary files from the server
CVE-2024-13618: The aoa-downloadable WordPress plugin through 0.1.0 lacks authorization and authentication for requests to its download.php endpoint, allowing unauthenticated visitors to make requests to arbitrary URLs.
CVE-2025-21876: In the Linux kernel, the following vulnerability has been resolved:  iommu/vt-d: Fix suspicious RCU usage  Commit <d74169ceb0d2> ("iommu/vt-d: Allocate DMAR fault interrupts locally") moved the call to enable_drhd_fault_handling() to a code path that does not hold any lock while traversing the drhd list. Fix it by ensuring the dmar_global_lock lock is held when traversing the drhd list.  Without this fix, the following warning is triggered:  =============================  WARNING: suspicious RCU usage  6.14.0-rc3 #55 Not tainted  -----------------------------  drivers/iommu/intel/dmar.c:2046 RCU-list traversed in non-reader section!!                other info that might help us debug this:                rcu_scheduler_active = 1, debug_locks = 1  2 locks held by cpuhp/1/23:  #0: ffffffff84a67c50 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0  #1: ffffffff84a6a380 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x87/0x2c0  stack backtrace:  CPU: 1 UID: 0 PID: 23 Comm: cpuhp/1 Not tainted 6.14.0-rc3 #55  Call Trace:   <TASK>   dump_stack_lvl+0xb7/0xd0   lockdep_rcu_suspicious+0x159/0x1f0   ? __pfx_enable_drhd_fault_handling+0x10/0x10   enable_drhd_fault_handling+0x151/0x180   cpuhp_invoke_callback+0x1df/0x990   cpuhp_thread_fun+0x1ea/0x2c0   smpboot_thread_fn+0x1f5/0x2e0   ? __pfx_smpboot_thread_fn+0x10/0x10   kthread+0x12a/0x2d0   ? __pfx_kthread+0x10/0x10   ret_from_fork+0x4a/0x60   ? __pfx_kthread+0x10/0x10   ret_from_fork_asm+0x1a/0x30   </TASK>  Holding the lock in enable_drhd_fault_handling() triggers a lockdep splat about a possible deadlock between dmar_global_lock and cpu_hotplug_lock. This is avoided by not holding dmar_global_lock when calling iommu_device_register(), which initiates the device probe process.
CVE-2025-21885: In the Linux kernel, the following vulnerability has been resolved:  RDMA/bnxt_re: Fix the page details for the srq created by kernel consumers  While using nvme target with use_srq on, below kernel panic is noticed.  [  549.698111] bnxt_en 0000:41:00.0 enp65s0np0: FEC autoneg off encoding: Clause 91 RS(544,514) [  566.393619] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI .. [  566.393799]  <TASK> [  566.393807]  ? __die_body+0x1a/0x60 [  566.393823]  ? die+0x38/0x60 [  566.393835]  ? do_trap+0xe4/0x110 [  566.393847]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re] [  566.393867]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re] [  566.393881]  ? do_error_trap+0x7c/0x120 [  566.393890]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re] [  566.393911]  ? exc_divide_error+0x34/0x50 [  566.393923]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re] [  566.393939]  ? asm_exc_divide_error+0x16/0x20 [  566.393966]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re] [  566.393997]  bnxt_qplib_create_srq+0xc9/0x340 [bnxt_re] [  566.394040]  bnxt_re_create_srq+0x335/0x3b0 [bnxt_re] [  566.394057]  ? srso_return_thunk+0x5/0x5f [  566.394068]  ? __init_swait_queue_head+0x4a/0x60 [  566.394090]  ib_create_srq_user+0xa7/0x150 [ib_core] [  566.394147]  nvmet_rdma_queue_connect+0x7d0/0xbe0 [nvmet_rdma] [  566.394174]  ? lock_release+0x22c/0x3f0 [  566.394187]  ? srso_return_thunk+0x5/0x5f  Page size and shift info is set only for the user space SRQs. Set page size and page shift for kernel space SRQs also.
CVE-2021-4454: In the Linux kernel, the following vulnerability has been resolved:  can: j1939: fix errant WARN_ON_ONCE in j1939_session_deactivate  The conclusion "j1939_session_deactivate() should be called with a session ref-count of at least 2" is incorrect. In some concurrent scenarios, j1939_session_deactivate can be called with the session ref-count less than 2. But there is not any problem because it will check the session active state before session putting in j1939_session_deactivate_locked().  Here is the concurrent scenario of the problem reported by syzbot and my reproduction log.          cpu0                            cpu1                                 j1939_xtp_rx_eoma j1939_xtp_rx_abort_one                                 j1939_session_get_by_addr [kref == 2] j1939_session_get_by_addr [kref == 3] j1939_session_deactivate [kref == 2] j1939_session_put [kref == 1]     j1939_session_completed     j1939_session_deactivate     WARN_ON_ONCE(kref < 2)  ===================================================== WARNING: CPU: 1 PID: 21 at net/can/j1939/transport.c:1088 j1939_session_deactivate+0x5f/0x70 CPU: 1 PID: 21 Comm: ksoftirqd/1 Not tainted 5.14.0-rc7+ #32 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014 RIP: 0010:j1939_session_deactivate+0x5f/0x70 Call Trace:  j1939_session_deactivate_activate_next+0x11/0x28  j1939_xtp_rx_eoma+0x12a/0x180  j1939_tp_recv+0x4a2/0x510  j1939_can_recv+0x226/0x380  can_rcv_filter+0xf8/0x220  can_receive+0x102/0x220  ? process_backlog+0xf0/0x2c0  can_rcv+0x53/0xf0  __netif_receive_skb_one_core+0x67/0x90  ? process_backlog+0x97/0x2c0  __netif_receive_skb+0x22/0x80
CVE-2022-49747: In the Linux kernel, the following vulnerability has been resolved:  erofs/zmap.c: Fix incorrect offset calculation  Effective offset to add to length was being incorrectly calculated, which resulted in iomap->length being set to 0, triggering a WARN_ON in iomap_iter_done().  Fix that, and describe it in comments.  This was reported as a crash by syzbot under an issue about a warning encountered in iomap_iter_done(), but unrelated to erofs.  C reproducer: https://syzkaller.appspot.com/text?tag=ReproC&x=1037a6b2880000 Kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&x=e2021a61197ebe02 Dashboard link: https://syzkaller.appspot.com/bug?extid=a8e049cd3abd342936b6
CVE-2022-49752: In the Linux kernel, the following vulnerability has been resolved:  device property: fix of node refcount leak in fwnode_graph_get_next_endpoint()  The 'parent' returned by fwnode_graph_get_port_parent() with refcount incremented when 'prev' is not NULL, it needs be put when finish using it.  Because the parent is const, introduce a new variable to store the returned fwnode, then put it before returning from fwnode_graph_get_next_endpoint().
CVE-2023-52940: In the Linux kernel, the following vulnerability has been resolved:  mm: multi-gen LRU: fix crash during cgroup migration  lru_gen_migrate_mm() assumes lru_gen_add_mm() runs prior to itself.  This isn't true for the following scenario:      CPU 1                         CPU 2    clone()     cgroup_can_fork()                                 cgroup_procs_write()     cgroup_post_fork()                                   task_lock()                                   lru_gen_migrate_mm()                                   task_unlock()     task_lock()     lru_gen_add_mm()     task_unlock()  And when the above happens, kernel crashes because of linked list corruption (mm_struct->lru_gen.list).
CVE-2023-52978: In the Linux kernel, the following vulnerability has been resolved:  riscv: kprobe: Fixup kernel panic when probing an illegal position  The kernel would panic when probed for an illegal position. eg:  (CONFIG_RISCV_ISA_C=n)  echo 'p:hello kernel_clone+0x16 a0=%a0' >> kprobe_events echo 1 > events/kprobes/hello/enable cat trace  Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: __do_sys_newfstatat+0xb8/0xb8 CPU: 0 PID: 111 Comm: sh Not tainted 6.2.0-rc1-00027-g2d398fe49a4d #490 Hardware name: riscv-virtio,qemu (DT) Call Trace: [<ffffffff80007268>] dump_backtrace+0x38/0x48 [<ffffffff80c5e83c>] show_stack+0x50/0x68 [<ffffffff80c6da28>] dump_stack_lvl+0x60/0x84 [<ffffffff80c6da6c>] dump_stack+0x20/0x30 [<ffffffff80c5ecf4>] panic+0x160/0x374 [<ffffffff80c6db94>] generic_handle_arch_irq+0x0/0xa8 [<ffffffff802deeb0>] sys_newstat+0x0/0x30 [<ffffffff800158c0>] sys_clone+0x20/0x30 [<ffffffff800039e8>] ret_from_syscall+0x0/0x4 ---[ end Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: __do_sys_newfstatat+0xb8/0xb8 ]---  That is because the kprobe's ebreak instruction broke the kernel's original code. The user should guarantee the correction of the probe position, but it couldn't make the kernel panic.  This patch adds arch_check_kprobe in arch_prepare_kprobe to prevent an illegal position (Such as the middle of an instruction).