Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
lt directly. References: - https://git.kernel.org/stable/c/7257070be70e19a9138f39009c1a26c83a8a7cfa - https://git.kernel.org/stable/c/bec1bea2fa974e63f6059c33edde669c7894d0bc - https://git.kernel.org/stable/c/a16394b5d661afec9a264fecac3abd87aea439ea - https://git.kernel.org/stable/c/e12b95680821b9880cd9992c0f3555389363604f - https://git.kernel.org/stable/c/031f196d1b1b6d5dfcb0533b431e3ab1750e6189
CVE ID: CVE-2023-53078 State: PUBLISHED Published: 2025-05-02T15:55:28.246Z Last Updated: 2025-05-04T12:50:18.916Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate() If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not freed, which will cause following memleak: unreferenced object 0xffff88810b2c6980 (size 32): comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$............. backtrace: [<00000
0 00 00 00 00 00 00 ................ 40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$............. backtrace: [<0000000098f3a26d>] alua_activate+0xb0/0x320 [<000000003b529641>] scsi_dh_activate+0xb2/0x140 [<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath] [<000000007adc9ace>] process_one_work+0x3c5/0x730 [<00000000c457a985>] worker_thread+0x93/0x650 [<00000000cb80e628>] kthread+0x1ba/0x210 [<00000000a1e61077>] ret_from_fork+0x22/0x30 Fix the problem by freeing 'qdata' in error path. References: - https://git.kernel.org/stable/c/123483df146492ca22b503ae6dacc2ce7c3a3974 - https://git.kernel.org/stable/c/c110051d335ef7f62ad33474b0c23997fee5bfb5 - https://git.kernel.org/stable/c
2ce7c3a3974 - https://git.kernel.org/stable/c/c110051d335ef7f62ad33474b0c23997fee5bfb5 - https://git.kernel.org/stable/c/5c4d71424df34fc23dc5336d09394ce68c849542 - https://git.kernel.org/stable/c/c09cdf6eb815ee35e55d6c50ac7f63db58bd20b8 - https://git.kernel.org/stable/c/9311e7a554dffd3823499e309a8b86a5cd1540e5 - https://git.kernel.org/stable/c/1c55982beb80c7d3c30278fc6cfda8496a31dbe6 - https://git.kernel.org/stable/c/0d89254a4320eb7de0970c478172f764125c6355 - https://git.kernel.org/stable/c/a13faca032acbf2699293587085293bdfaafc8ae
CVE ID: CVE-2023-53079 State: PUBLISHED Published: 2025-05-02T15:55:28.968Z Last Updated: 2025-05-04T07:49:19.664Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix steering rules cleanup vport's mc, uc and multicast rules are not deleted in teardown path when EEH happens. Since the vport's promisc settings(uc, mc and all) in firmware are reset after EEH, mlx5 driver will try to delete the above rules in the initialization path. This cause kernel crash because these software rules are no longer valid. Fix by nullifying these rules right after delete to avoid accessing any dangling pointers. Call Trace: __list_del_ent
d. Fix by nullifying these rules right after delete to avoid accessing any dangling pointers. Call Trace: __list_del_entry_valid+0xcc/0x100 (unreliable) tree_put_node+0xf4/0x1b0 [mlx5_core] tree_remove_node+0x30/0x70 [mlx5_core] mlx5_del_flow_rules+0x14c/0x1f0 [mlx5_core] esw_apply_vport_rx_mode+0x10c/0x200 [mlx5_core] esw_update_vport_rx_mode+0xb4/0x180 [mlx5_core] esw_vport_change_handle_locked+0x1ec/0x230 [mlx5_core] esw_enable_vport+0x130/0x260 [mlx5_core] mlx5_eswitch_enable_sriov+0x2a0/0x2f0 [mlx5_core] mlx5_device_enable_sriov+0x74/0x440 [mlx5_core] mlx5_load_one+0x114c/0x1550 [mlx5_core] mlx5_pci_resume+0x68/0xf0 [mlx5_core] eeh_report_resume+0x1a4/0x230 eeh_pe_dev_traverse+0x98/0x17
14c/0x1550 [mlx5_core] mlx5_pci_resume+0x68/0xf0 [mlx5_core] eeh_report_resume+0x1a4/0x230 eeh_pe_dev_traverse+0x98/0x170 eeh_handle_normal_event+0x3e4/0x640 eeh_handle_event+0x4c/0x370 eeh_event_handler+0x14c/0x210 kthread+0x168/0x1b0 ret_from_kernel_thread+0x5c/0x84 References: - https://git.kernel.org/stable/c/18cead61e437f4c7898acca0a5f3df12f801d97f - https://git.kernel.org/stable/c/4df1f2d36bdc9a368650bf14b9097c555e95f71d - https://git.kernel.org/stable/c/63546395a0e6ac264f78f65218086ce6014b4494 - https://git.kernel.org/stable/c/6f5780536181d1d0d09a11a1bc92f22e143447e2 - https://git.kernel.org/stable/c/922f56e9a795d6f3dd72d3428ebdd7ee040fa855
CVE ID: CVE-2023-53080 State: PUBLISHED Published: 2025-05-02T15:55:29.825Z Last Updated: 2025-05-04T07:49:20.748Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: xsk: Add missing overflow check in xdp_umem_reg The number of chunks can overflow u32. Make sure to return -EINVAL on overflow. Also remove a redundant u32 cast assigning umem->npgs. References: - https://git.kernel.org/stable/c/580634b03a55f04a3c1968bcbd97736c079c6601 - https://git.kernel.org/stable/c/3cfc3564411acf96bf2fb791f706a1aa4f872c1d - https://git.kernel.org/stable/c/a069909acc4435eeb41d05ccc03baa447cc01b7e - https://git.kernel.org/stable/c/bb2e3bfb2a79db0c205
//git.kernel.org/stable/c/a069909acc4435eeb41d05ccc03baa447cc01b7e - https://git.kernel.org/stable/c/bb2e3bfb2a79db0c2057c6f701b782954394c67f - https://git.kernel.org/stable/c/c7df4813b149362248d6ef7be41a311e27bf75fe
CVE ID: CVE-2023-53081 State: PUBLISHED Published: 2025-05-02T15:55:30.453Z Last Updated: 2025-05-04T12:50:20.030Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix data corruption after failed write When buffered write fails to copy data into underlying page cache page, ocfs2_write_end_nolock() just zeroes out and dirties the page. This can leave dirty page beyond EOF and if page writeback tries to write this page before write succeeds and expands i_size, page gets into inconsistent state where page dirty bit is clear but buffer dirty bits stay set resulting in page data never getting written and so data copied to the
irty bit is clear but buffer dirty bits stay set resulting in page data never getting written and so data copied to the page is lost. Fix the problem by invalidating page beyond EOF after failed write. References: - https://git.kernel.org/stable/c/1629f6f522b2d058019710466a84b240683bbee3 - https://git.kernel.org/stable/c/c26f3ff4c0be590c1250f945ac2e4fc5fcdc5f45 - https://git.kernel.org/stable/c/4c24eb49ab44351424ac8fe8567f91ea48a06089 - https://git.kernel.org/stable/c/91d7a4bd5656552d6259e2d0f8859f9e8cc5ef68 - https://git.kernel.org/stable/c/a9e53869cb43c96d6d851c491fd4e26430ab6ba6 - https://git.kernel.org/stable/c/47eb055ad3588fc96d34e9e1dd87b210ce62906b - https://git.kernel.org/stable/c/20
30ab6ba6 - https://git.kernel.org/stable/c/47eb055ad3588fc96d34e9e1dd87b210ce62906b - https://git.kernel.org/stable/c/205759c6c18f54659b0b5976b14a52d1b3eb9f57 - https://git.kernel.org/stable/c/90410bcf873cf05f54a32183afff0161f44f9715
CVE ID: CVE-2023-53082 State: PUBLISHED Published: 2025-05-02T15:55:31.071Z Last Updated: 2025-05-04T07:49:23.320Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix the crash in hot unplug with vp_vdpa While unplugging the vp_vdpa device, it triggers a kernel panic The root cause is: vdpa_mgmtdev_unregister() will accesses modern devices which will cause a use after free. So need to change the sequence in vp_vdpa_remove [ 195.003359] BUG: unable to handle page fault for address: ff4e8beb80199014 [ 195.004012] #PF: supervisor read access in kernel mode [ 195.004486] #PF: error_code(0x0000) - not-present page [ 195.0049
5.004012] #PF: supervisor read access in kernel mode [ 195.004486] #PF: error_code(0x0000) - not-present page [ 195.004960] PGD 100000067 P4D 1001b6067 PUD 1001b7067 PMD 1001b8067 PTE 0 [ 195.005578] Oops: 0000 1 PREEMPT SMP PTI [ 195.005968] CPU: 13 PID: 164 Comm: kworker/u56:10 Kdump: loaded Not tainted 5.14.0-252.el9.x86_64 #1 [ 195.006792] Hardware name: Red Hat KVM/RHEL, BIOS edk2-20221207gitfff6d81270b5-2.el9 unknown [ 195.007556] Workqueue: kacpi_hotplug acpi_hotplug_work_fn [ 195.008059] RIP: 0010:ioread8+0x31/0x80 [ 195.008418] Code: 77 28 48 81 ff 00 00 01 00 76 0b 89 fa ec 0f b6 c0 c3 cc cc cc cc 8b 15 ad 72 93 01 b8 ff 00 00 00 85 d2 75 0f c3 cc cc cc cc <8a> 07 0f b6 c0 c3 cc cc
b 89 fa ec 0f b6 c0 c3 cc cc cc cc 8b 15 ad 72 93 01 b8 ff 00 00 00 85 d2 75 0f c3 cc cc cc cc <8a> 07 0f b6 c0 c3 cc cc cc cc 83 ea 01 48 83 ec 08 48 89 fe 48 c7 [ 195.010104] RSP: 0018:ff4e8beb8067bab8 EFLAGS: 00010292 [ 195.010584] RAX: ffffffffc05834a0 RBX: ffffffffc05843c0 RCX: ff4e8beb8067bae0 [ 195.011233] RDX: ff1bcbd580f88000 RSI: 0000000000000246 RDI: ff4e8beb80199014 [ 195.011881] RBP: ff1bcbd587e39000 R08: ffffffff916fa2d0 R09: ff4e8beb8067ba68 [ 195.012527] R10: 000000000000001c R11: 0000000000000000 R12: ff1bcbd5a3de9120 [ 195.013179] R13: ffffffffc062d000 R14: 0000000000000080 R15: ff1bcbe402bc7805 [ 195.013826] FS: 0000000000000000(0000) GS:ff1bcbe402740000(0000) knlGS:000000
: 0000000000000080 R15: ff1bcbe402bc7805 [ 195.013826] FS: 0000000000000000(0000) GS:ff1bcbe402740000(0000) knlGS:0000000000000000 [ 195.014564] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 195.015093] CR2: ff4e8beb80199014 CR3: 0000000107dea002 CR4: 0000000000771ee0 [ 195.015741] PKRU: 55555554 [ 195.016001] Call Trace: [ 195.016233] <TASK> [ 195.016434] vp_modern_get_status+0x12/0x20 [ 195.016823] vp_vdpa_reset+0x1b/0x50 [vp_vdpa] [ 195.017238] virtio_vdpa_reset+0x3c/0x48 [virtio_vdpa] [ 195.017709] remove_vq_common+0x1f/0x3a0 [virtio_net] [ 195.018178] virtnet_remove+0x5d/0x70 [virtio_net] [ 195.018618] virtio_dev_remove+0x3d/0x90 [ 195.018986] device_release_driver_internal+0x1aa/0
ve+0x5d/0x70 [virtio_net] [ 195.018618] virtio_dev_remove+0x3d/0x90 [ 195.018986] device_release_driver_internal+0x1aa/0x230 [ 195.019466] bus_remove_device+0xd8/0x150 [ 195.019841] device_del+0x18b/0x3f0 [ 195.020167] ? kernfs_find_ns+0x35/0xd0 [ 195.020526] device_unregister+0x13/0x60 [ 195.020894] unregister_virtio_device+0x11/0x20 [ 195.021311] device_release_driver_internal+0x1aa/0x230 [ 195.021790] bus_remove_device+0xd8/0x150 [ 195.022162] device_del+0x18b/0x3f0 [ 195.022487] device_unregister+0x13/0x60 [ 195.022852] ? vdpa_dev_remove+0x30/0x30 [vdpa] [ 195.023270] vp_vdpa_dev_del+0x12/0x20 [vp_vdpa] [ 195.023694] vdpa_match_remove+0x2b/0x40 [vdpa] [ 195.024115] bus_for_each_dev+0x78/
p_vdpa_dev_del+0x12/0x20 [vp_vdpa] [ 195.023694] vdpa_match_remove+0x2b/0x40 [vdpa] [ 195.024115] bus_for_each_dev+0x78/0xc0 [ 195.024471] vdpa_mgmtdev_unregister+0x65/0x80 [vdpa] [ 195.024937] vp_vdpa_remove+0x23/0x40 [vp_vdpa] [ 195.025353] pci_device_remove+0x36/0xa0 [ 195.025719] device_release_driver_internal+0x1aa/0x230 [ 195.026201] pci_stop_bus_device+0x6c/0x90 [ 195.026580] pci_stop_and_remove_bus_device+0xe/0x20 [ 195.027039] disable_slot+0x49/0x90 [ 195.027366] acpiphp_disable_and_eject_slot+0x15/0x90 [ 195.027832] hotplug_event+0xea/0x210 [ 195.028171] ? hotplug_event+0x210/0x210 [ 195.028535] acpiphp_hotplug_notify+0x22/0x80 [ 195.028942] ? hotplug_event+0x210/0x210 [ 195.029303
_event+0x210/0x210 [ 195.028535] acpiphp_hotplug_notify+0x22/0x80 [ 195.028942] ? hotplug_event+0x210/0x210 [ 195.029303] acpi_device_hotplug+0x8a/0x1d0 [ 195.029690] acpi_hotplug_work_fn+0x1a/0x30 [ 195.030077] process_one_work+0x1e8/0x3c0 [ 195.030451] worker_thread+0x50/0x3b0 [ 195.030791] ? rescuer_thread+0x3a0/0x3a0 [ 195.031165] kthread+0xd9/0x100 [ 195.031459] ? kthread_complete_and_exit+0x20/0x20 [ 195.031899] ret_from_fork+0x22/0x30 [ 195.032233] </TASK> References: - https://git.kernel.org/stable/c/baafa2960731211837d8fc04ff3873ecb7440464 - https://git.kernel.org/stable/c/fa1f327f93c9a7310cce9d2fcda28b7af91f7437 - https://git.kernel.org/stable/c/aed8efddd39b3434c96718d39009285c52b1
stable/c/fa1f327f93c9a7310cce9d2fcda28b7af91f7437 - https://git.kernel.org/stable/c/aed8efddd39b3434c96718d39009285c52b1cafc
CVE ID: CVE-2023-53083 State: PUBLISHED Published: 2025-05-02T15:55:31.699Z Last Updated: 2025-05-04T07:49:24.528Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nfsd: don't replace page in rq_pages if it's a continuation of last page The splice read calls nfsd_splice_actor to put the pages containing file data into the svc_rqst->rq_pages array. It's possible however to get a splice result that only has a partial page at the end, if (e.g.) the filesystem hands back a short read that doesn't cover the whole page. nfsd_splice_actor will plop the partial page into its rq_pages array and return. Then later, when nfsd_splice_actor i
e. nfsd_splice_actor will plop the partial page into its rq_pages array and return. Then later, when nfsd_splice_actor is called again, the remainder of the page may end up being filled out. At this point, nfsd_splice_actor will put the page into the array _again_ corrupting the reply. If this is done enough times, rq_next_page will overrun the array and corrupt the trailing fields -- the rq_respages and rq_next_page pointers themselves. If we've already added the page to the array in the last pass, don't add it to the array a second time when dealing with a splice continuation. This was originally handled properly in nfsd_splice_actor, but commit 91e23b1c3982 ("NFSD: Clean up nfsd_splice_ac
tion. This was originally handled properly in nfsd_splice_actor, but commit 91e23b1c3982 ("NFSD: Clean up nfsd_splice_actor()") removed the check for it. References: - https://git.kernel.org/stable/c/8235cd619db6e67f1d7d26c55f1f3e4e575c947d - https://git.kernel.org/stable/c/12eca509234acb6b666802edf77408bb70d7bfca - https://git.kernel.org/stable/c/51ddb84baff6f09ad62b5999ece3ec172e4e3568 - https://git.kernel.org/stable/c/0101067f376eb7b9afd00279270f25d5111a091d - https://git.kernel.org/stable/c/27c934dd8832dd40fd34776f916dc201e18b319b
CVE ID: CVE-2023-53084 State: PUBLISHED Published: 2025-05-02T15:55:32.319Z Last Updated: 2025-05-04T12:50:21.210Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/shmem-helper: Remove another errant put in error path drm_gem_shmem_mmap() doesn't own reference in error code path, resulting in the dma-buf shmem GEM object getting prematurely freed leading to a later use-after-free. References: - https://git.kernel.org/stable/c/684c7372bbd6447c2e86a2a84e97a1478604d21f - https://git.kernel.org/stable/c/5cfb617967b05f8f27e862c97db1fabd8485f4db - https://git.kernel.org/stable/c/dede8c14a37a7ac458f9add56154a074ed78e7cf - https://gi
67b05f8f27e862c97db1fabd8485f4db - https://git.kernel.org/stable/c/dede8c14a37a7ac458f9add56154a074ed78e7cf - https://git.kernel.org/stable/c/77d26c824aa5a7e0681ef1d5b75fe538d746addc - https://git.kernel.org/stable/c/ee9adb7a45516cfa536ca92253d7ae59d56db9e4
CVE ID: CVE-2023-53085 State: PUBLISHED Published: 2025-05-02T15:55:32.939Z Last Updated: 2025-05-04T07:49:26.749Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/edid: fix info leak when failing to get panel id Make sure to clear the transfer buffer before fetching the EDID to avoid leaking slab data to the logs on errors that leave the buffer unchanged. References: - https://git.kernel.org/stable/c/598c42c78919117dc0d235ae22d17ad642377483 - https://git.kernel.org/stable/c/4d8457fe0eb9c80ff7795cf8a30962128b71d853
CVE ID: CVE-2023-53086 State: PUBLISHED Published: 2025-05-02T15:55:33.578Z Last Updated: 2025-05-04T07:49:28.077Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: connac: do not check WED status for non-mmio devices WED is supported just for mmio devices, so do not check it for usb or sdio devices. This patch fixes the crash reported below: [ 21.946627] wlp0s3u1i3: authenticate with c4:41:1e:f5:2b:1d [ 22.525298] wlp0s3u1i3: send auth to c4:41:1e:f5:2b:1d (try 1/3) [ 22.548274] wlp0s3u1i3: authenticate with c4:41:1e:f5:2b:1d [ 22.557694] wlp0s3u1i3: send auth to c4:41:1e:f5:2b:1d (try 1/3) [ 22.565885] wlp0s3u1i3: au
ate with c4:41:1e:f5:2b:1d [ 22.557694] wlp0s3u1i3: send auth to c4:41:1e:f5:2b:1d (try 1/3) [ 22.565885] wlp0s3u1i3: authenticated [ 22.569502] wlp0s3u1i3: associate with c4:41:1e:f5:2b:1d (try 1/3) [ 22.578966] wlp0s3u1i3: RX AssocResp from c4:41:1e:f5:2b:1d (capab=0x11 status=30 aid=3) [ 22.579113] wlp0s3u1i3: c4:41:1e:f5:2b:1d rejected association temporarily; comeback duration 1000 TU (1024 ms) [ 23.649518] wlp0s3u1i3: associate with c4:41:1e:f5:2b:1d (try 2/3) [ 23.752528] wlp0s3u1i3: RX AssocResp from c4:41:1e:f5:2b:1d (capab=0x11 status=0 aid=3) [ 23.797450] wlp0s3u1i3: associated [ 24.959527] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) [ 24.959640] BUG: una
1i3: associated [ 24.959527] kernel tried to execute NX-protected page - exploit attempt? (uid: 0) [ 24.959640] BUG: unable to handle page fault for address: ffff88800c223200 [ 24.959706] #PF: supervisor instruction fetch in kernel mode [ 24.959788] #PF: error_code(0x0011) - permissions violation [ 24.959846] PGD 2c01067 P4D 2c01067 PUD 2c02067 PMD c2a8063 PTE 800000000c223163 [ 24.959957] Oops: 0011 [#1] PREEMPT SMP [ 24.960009] CPU: 0 PID: 391 Comm: wpa_supplicant Not tainted 6.2.0-kvm #18 [ 24.960089] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014 [ 24.960191] RIP: 0010:0xffff88800c223200 [ 24.960446] RSP: 0018:ffffc90000ff7698 EFLAGS: 00010282 [ 24.9605
04/01/2014 [ 24.960191] RIP: 0010:0xffff88800c223200 [ 24.960446] RSP: 0018:ffffc90000ff7698 EFLAGS: 00010282 [ 24.960513] RAX: ffff888028397010 RBX: ffff88800c26e630 RCX: 0000000000000058 [ 24.960598] RDX: ffff88800c26f844 RSI: 0000000000000006 RDI: ffff888028397010 [ 24.960682] RBP: ffff88800ea72f00 R08: 18b873fbab2b964c R09: be06b38235f3c63c [ 24.960766] R10: 18b873fbab2b964c R11: be06b38235f3c63c R12: 0000000000000001 [ 24.960853] R13: ffff88800c26f84c R14: ffff8880063f0ff8 R15: ffff88800c26e644 [ 24.960950] FS: 00007effcea327c0(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 [ 24.961036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 24.961106] CR2: ffff88800c223200 CR3: 000
00000000000000 [ 24.961036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 24.961106] CR2: ffff88800c223200 CR3: 000000000eaa2000 CR4: 00000000000006b0 [ 24.961190] Call Trace: [ 24.961219] <TASK> [ 24.961245] ? mt76_connac_mcu_add_key+0x2cf/0x310 [ 24.961313] ? mt7921_set_key+0x150/0x200 [ 24.961365] ? drv_set_key+0xa9/0x1b0 [ 24.961418] ? ieee80211_key_enable_hw_accel+0xd9/0x240 [ 24.961485] ? ieee80211_key_replace+0x3f3/0x730 [ 24.961541] ? crypto_shash_setkey+0x89/0xd0 [ 24.961597] ? ieee80211_key_link+0x2d7/0x3a0 [ 24.961664] ? crypto_aead_setauthsize+0x31/0x50 [ 24.961730] ? sta_info_hash_lookup+0xa6/0xf0 [ 24.961785] ? ieee80211_add_key+0x1fc/0x250 [ 24.961842] ? rdev_add_key+0x41
4.961730] ? sta_info_hash_lookup+0xa6/0xf0 [ 24.961785] ? ieee80211_add_key+0x1fc/0x250 [ 24.961842] ? rdev_add_key+0x41/0x140 [ 24.961882] ? nl80211_parse_key+0x6c/0x2f0 [ 24.961940] ? nl80211_new_key+0x24a/0x290 [ 24.961984] ? genl_rcv_msg+0x36c/0x3a0 [ 24.962036] ? rdev_mod_link_station+0xe0/0xe0 [ 24.962102] ? nl80211_set_key+0x410/0x410 [ 24.962143] ? nl80211_pre_doit+0x200/0x200 [ 24.962187] ? genl_bind+0xc0/0xc0 [ 24.962217] ? netlink_rcv_skb+0xaa/0xd0 [ 24.962259] ? genl_rcv+0x24/0x40 [ 24.962300] ? netlink_unicast+0x224/0x2f0 [ 24.962345] ? netlink_sendmsg+0x30b/0x3d0 [ 24.962388] ? ____sys_sendmsg+0x109/0x1b0 [ 24.962388] ? ____sys_sendmsg+0x109/0x1b0 [ 24.962440] ? __import_iovec+
3d0 [ 24.962388] ? ____sys_sendmsg+0x109/0x1b0 [ 24.962388] ? ____sys_sendmsg+0x109/0x1b0 [ 24.962440] ? __import_iovec+0x2e/0x110 [ 24.962482] ? ___sys_sendmsg+0xbe/0xe0 [ 24.962525] ? mod_objcg_state+0x25c/0x330 [ 24.962576] ? __dentry_kill+0x19e/0x1d0 [ 24.962618] ? call_rcu+0x18f/0x270 [ 24.962660] ? __dentry_kill+0x19e/0x1d0 [ 24.962702] ? __x64_sys_sendmsg+0x70/0x90 [ 24.962744] ? do_syscall_64+0x3d/0x80 [ 24.962796] ? exit_to_user_mode_prepare+0x1b/0x70 [ 24.962852] ? entry_SYSCA ---truncated--- References: - https://git.kernel.org/stable/c/53edfda851dd1ce41ac049ce2f195dc41dd27cc1 - https://git.kernel.org/stable/c/5683e1488aa9b0805a9403d215e48fed29d6d923
CVE ID: CVE-2023-53087 State: PUBLISHED Published: 2025-05-02T15:55:34.204Z Last Updated: 2025-05-04T07:49:29.178Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/i915/active: Fix misuse of non-idle barriers as fence trackers Users reported oopses on list corruptions when using i915 perf with a number of concurrently running graphics applications. Root cause analysis pointed at an issue in barrier processing code -- a race among perf open / close replacing active barriers with perf requests on kernel context and concurrent barrier preallocate / acquire operations performed during user context first pin / last unpin. When add
t and concurrent barrier preallocate / acquire operations performed during user context first pin / last unpin. When adding a request to a composite tracker, we try to reuse an existing fence tracker, already allocated and registered with that composite. The tracker we obtain may already track another fence, may be an idle barrier, or an active barrier. If the tracker we get occurs a non-idle barrier then we try to delete that barrier from a list of barrier tasks it belongs to. However, while doing that we don't respect return value from a function that performs the barrier deletion. Should the deletion ever fail, we would end up reusing the tracker still registered as a barrier task. Since
deletion. Should the deletion ever fail, we would end up reusing the tracker still registered as a barrier task. Since the same structure field is reused with both fence callback lists and barrier tasks list, list corruptions would likely occur. Barriers are now deleted from a barrier tasks list by temporarily removing the list content, traversing that content with skip over the node to be deleted, then populating the list back with the modified content. Should that intentionally racy concurrent deletion attempts be not serialized, one or more of those may fail because of the list being temporary empty. Related code that ignores the results of barrier deletion was initially introduced in v5
the list being temporary empty. Related code that ignores the results of barrier deletion was initially introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel requests"). However, all users of the barrier deletion routine were apparently serialized at that time, then the issue didn't exhibit itself. Results of git bisect with help of a newly developed igt@gem_barrier_race@remote-request IGT test indicate that list corruptions might start to appear after commit 311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles"), introduced in v5.5. Respect results of barrier deletion attempts -- mark the barrier as idle only if success
ne idles"), introduced in v5.5. Respect results of barrier deletion attempts -- mark the barrier as idle only if successfully deleted from the list. Then, before proceeding with setting our fence as the one currently tracked, make sure that the tracker we've got is not a non-idle barrier. If that check fails then don't use that tracker but go back and try to acquire a new, usable one. v3: use unlikely() to document what outcome we expect (Andi), - fix bad grammar in commit description. v2: no code changes, - blame commit 311770173fac ("drm/i915/gt: Schedule request retirement when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow sharing the idle-barrier from other kernel req