Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2022-49512 State: PUBLISHED Published: 2025-02-26T02:13:42.128Z Last Updated: 2025-05-04T08:39:31.928Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: denali: Use managed device resources All of the resources used by this driver has managed interfaces, so use them. Otherwise we will get the following splat: [ 4.472703] denali-nand-pci 0000:00:05.0: timeout while waiting for irq 0x1000 [ 4.474071] denali-nand-pci: probe of 0000:00:05.0 failed with error -5 [ 4.473538] nand: No NAND device found [ 4.474068] BUG: unable to handle page fault for address: ffffc90005000410 [ 4.475169] #PF: supervisor write ac
ce found [ 4.474068] BUG: unable to handle page fault for address: ffffc90005000410 [ 4.475169] #PF: supervisor write access in kernel mode [ 4.475579] #PF: error_code(0x0002) - not-present page [ 4.478362] RIP: 0010:iowrite32+0x9/0x50 [ 4.486068] Call Trace: [ 4.486269] <IRQ> [ 4.486443] denali_isr+0x15b/0x300 [denali] [ 4.486788] ? denali_direct_write+0x50/0x50 [denali] [ 4.487189] __handle_irq_event_percpu+0x161/0x3b0 [ 4.487571] handle_irq_event+0x7d/0x1b0 [ 4.487884] handle_fasteoi_irq+0x2b0/0x770 [ 4.488219] __common_interrupt+0xc8/0x1b0 [ 4.488549] common_interrupt+0x9a/0xc0 References: - https://git.kernel.org/stable/c/3c68daf4a368cd9e63ae5a2145c9e4a6f838c166 - https://git.kernel.org
x9a/0xc0 References: - https://git.kernel.org/stable/c/3c68daf4a368cd9e63ae5a2145c9e4a6f838c166 - https://git.kernel.org/stable/c/3830dbdfb9a4aec680e43ed80b9f23db7a88eac9 - https://git.kernel.org/stable/c/87149cf9186201a63f0e0b93d9fa93d480bcb771 - https://git.kernel.org/stable/c/efea1dd176edd17c8252051b7de6957f06efc394 - https://git.kernel.org/stable/c/3a745b51cddafade99aaea1b93aad31e9614e230
CVE ID: CVE-2022-49513 State: PUBLISHED Published: 2025-02-26T02:13:42.759Z Last Updated: 2025-05-04T08:39:33.221Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cpufreq: governor: Use kobject release() method to free dbs_data The struct dbs_data embeds a struct gov_attr_set and the struct gov_attr_set embeds a kobject. Since every kobject must have a release() method and we can't use kfree() to free it directly, so introduce cpufreq_dbs_data_release() to release the dbs_data via the kobject::release() method. This fixes the calltrace like below: ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_ti
This fixes the calltrace like below: ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x
464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_o
x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [<ffff8000080849d0>] finish_task_switch.is
4_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [<ffff8000080849d0>] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [<ffff8000090667a4>] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [<ffff8000080106d0>] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [<ffff80000804a618>] __irq_exit_rcu+0x108/0x1a4 [ rjw: Because can be freed by the gov_attr_set_put() in cpufreq_dbs_governor_exit() now, it is also necessary to put the invocation of the governor ->exit() callback into the new cpufreq_dbs_data_release() function. ] References: - https://git.kernel.org/stable/c/a1964688582d26af1328e19b658933659fb54337 - https://git.kern
() function. ] References: - https://git.kernel.org/stable/c/a1964688582d26af1328e19b658933659fb54337 - https://git.kernel.org/stable/c/1e32083f327184b6226ce320ef30085ce785ea4e - https://git.kernel.org/stable/c/a85ee6401a47ae3fc64ba506cacb3e7873823c65
CVE ID: CVE-2022-49514 State: PUBLISHED Published: 2025-02-26T02:13:43.398Z Last Updated: 2025-10-01T19:46:42.268Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe Call of_node_put(platform_node) to avoid refcount leak in the error path. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0a1901f34f775b83ea4b8dbb5ed992147b9b8531 - https://git.kernel.org/stable/c/1e932aba3c7628c9f880ee9c2cfcc2ae3ba0c01e - https://git.kernel.org/stable/c/cc43b9fdca519c5b13be6a717bacbebccd628cf6 - https://git.kernel.org/stable/c/23f340ed906c7
https://git.kernel.org/stable/c/cc43b9fdca519c5b13be6a717bacbebccd628cf6 - https://git.kernel.org/stable/c/23f340ed906c758cec6527376768e3bc1474ac30 - https://git.kernel.org/stable/c/fb66e0512e5ccc093070e21cf88cce8d98c181b5 - https://git.kernel.org/stable/c/48889eb3cce91d7f58e02bc07277b7f724b7a54a - https://git.kernel.org/stable/c/ebd5cb4f1f3f10b839e7575219e0f17b60c23113 - https://git.kernel.org/stable/c/98d5afe868df998b0244f4c229ab758b4083684a - https://git.kernel.org/stable/c/4f4e0454e226de3bf4efd7e7924d1edc571c52d5
CVE ID: CVE-2022-49515 State: PUBLISHED Published: 2025-02-26T02:13:43.888Z Last Updated: 2025-05-04T08:39:35.897Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: cs35l41: Fix an out-of-bounds access in otp_packed_element_t The CS35L41_NUM_OTP_ELEM is 100, but only 99 entries are defined in the array otp_map_1/2[CS35L41_NUM_OTP_ELEM], this will trigger UBSAN to report a shift-out-of-bounds warning in the cs35l41_otp_unpack() since the last entry in the array will result in GENMASK(-1, 0). UBSAN reports this problem: UBSAN: shift-out-of-bounds in /home/hwang4/build/jammy/jammy/sound/soc/codecs/cs35l41-lib.c:836:8 shift expo
is problem: UBSAN: shift-out-of-bounds in /home/hwang4/build/jammy/jammy/sound/soc/codecs/cs35l41-lib.c:836:8 shift exponent 64 is too large for 64-bit type 'long unsigned int' CPU: 10 PID: 595 Comm: systemd-udevd Not tainted 5.15.0-23-generic #23 Hardware name: LENOVO \x02MFG_IN_GO/\x02MFG_IN_GO, BIOS N3GET19W (1.00 ) 03/11/2022 Call Trace: <TASK> show_stack+0x52/0x58 dump_stack_lvl+0x4a/0x5f dump_stack+0x10/0x12 ubsan_epilogue+0x9/0x45 __ubsan_handle_shift_out_of_bounds.cold+0x61/0xef ? regmap_unlock_mutex+0xe/0x10 cs35l41_otp_unpack.cold+0x1c6/0x2b2 [snd_soc_cs35l41_lib] cs35l41_hda_probe+0x24f/0x33a [snd_hda_scodec_cs35l41] cs35l41_hda_i2c_probe+0x65/0x90 [snd_hda_scodec_cs35l41_i2c] ? c
cs35l41_hda_probe+0x24f/0x33a [snd_hda_scodec_cs35l41] cs35l41_hda_i2c_probe+0x65/0x90 [snd_hda_scodec_cs35l41_i2c] ? cs35l41_hda_i2c_remove+0x20/0x20 [snd_hda_scodec_cs35l41_i2c] i2c_device_probe+0x252/0x2b0 References: - https://git.kernel.org/stable/c/dbc35268e14d5d89c7a9db72009ad4dcd9ede646 - https://git.kernel.org/stable/c/a59b9958416096dd21dc4f62b0c5be525d459ca8 - https://git.kernel.org/stable/c/9f342904216f378e88008bb0ce1ae200a4b99fe8
CVE ID: CVE-2022-49516 State: PUBLISHED Published: 2025-02-26T02:13:44.359Z Last Updated: 2025-10-01T19:46:42.109Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ice: always check VF VSI pointer values The ice_get_vf_vsi function can return NULL in some cases, such as if handling messages during a reset where the VSI is being removed and recreated. Several places throughout the driver do not bother to check whether this VSI pointer is valid. Static analysis tools maybe report issues because they detect paths where a potentially NULL pointer could be dereferenced. Fix this by checking the return value of ice_get_vf_vsi everywher
here a potentially NULL pointer could be dereferenced. Fix this by checking the return value of ice_get_vf_vsi everywhere. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/e7be3877589d539c52e5d1d23a625f889b541b9d - https://git.kernel.org/stable/c/baeb705fd6a7245cc1fa69ed991a9cffdf44a174
CVE ID: CVE-2022-49517 State: PUBLISHED Published: 2025-02-26T02:13:44.853Z Last Updated: 2025-10-01T19:46:41.962Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: Fix missing of_node_put in mt2701_wm8960_machine_probe This node pointer is returned by of_parse_phandle() with refcount incremented in this function. Calling of_node_put() to avoid the refcount leak. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/bc2afecaabd2a2c9f17e43b4793a30e3461bfb29 - https://git.kernel.org/stable/c/9345122f5fb9f97a206f440f38bb656e53f46912 - https://git.kernel.org/stable/c/c71494f5f
9 - https://git.kernel.org/stable/c/9345122f5fb9f97a206f440f38bb656e53f46912 - https://git.kernel.org/stable/c/c71494f5f2b444adfd992a7359a0d2a791642b39 - https://git.kernel.org/stable/c/f279c49f17ce10866087ea6c0c57382158974b63 - https://git.kernel.org/stable/c/61a85a20e8df5e0a92cfe169c92425c7bae0753b - https://git.kernel.org/stable/c/318afb1442eeef089fe7f8a8297d97c0302ff6f6 - https://git.kernel.org/stable/c/94587aa17abf8b26f543d2b29c44abc21bc36836 - https://git.kernel.org/stable/c/05654431a18fe24e5e46a375d98904134628a102
CVE ID: CVE-2022-49518 State: PUBLISHED Published: 2025-02-26T02:13:45.396Z Last Updated: 2025-05-04T08:39:39.327Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: ipc3-topology: Correct get_control_data for non bytes payload It is possible to craft a topology where sof_get_control_data() would do out of bounds access because it expects that it is only called when the payload is bytes type. Confusingly it also handles other types of controls, but the payload parsing implementation is only valid for bytes. Fix the code to count the non bytes controls and instead of storing a pointer to sof_abi_hdr in sof_widget_data (wh
tes. Fix the code to count the non bytes controls and instead of storing a pointer to sof_abi_hdr in sof_widget_data (which is only valid for bytes), store the pointer to the data itself and add a new member to save the size of the data. In case of non bytes controls we store the pointer to the chanv itself, which is just an array of values at the end. In case of bytes control, drop the wrong cdata->data (wdata[i].pdata) check against NULL since it is incorrect and invalid in this context. The data is pointing to the end of cdata struct, so it should never be null. References: - https://git.kernel.org/stable/c/896b03bb7c7010042786cfae2115083d4c241dd3 - https://git.kernel.org/stable/c/a962890
es: - https://git.kernel.org/stable/c/896b03bb7c7010042786cfae2115083d4c241dd3 - https://git.kernel.org/stable/c/a962890a5a3cce903ff7c7a19fadee63ed9efdc7
CVE ID: CVE-2022-49519 State: PUBLISHED Published: 2025-02-26T02:13:45.857Z Last Updated: 2025-09-15T12:14:07.773Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ath10k: skip ath10k_halt during suspend for driver state RESTARTING Double free crash is observed when FW recovery(caused by wmi timeout/crash) is followed by immediate suspend event. The FW recovery is triggered by ath10k_core_restart() which calls driver clean up via ath10k_halt(). When the suspend event occurs between the FW recovery, the restart worker thread is put into frozen state until suspend completes. The suspend event triggers ath10k_stop() which again trig
orker thread is put into frozen state until suspend completes. The suspend event triggers ath10k_stop() which again triggers ath10k_halt() The double invocation of ath10k_halt() causes ath10k_htt_rx_free() to be called twice(Note: ath10k_htt_rx_alloc was not called by restart worker thread because of its frozen state), causing the crash. To fix this, during the suspend flow, skip call to ath10k_halt() in ath10k_stop() when the current driver state is ATH10K_STATE_RESTARTING. Also, for driver state ATH10K_STATE_RESTARTING, call ath10k_wait_for_suspend() in ath10k_stop(). This is because call to ath10k_wait_for_suspend() is skipped later in [ath10k_halt() > ath10k_core_stop()] for the driver s
s is because call to ath10k_wait_for_suspend() is skipped later in [ath10k_halt() > ath10k_core_stop()] for the driver state ATH10K_STATE_RESTARTING. The frozen restart worker thread will be cancelled during resume when the device comes out of suspend. Below is the crash stack for reference: [ 428.469167] ------------[ cut here ]------------ [ 428.469180] kernel BUG at mm/slub.c:4150! [ 428.469193] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 428.469219] Workqueue: events_unbound async_run_entry_fn [ 428.469230] RIP: 0010:kfree+0x319/0x31b [ 428.469241] RSP: 0018:ffffa1fac015fc30 EFLAGS: 00010246 [ 428.469247] RAX: ffffedb10419d108 RBX: ffff8c05262b0000 [ 428.469252] RDX: ffff8c04a8c07000 R
015fc30 EFLAGS: 00010246 [ 428.469247] RAX: ffffedb10419d108 RBX: ffff8c05262b0000 [ 428.469252] RDX: ffff8c04a8c07000 RSI: 0000000000000000 [ 428.469256] RBP: ffffa1fac015fc78 R08: 0000000000000000 [ 428.469276] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 428.469285] Call Trace: [ 428.469295] ? dma_free_attrs+0x5f/0x7d [ 428.469320] ath10k_core_stop+0x5b/0x6f [ 428.469336] ath10k_halt+0x126/0x177 [ 428.469352] ath10k_stop+0x41/0x7e [ 428.469387] drv_stop+0x88/0x10e [ 428.469410] __ieee80211_suspend+0x297/0x411 [ 428.469441] rdev_suspend+0x6e/0xd0 [ 428.469462] wiphy_suspend+0xb1/0x105 [ 428.469483] ? name_show+0x2d/0x2d [ 428.469490] dpm_run_callback+0x8c/0x126 [ 428.469511] ? name_s
_suspend+0xb1/0x105 [ 428.469483] ? name_show+0x2d/0x2d [ 428.469490] dpm_run_callback+0x8c/0x126 [ 428.469511] ? name_show+0x2d/0x2d [ 428.469517] __device_suspend+0x2e7/0x41b [ 428.469523] async_suspend+0x1f/0x93 [ 428.469529] async_run_entry_fn+0x3d/0xd1 [ 428.469535] process_one_work+0x1b1/0x329 [ 428.469541] worker_thread+0x213/0x372 [ 428.469547] kthread+0x150/0x15f [ 428.469552] ? pr_cont_work+0x58/0x58 [ 428.469558] ? kthread_blkcg+0x31/0x31 Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1 References: - https://git.kernel.org/stable/c/8aa3750986ffcf73e0692db3b40dd3a8e8c0c575 - https://git.kernel.org/stable/c/c2272428090d0d215a3f017cbbbad731c07eee53 - https://git.kernel.or
92db3b40dd3a8e8c0c575 - https://git.kernel.org/stable/c/c2272428090d0d215a3f017cbbbad731c07eee53 - https://git.kernel.org/stable/c/7eb14cb604f49e58b7cf6faa87961a865a3c8649 - https://git.kernel.org/stable/c/5321e5211b5dc873e2e3d0deb749e69ecf4dbfe5 - https://git.kernel.org/stable/c/b72a4aff947ba807177bdabb43debaf2c66bee05
CVE ID: CVE-2022-49520 State: PUBLISHED Published: 2025-02-26T02:13:46.336Z Last Updated: 2025-05-04T08:39:41.554Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64: compat: Do not treat syscall number as ESR_ELx for a bad syscall If a compat process tries to execute an unknown system call above the __ARM_NR_COMPAT_END number, the kernel sends a SIGILL signal to the offending process. Information about the error is printed to dmesg in compat_arm_syscall() -> arm64_notify_die() -> arm64_force_sig_fault() -> arm64_show_signal(). arm64_show_signal() interprets a non-zero value for current->thread.fault_code as an exception synd
arm64_show_signal(). arm64_show_signal() interprets a non-zero value for current->thread.fault_code as an exception syndrome and displays the message associated with the ESR_ELx.EC field (bits 31:26). current->thread.fault_code is set in compat_arm_syscall() -> arm64_notify_die() with the bad syscall number instead of a valid ESR_ELx value. This means that the ESR_ELx.EC field has the value that the user set for the syscall number and the kernel can end up printing bogus exception messages*. For example, for the syscall number 0x68000000, which evaluates to ESR_ELx.EC value of 0x1A (ESR_ELx_EC_FPAC) the kernel prints this error: [ 18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERE
of 0x1A (ESR_ELx_EC_FPAC) the kernel prints this error: [ 18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - bad compat syscall(2) in syscall[10000+50000] [ 18.350639] CPU: 2 PID: 300 Comm: syscall Not tainted 5.18.0-rc1 #79 [ 18.351249] Hardware name: Pine64 RockPro64 v2.0 (DT) [..] which is misleading, as the bad compat syscall has nothing to do with pointer authentication. Stop arm64_show_signal() from printing exception syndrome information by having compat_arm_syscall() set the ESR_ELx value to 0, as it has no meaning for an invalid system call number. The example above now becomes: [ 19.935275] syscall[301]: unhandled exception: Oops - bad compat
id system call number. The example above now becomes: [ 19.935275] syscall[301]: unhandled exception: Oops - bad compat syscall(2) in syscall[10000+50000] [ 19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80 [ 19.936894] Hardware name: Pine64 RockPro64 v2.0 (DT) [..] which although shows less information because the syscall number, wrongfully advertised as the ESR value, is missing, it is better than showing plainly wrong information. The syscall number can be easily obtained with strace. *A 32-bit value above or equal to 0x8000_0000 is interpreted as a negative integer in compat_arm_syscal() and the condition scno < __ARM_NR_COMPAT_END evaluates to true;
interpreted as a negative integer in compat_arm_syscal() and the condition scno < __ARM_NR_COMPAT_END evaluates to true; the syscall will exit to userspace in this case with the ENOSYS error code instead of arm64_notify_die() being called. References: - https://git.kernel.org/stable/c/efd183d988b416fcdf6f7c298a17ced4859ca77d - https://git.kernel.org/stable/c/ad97425d23af3c3b8d4f6a2bb666cb485087c007 - https://git.kernel.org/stable/c/621916afe8cd4f322eb12759b64a2f938d4e551d - https://git.kernel.org/stable/c/095e975f8150ccd7f852eb578c1cdbdd2f517c7a - https://git.kernel.org/stable/c/3910ae71cb963fa2b68e684489d4fc3d105afda0 - https://git.kernel.org/stable/c/3fed9e551417b84038b15117732ea4505eee386
ble/c/3910ae71cb963fa2b68e684489d4fc3d105afda0 - https://git.kernel.org/stable/c/3fed9e551417b84038b15117732ea4505eee386b
CVE ID: CVE-2022-49521 State: PUBLISHED Published: 2025-02-26T02:13:46.812Z Last Updated: 2025-05-04T08:39:42.826Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix resource leak in lpfc_sli4_send_seq_to_ulp() If no handler is found in lpfc_complete_unsol_iocb() to match the rctl of a received frame, the frame is dropped and resources are leaked. Fix by returning resources when discarding an unhandled frame type. Update lpfc_fc_frame_check() handling of NOP basic link service. References: - https://git.kernel.org/stable/c/fa1b509d41c5433672f72c0615cf4aefa0611c99 - https://git.kernel.org/stable/c/40cf4ea4d2d497f7732
//git.kernel.org/stable/c/fa1b509d41c5433672f72c0615cf4aefa0611c99 - https://git.kernel.org/stable/c/40cf4ea4d2d497f7732c87d350ba5c3f5e8a43a1 - https://git.kernel.org/stable/c/08709769ff2fb6c5ffedcda3742700d8ea1618a8 - https://git.kernel.org/stable/c/7860d8f8082605b57596aa82d3d438c1fdad9a9e - https://git.kernel.org/stable/c/646db1a560f44236b7278b822ca99a1d3b6ea72c
CVE ID: CVE-2022-49522 State: PUBLISHED Published: 2025-02-26T02:13:47.278Z Last Updated: 2025-05-04T08:39:43.953Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mmc: jz4740: Apply DMA engine limits to maximum segment size Do what is done in other DMA-enabled MMC host drivers (cf. host/mmci.c) and limit the maximum segment size based on the DMA engine's capabilities. This is needed to avoid warnings like the following with CONFIG_DMA_API_DEBUG=y. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 21 at kernel/dma/debug.c:1162 debug_dma_map_sg+0x2f4/0x39c DMA-API: jz4780-dma 13420000.dma-controller: mapping sg segment lon
kernel/dma/debug.c:1162 debug_dma_map_sg+0x2f4/0x39c DMA-API: jz4780-dma 13420000.dma-controller: mapping sg segment longer than device claims to support [len=98304] [max=65536] CPU: 0 PID: 21 Comm: kworker/0:1H Not tainted 5.18.0-rc1 #19 Workqueue: kblockd blk_mq_run_work_fn Stack : 81575aec 00000004 80620000 80620000 80620000 805e7358 00000009 801537ac 814c832c 806276e3 806e34b4 80620000 81575aec 00000001 81575ab8 09291444 00000000 00000000 805e7358 81575958 ffffffea 8157596c 00000000 636f6c62 6220646b 80387a70 0000000f 6d5f6b6c 80620000 00000000 81575ba4 00000009 805e170c 80896640 00000001 00010000 00000000 00000000 00006098 806e0000 ... Call Trace: [<80107670>] show_stack+0x84/0x120 [<80
c 80896640 00000001 00010000 00000000 00000000 00006098 806e0000 ... Call Trace: [<80107670>] show_stack+0x84/0x120 [<80528cd8>] __warn+0xb8/0xec [<80528d78>] warn_slowpath_fmt+0x6c/0xb8 [<8016f1d4>] debug_dma_map_sg+0x2f4/0x39c [<80169d4c>] __dma_map_sg_attrs+0xf0/0x118 [<8016a27c>] dma_map_sg_attrs+0x14/0x28 [<804f66b4>] jz4740_mmc_prepare_dma_data+0x74/0xa4 [<804f6714>] jz4740_mmc_pre_request+0x30/0x54 [<804f4ff4>] mmc_blk_mq_issue_rq+0x6e0/0x7bc [<804f5590>] mmc_mq_queue_rq+0x220/0x2d4 [<8038b2c0>] blk_mq_dispatch_rq_list+0x480/0x664 [<80391040>] blk_mq_do_dispatch_sched+0x2dc/0x370 [<80391468>] __blk_mq_sched_dispatch_requests+0xec/0x164 [<80391540>] blk_mq_sched_dispatch_requests+0x44/
d+0x2dc/0x370 [<80391468>] __blk_mq_sched_dispatch_requests+0xec/0x164 [<80391540>] blk_mq_sched_dispatch_requests+0x44/0x94 [<80387900>] __blk_mq_run_hw_queue+0xb0/0xcc [<80134c14>] process_one_work+0x1b8/0x264 [<80134ff8>] worker_thread+0x2ec/0x3b8 [<8013b13c>] kthread+0x104/0x10c [<80101dcc>] ret_from_kernel_thread+0x14/0x1c ---[ end trace 0000000000000000 ]--- References: - https://git.kernel.org/stable/c/7923f95997a79cef2ad161a2facae64c25a0bca0 - https://git.kernel.org/stable/c/90281cadf5077f2d2bec8b08c2ead1f8cd12660e - https://git.kernel.org/stable/c/353298cadbd4c7d8e8a16d6000066414694933c3 - https://git.kernel.org/stable/c/807f90f1960a59dc557542b818c484a8db9ac978 - https://git.kernel.
8a16d6000066414694933c3 - https://git.kernel.org/stable/c/807f90f1960a59dc557542b818c484a8db9ac978 - https://git.kernel.org/stable/c/a828920b9ec0d89d3011198d482b7fe224d2de19 - https://git.kernel.org/stable/c/afadb04f1d6e74b18a253403f5274cde5e3fd7bd