Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
0x70 [amdgpu] [ 7283.170964] RSP: 0018:ffff9a5fc3967d00 EFLAGS: 00010246 [ 7283.170967] RAX: ffff98d88afd3040 RBX: ffff98d89da20000 RCX: 0000000000000000 [ 7283.170969] RDX: 0000000000000000 RSI: ffff98d89da2bef8 RDI: ffff98d89da20000 [ 7283.170971] RBP: ffff98d89da20000 R08: ffff98d89da2ca18 R09: 0000000000000006 [ 7283.170973] R10: ffffd5764243c008 R11: 0000000000000000 R12: 0000000000001050 [ 7283.170975] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105 [ 7283.170978] FS: 0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000 [ 7283.170981] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7283.170983] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 000
81] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 7283.170983] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0 [ 7283.170986] Call Trace: [ 7283.170988] <TASK> [ 7283.170989] gfx_v9_0_hw_fini+0x1c/0x6d0 [amdgpu] [ 7283.171655] amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu] [ 7283.172245] amdgpu_device_suspend+0x103/0x180 [amdgpu] [ 7283.172823] amdgpu_pmops_freeze+0x21/0x60 [amdgpu] [ 7283.173412] pci_pm_freeze+0x54/0xc0 [ 7283.173419] ? __pfx_pci_pm_freeze+0x10/0x10 [ 7283.173425] dpm_run_callback+0x98/0x200 [ 7283.173430] __device_suspend+0x164/0x5f0 v2: drop gfx11 as it's fixed in a different solution by retiring cp_ecc_irq funcs(Hawking) References: - https:/
4/0x5f0 v2: drop gfx11 as it's fixed in a different solution by retiring cp_ecc_irq funcs(Hawking) References: - https://git.kernel.org/stable/c/625d4112ea25dbad7ddf749fd5c1287ceffb2339 - https://git.kernel.org/stable/c/20ca90ceda71ed90a4d6960acbe7d5e120b40c0d - https://git.kernel.org/stable/c/cd3c0f7013c37cd24fc40b601319007f136c1201 - https://git.kernel.org/stable/c/f661ad53658a1ea35c004af1f5fbe25c4d1cdb08 - https://git.kernel.org/stable/c/3d28af21a874c5123d1681c2d686627f7ff7e488 - https://git.kernel.org/stable/c/efce310db74fdc6d2acd959f3582972ae4a8d7d5 - https://git.kernel.org/stable/c/4a76680311330aefe5074bed8f06afa354b85c48
CVE ID: CVE-2023-53472 State: PUBLISHED Published: 2025-10-01T11:42:41.951Z Last Updated: 2025-10-01T11:42:41.951Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: pwm: lpc32xx: Remove handling of PWM channels Because LPC32xx PWM controllers have only a single output which is registered as the only PWM device/channel per controller, it is known in advance that pwm->hwpwm value is always 0. On basis of this fact simplify the code by removing operations with pwm->hwpwm, there is no controls which require channel number as input. Even though I wasn't aware at the time when I forward ported that patch, this fixes a null pointer deref
umber as input. Even though I wasn't aware at the time when I forward ported that patch, this fixes a null pointer dereference as lpc32xx->chip.pwms is NULL before devm_pwmchip_add() is called. References: - https://git.kernel.org/stable/c/abd9b2ee4047ccd980decbf26d61f9637604b1d5 - https://git.kernel.org/stable/c/a9a505f5b39d8fff1a55963a5e524c84639e98b2 - https://git.kernel.org/stable/c/04301da4d87067a989f70ee56942bf9d97cd2a45 - https://git.kernel.org/stable/c/a2d9d884e84bfd37892219b1f55847f36d8e9901 - https://git.kernel.org/stable/c/5e22217c11424ef958ba28d03ff7167b4d7a8914 - https://git.kernel.org/stable/c/523f6268e86552a048975749251184c4e9a4b38f - https://git.kernel.org/stable/c/e3a0ddbaf7
- https://git.kernel.org/stable/c/523f6268e86552a048975749251184c4e9a4b38f - https://git.kernel.org/stable/c/e3a0ddbaf7f1f9ffc070718b417461ced3268758 - https://git.kernel.org/stable/c/4aae44f65827f0213a7361cf9c32cfe06114473f
CVE ID: CVE-2023-53473 State: PUBLISHED Published: 2025-10-01T11:42:42.875Z Last Updated: 2025-10-29T10:50:27.391Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: improve error handling from ext4_dirhash() The ext4_dirhash() will *almost* never fail, especially when the hash tree feature was first introduced. However, with the addition of support of encrypted, casefolded file names, that function can most certainly fail today. So make sure the callers of ext4_dirhash() properly check for failures, and reflect the errors back up to their callers. References: - https://git.kernel.org/stable/c/b2531936118deb3f479c4fa1bcd787b7
lect the errors back up to their callers. References: - https://git.kernel.org/stable/c/b2531936118deb3f479c4fa1bcd787b74b8faa6a - https://git.kernel.org/stable/c/f68876aeef96ef8b708ab10b9cb47ce0a5adb424 - https://git.kernel.org/stable/c/70d579aefa652a06af97e013e3fbbabbe5a43553 - https://git.kernel.org/stable/c/c1fae027da61fe8e7eb99f7244297e81bc0f1e43 - https://git.kernel.org/stable/c/4b3cb1d108bfc2aebb0d7c8a52261a53cf7f5786
CVE ID: CVE-2023-53474 State: PUBLISHED Published: 2025-10-01T11:42:43.798Z Last Updated: 2025-10-01T11:42:43.798Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/MCE/AMD: Use an u64 for bank_map Thee maximum number of MCA banks is 64 (MAX_NR_BANKS), see a0bc32b3cacf ("x86/mce: Increase maximum number of banks to 64"). However, the bank_map which contains a bitfield of which banks to initialize is of type unsigned int and that overflows when those bit numbers are >= 32, leading to UBSAN complaining correctly: UBSAN: shift-out-of-bounds in arch/x86/kernel/cpu/mce/amd.c:1365:38 shift exponent 32 is too large for 32-bit type 'i
y: UBSAN: shift-out-of-bounds in arch/x86/kernel/cpu/mce/amd.c:1365:38 shift exponent 32 is too large for 32-bit type 'int' Change the bank_map to a u64 and use the proper BIT_ULL() macro when modifying bits in there. [ bp: Rewrite commit message. ] References: - https://git.kernel.org/stable/c/a9b9ea0e63a0ec5e97bf1219ab6dcbd55e362f83 - https://git.kernel.org/stable/c/11c58a0c1937c157dbdf82d5ab634d68c99f3098 - https://git.kernel.org/stable/c/ba8ffb1251eb629c2ec35220e3896cf4f7b888a7 - https://git.kernel.org/stable/c/9669fa17287c3af2bbd4868d4c8fdd9e57f8332e - https://git.kernel.org/stable/c/67bb7521b6420d81dab7538c0686f18f7d6d09f4 - https://git.kernel.org/stable/c/4c1cdec319b9aadb65737c3eb1f5c
el.org/stable/c/67bb7521b6420d81dab7538c0686f18f7d6d09f4 - https://git.kernel.org/stable/c/4c1cdec319b9aadb65737c3eb1f5cb74bd6aa156
CVE ID: CVE-2023-53475 State: PUBLISHED Published: 2025-10-01T11:42:44.604Z Last Updated: 2025-10-01T11:42:44.604Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: xhci: tegra: fix sleep in atomic call When we set the dual-role port to Host mode, we observed the following splat: [ 167.057718] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:229 [ 167.057872] Workqueue: events tegra_xusb_usb_phy_work [ 167.057954] Call trace: [ 167.057962] dump_backtrace+0x0/0x210 [ 167.057996] show_stack+0x30/0x50 [ 167.058020] dump_stack_lvl+0x64/0x84 [ 167.058065] dump_stack+0x14/0x34 [ 167.058100] __might_res
show_stack+0x30/0x50 [ 167.058020] dump_stack_lvl+0x64/0x84 [ 167.058065] dump_stack+0x14/0x34 [ 167.058100] __might_resched+0x144/0x180 [ 167.058140] __might_sleep+0x64/0xd0 [ 167.058171] slab_pre_alloc_hook.constprop.0+0xa8/0x110 [ 167.058202] __kmalloc_track_caller+0x74/0x2b0 [ 167.058233] kvasprintf+0xa4/0x190 [ 167.058261] kasprintf+0x58/0x90 [ 167.058285] tegra_xusb_find_port_node.isra.0+0x58/0xd0 [ 167.058334] tegra_xusb_find_port+0x38/0xa0 [ 167.058380] tegra_xusb_padctl_get_usb3_companion+0x38/0xd0 [ 167.058430] tegra_xhci_id_notify+0x8c/0x1e0 [ 167.058473] notifier_call_chain+0x88/0x100 [ 167.058506] atomic_notifier_call_chain+0x44/0x70 [ 167.058537] tegra_xusb_usb_phy_work+0x60/0x
r_call_chain+0x88/0x100 [ 167.058506] atomic_notifier_call_chain+0x44/0x70 [ 167.058537] tegra_xusb_usb_phy_work+0x60/0xd0 [ 167.058581] process_one_work+0x1dc/0x4c0 [ 167.058618] worker_thread+0x54/0x410 [ 167.058650] kthread+0x188/0x1b0 [ 167.058672] ret_from_fork+0x10/0x20 The function tegra_xusb_padctl_get_usb3_companion eventually calls tegra_xusb_find_port and this in turn calls kasprintf which might sleep and so cannot be called from an atomic context. Fix this by moving the call to tegra_xusb_padctl_get_usb3_companion to the tegra_xhci_id_work function where it is really needed. References: - https://git.kernel.org/stable/c/b4b4f17aa46c025da77aed5133b08971959c9684 - https://git.kerne
eally needed. References: - https://git.kernel.org/stable/c/b4b4f17aa46c025da77aed5133b08971959c9684 - https://git.kernel.org/stable/c/1122474b757a5dd8b2b50008a97f33cdb10dff6e - https://git.kernel.org/stable/c/130c61c516cd0684282a8f6ab163281d60642fc5 - https://git.kernel.org/stable/c/1fe6015aa92cc0dfd875c1d3c7c1750a1b0767d9 - https://git.kernel.org/stable/c/4c7f9d2e413dc06a157c4e5dccde84aaf4655eb3
CVE ID: CVE-2023-53476 State: PUBLISHED Published: 2025-10-01T11:42:45.499Z Last Updated: 2025-10-01T11:42:45.499Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iw_cxgb4: Fix potential NULL dereference in c4iw_fill_res_cm_id_entry() This condition needs to match the previous "if (epcp->state == LISTEN) {" exactly to avoid a NULL dereference of either "listen_ep" or "ep". The problem is that "epcp" has been re-assigned so just testing "if (epcp->state == LISTEN) {" a second time is not sufficient. References: - https://git.kernel.org/stable/c/76e0396313c79ecd0df44ee3c18745cfac52b3e6 - https://git.kernel.org/stable/c/24278dc380a
- https://git.kernel.org/stable/c/76e0396313c79ecd0df44ee3c18745cfac52b3e6 - https://git.kernel.org/stable/c/24278dc380aab6a1aef0a75317f57ad4c2453cf6 - https://git.kernel.org/stable/c/dd55240e4364d64befcc575b0d33091881524f42 - https://git.kernel.org/stable/c/4ca446b127c568b59cb8d9748b6f70499624bb18
CVE ID: CVE-2023-53477 State: PUBLISHED Published: 2025-10-01T11:42:46.279Z Last Updated: 2025-10-01T11:42:46.279Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ipv6: Add lwtunnel encap size of all siblings in nexthop calculation In function rt6_nlmsg_size(), the length of nexthop is calculated by multipling the nexthop length of fib6_info and the number of siblings. However if the fib6_info has no lwtunnel but the siblings have lwtunnels, the nexthop length is less than it should be, and it will trigger a warning in inet6_rt_notify() as follows: WARNING: CPU: 0 PID: 6082 at net/ipv6/route.c:6180 inet6_rt_notify+0x120/0x130 ..
rning in inet6_rt_notify() as follows: WARNING: CPU: 0 PID: 6082 at net/ipv6/route.c:6180 inet6_rt_notify+0x120/0x130 ...... Call Trace: <TASK> fib6_add_rt2node+0x685/0xa30 fib6_add+0x96/0x1b0 ip6_route_add+0x50/0xd0 inet6_rtm_newroute+0x97/0xa0 rtnetlink_rcv_msg+0x156/0x3d0 netlink_rcv_skb+0x5a/0x110 netlink_unicast+0x246/0x350 netlink_sendmsg+0x250/0x4c0 sock_sendmsg+0x66/0x70 ___sys_sendmsg+0x7c/0xd0 __sys_sendmsg+0x5d/0xb0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc This bug can be reproduced by script: ip -6 addr add 2002::2/64 dev ens2 ip -6 route add 100::/64 via 2002::1 dev ens2 metric 100 for i in 10 20 30 40 50 60 70; do ip link add link ens2 name ipv_$i type i
add 100::/64 via 2002::1 dev ens2 metric 100 for i in 10 20 30 40 50 60 70; do ip link add link ens2 name ipv_$i type ipvlan ip -6 addr add 2002::$i/64 dev ipv_$i ifconfig ipv_$i up done for i in 10 20 30 40 50 60; do ip -6 route append 100::/64 encap ip6 dst 2002::$i via 2002::1 dev ipv_$i metric 100 done ip -6 route append 100::/64 via 2002::1 dev ipv_70 metric 100 This patch fixes it by adding nexthop_len of every siblings using rt6_nh_nlmsg_size(). References: - https://git.kernel.org/stable/c/aba298b35619213ca787d08d472049627d8cd012 - https://git.kernel.org/stable/c/da26369377f0b671c14692e2d65ceb38131053e1 - https://git.kernel.org/stable/c/dcdddb5f490890d058ea1f194d661219e92fe88d - htt
a26369377f0b671c14692e2d65ceb38131053e1 - https://git.kernel.org/stable/c/dcdddb5f490890d058ea1f194d661219e92fe88d - https://git.kernel.org/stable/c/e11e4d524eba2d3c8fdf897d7ce3853f7573bae9 - https://git.kernel.org/stable/c/aa75d826c221e8d48607aef33836cf872a159cf1 - https://git.kernel.org/stable/c/4cc59f386991ec9374cb4bc83dbe1c0b5a95033f
CVE ID: CVE-2023-53478 State: PUBLISHED Published: 2025-10-01T11:42:47.185Z Last Updated: 2025-10-01T11:42:47.185Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing/synthetic: Fix races on freeing last_cmd Currently, the "last_cmd" variable can be accessed by multiple processes asynchronously when multiple users manipulate synthetic_events node at the same time, it could lead to use-after-free or double-free. This patch add "lastcmd_mutex" to prevent "last_cmd" from being accessed asynchronously. ================================================================ It's easy to reproduce in the KASAN environment by running the
======================================================== It's easy to reproduce in the KASAN environment by running the two scripts below in different shells. script 1: while : do echo -n -e '\x88' > /sys/kernel/tracing/synthetic_events done script 2: while : do echo -n -e '\xb0' > /sys/kernel/tracing/synthetic_events done ================================================================ double-free scenario: process A process B ------------------- --------------- 1.kstrdup last_cmd 2.free last_cmd 3.free last_cmd(double-free) ================================================================ use-after-free scenario: process A process B ------------------- --------------- 1.kstrdup last_cmd 2.f
================ use-after-free scenario: process A process B ------------------- --------------- 1.kstrdup last_cmd 2.free last_cmd 3.tracing_log_err(use-after-free) ================================================================ Appendix 1. KASAN report double-free: BUG: KASAN: double-free in kfree+0xdc/0x1d4 Free of addr ***** by task sh/4879 Call trace: ... kfree+0xdc/0x1d4 create_or_delete_synth_event+0x60/0x1e8 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Allocated by task 4879: ... kstrdup+0x5c/0x98 create_or_delete_synth_event+0x6c/0x1e8 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Freed by t
h_event+0x6c/0x1e8 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Freed by task 5464: ... kfree+0xdc/0x1d4 create_or_delete_synth_event+0x60/0x1e8 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... ================================================================ Appendix 2. KASAN report use-after-free: BUG: KASAN: use-after-free in strlen+0x5c/0x7c Read of size 1 at addr ***** by task sh/5483 sh: CPU: 7 PID: 5483 Comm: sh ... __asan_report_load1_noabort+0x34/0x44 strlen+0x5c/0x7c tracing_log_err+0x60/0x444 create_or_delete_synth_event+0xc4/0x204 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30
_err+0x60/0x444 create_or_delete_synth_event+0xc4/0x204 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Allocated by task 5483: ... kstrdup+0x5c/0x98 create_or_delete_synth_event+0x80/0x204 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... Freed by task 5480: ... kfree+0xdc/0x1d4 create_or_delete_synth_event+0x74/0x204 trace_parse_run_command+0x2bc/0x4b8 synth_events_write+0x20/0x30 vfs_write+0x200/0x830 ... References: - https://git.kernel.org/stable/c/9fe183f659a2704255e5d84f6ae308c234a113ec - https://git.kernel.org/stable/c/8826d9e7bd51e7656f78baa4472e8e2f5e7069f0 - https://git.kernel.org/stable/c/4ccf11c4
ec - https://git.kernel.org/stable/c/8826d9e7bd51e7656f78baa4472e8e2f5e7069f0 - https://git.kernel.org/stable/c/4ccf11c4e8a8e051499d53a12f502196c97a758e
CVE ID: CVE-2023-53479 State: PUBLISHED Published: 2025-10-01T11:42:47.987Z Last Updated: 2025-10-01T11:42:47.987Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cxl/acpi: Fix a use-after-free in cxl_parse_cfmws() KASAN and KFENCE detected an user-after-free in the CXL driver. This happens in the cxl_decoder_add() fail path. KASAN prints the following error: BUG: KASAN: slab-use-after-free in cxl_parse_cfmws (drivers/cxl/acpi.c:299) This happens in cxl_parse_cfmws(), where put_device() is called, releasing cxld, which is accessed later. Use the local variables in the dev_err() instead of pointing to the released memory. Since t
d, which is accessed later. Use the local variables in the dev_err() instead of pointing to the released memory. Since the dev_err() is printing a resource, change the open coded print format to use the %pr format specifier. References: - https://git.kernel.org/stable/c/748fadc08bcbdaf573b34d9784bb3dbd87441dbf - https://git.kernel.org/stable/c/316db489647b8ddc381682597e89787eac61a278 - https://git.kernel.org/stable/c/4cf67d3cc9994a59cf77bb9c0ccf9007fe916afe
CVE ID: CVE-2023-53480 State: PUBLISHED Published: 2025-10-01T11:42:48.919Z Last Updated: 2025-10-01T11:42:48.919Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: kobject: Add sanity check for kset->kobj.ktype in kset_register() When I register a kset in the following way: static struct kset my_kset; kobject_set_name(&my_kset.kobj, "my_kset"); ret = kset_register(&my_kset); A null pointer dereference exception is occurred: [ 4453.568337] Unable to handle kernel NULL pointer dereference at \ virtual address 0000000000000028 ... ... [ 4453.810361] Call trace: [ 4453.813062] kobject_get_ownership+0xc/0x34 [ 4453.817493] kobject_add
000000000028 ... ... [ 4453.810361] Call trace: [ 4453.813062] kobject_get_ownership+0xc/0x34 [ 4453.817493] kobject_add_internal+0x98/0x274 [ 4453.822005] kset_register+0x5c/0xb4 [ 4453.825820] my_kobj_init+0x44/0x1000 [my_kset] ... ... Because I didn't initialize my_kset.kobj.ktype. According to the description in Documentation/core-api/kobject.rst: - A ktype is the type of object that embeds a kobject. Every structure that embeds a kobject needs a corresponding ktype. So add sanity check to make sure kset->kobj.ktype is not NULL. References: - https://git.kernel.org/stable/c/1792eac72e27f676bf9ebde28a5afea627fb85f0 - https://git.kernel.org/stable/c/039ec9db2d30032eafa365f5f89b30eca5322b05
le/c/1792eac72e27f676bf9ebde28a5afea627fb85f0 - https://git.kernel.org/stable/c/039ec9db2d30032eafa365f5f89b30eca5322b05 - https://git.kernel.org/stable/c/964e025ceefdf75da46b0133d0c2790de451aeec - https://git.kernel.org/stable/c/5df5829158513134ddcaf2184d9286eda7b0bb18 - https://git.kernel.org/stable/c/f3f6bf22a4f5ba649cf26ae4670de5c7f861bdef - https://git.kernel.org/stable/c/48aebbe801e78a8932404c122ed0e880ccedc220 - https://git.kernel.org/stable/c/1a772881bc059c596d8ca587cbd2a233edce3d3b - https://git.kernel.org/stable/c/4d0fe8c52bb3029d83e323c961221156ab98680b
CVE ID: CVE-2023-53481 State: PUBLISHED Published: 2025-10-01T11:42:49.825Z Last Updated: 2025-10-01T11:42:49.825Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ubi: ubi_wl_put_peb: Fix infinite loop when wear-leveling work failed Following process will trigger an infinite loop in ubi_wl_put_peb(): ubifs_bgt ubi_bgt ubifs_leb_unmap ubi_leb_unmap ubi_eba_unmap_leb ubi_wl_put_peb wear_leveling_worker e1 = rb_entry(rb_first(&ubi->used) e2 = get_peb_for_wl(ubi) ubi_io_read_vid_hdr // return err (flash fault) out_error: ubi->move_from = ubi->move_to = NULL wl_entry_destroy(ubi, e1) ubi->lookuptbl[e->pnum] = NULL retry: e = ubi->loo
error: ubi->move_from = ubi->move_to = NULL wl_entry_destroy(ubi, e1) ubi->lookuptbl[e->pnum] = NULL retry: e = ubi->lookuptbl[pnum]; // return NULL if (e == ubi->move_from) { // NULL == NULL gets true goto retry; // infinite loop !!! $ top PID USER PR NI VIRT RES SHR S %CPU %MEM COMMAND 7676 root 20 0 0 0 0 R 100.0 0.0 ubifs_bgt0_0 Fix it by: 1) Letting ubi_wl_put_peb() returns directly if wearl leveling entry has been removed from 'ubi->lookuptbl'. 2) Using 'ubi->wl_lock' protecting wl entry deletion to preventing an use-after-free problem for wl entry in ubi_wl_put_peb(). Fetch a reproducer in [Link]. References: - https://git.kernel.org/stable/c/b40d2fbf47af58377e898b5062077a47bb28a132 -
. Fetch a reproducer in [Link]. References: - https://git.kernel.org/stable/c/b40d2fbf47af58377e898b5062077a47bb28a132 - https://git.kernel.org/stable/c/f006f596fe851c3b6aae60b79f89f89f0e515d2f - https://git.kernel.org/stable/c/b5be23f6ae610bdb262160a1f294afee6d0e6a69 - https://git.kernel.org/stable/c/8a18856e074479bd050b01e688c58defadce7ab0 - https://git.kernel.org/stable/c/3afaaf6f5867dc4ad383808d4053f428ec7b867d - https://git.kernel.org/stable/c/cc4bc532acda66189bddc03b3fe1ad689d9a48a2 - https://git.kernel.org/stable/c/5af1c643184a5d09ff5b3f334077a4d0a163c677 - https://git.kernel.org/stable/c/4d57a7333e26040f2b583983e1970d9d460e56b0
CVE ID: CVE-2023-53482 State: PUBLISHED Published: 2025-10-01T11:42:50.800Z Last Updated: 2025-10-01T11:42:50.800Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu: Fix error unwind in iommu_group_alloc() If either iommu_group_grate_file() fails then the iommu_group is leaked. Destroy it on these error paths. Found by kselftest/iommu/iommufd_fail_nth References: - https://git.kernel.org/stable/c/f119ef452e2d82d912797273cb790a86f1125b3e - https://git.kernel.org/stable/c/4c23124b45ee0aa895ed8d5d08871ae6b15ee336 - https://git.kernel.org/stable/c/8602fa38a63fc689eca29c8c586fac2d8a1f8739 - https://git.kernel.org/stable/c/4daa861
336 - https://git.kernel.org/stable/c/8602fa38a63fc689eca29c8c586fac2d8a1f8739 - https://git.kernel.org/stable/c/4daa861174d56023c2068ddb03de0752f07fa199
CVE ID: CVE-2023-53483 State: PUBLISHED Published: 2025-10-01T11:42:51.778Z Last Updated: 2025-10-01T11:42:51.778Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ACPI: processor: Check for null return of devm_kzalloc() in fch_misc_setup() devm_kzalloc() may fail, clk_data->name might be NULL and will cause a NULL pointer dereference later. [ rjw: Subject and changelog edits ] References: - https://git.kernel.org/stable/c/79ca94bc3e8cc3befa883c7d30b30a27ef0ea386 - https://git.kernel.org/stable/c/8a632ff6a2bea49993002b4c46092a2aea625840 - https://git.kernel.org/stable/c/4dea41775d951ff1f7b472a346a8ca3ae7e74455
CVE ID: CVE-2023-53484 State: PUBLISHED Published: 2025-10-01T11:42:52.590Z Last Updated: 2025-10-01T11:42:52.590Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: lib: cpu_rmap: Avoid use after free on rmap->obj array entries When calling irq_set_affinity_notifier() with NULL at the notify argument, it will cause freeing of the glue pointer in the corresponding array entry but will leave the pointer in the array. A subsequent call to free_irq_cpu_rmap() will try to free this entry again leading to possible use after free. Fix that by setting NULL to the array entry and checking that we have non-zero at the array entry when itera
after free. Fix that by setting NULL to the array entry and checking that we have non-zero at the array entry when iterating over the array in free_irq_cpu_rmap(). The current code does not suffer from this since there are no cases where irq_set_affinity_notifier(irq, NULL) (note the NULL passed for the notify arg) is called, followed by a call to free_irq_cpu_rmap() so we don't hit and issue. Subsequent patches in this series excersize this flow, hence the required fix. References: - https://git.kernel.org/stable/c/981f339d2905b6a92ef59358158b326493aecac5 - https://git.kernel.org/stable/c/d1308bd0b24cb1d78fa2747d5fa3e055cc628a48 - https://git.kernel.org/stable/c/cc2d2b3dbfb0ba57bc027fb7e112