Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
up_config+0x74d/0x7a0 [5.606741] ? btrfs_read_qgroup_config+0x74d/0x7a0 [5.607038] ? try_to_wake_up+0x317/0x760 [5.607286] open_ctree+0xd9c/0x1710 [5.607509] btrfs_get_tree+0x58a/0x7e0 [5.608002] vfs_get_tree+0x2e/0x100 [5.608224] fc_mount+0x16/0x60 [5.608420] btrfs_get_tree+0x2f8/0x7e0 [5.608897] vfs_get_tree+0x2e/0x100 [5.609121] path_mount+0x4c8/0xbc0 [5.609538] __x64_sys_mount+0x10d/0x150 The issue can be easily reproduced using the following reproducer: root@q:linux# cat repro.sh set -e mkfs.btrfs -q -f /dev/sdb mount /dev/sdb /mnt/btrfs btrfs quota enable -s /mnt/btrfs umount /mnt/btrfs mount /dev/sdb /mnt/btrfs The issue is that when enabling quotas, at btrfs_quota_enable(), we set BT
s umount /mnt/btrfs mount /dev/sdb /mnt/btrfs The issue is that when enabling quotas, at btrfs_quota_enable(), we set BTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE at fs_info->qgroup_flags and persist it in the quota root in the item with the key BTRFS_QGROUP_STATUS_KEY, but we only set the incompat bit BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA after we commit the transaction used to enable simple quotas. This means that if after that transaction commit we unmount the filesystem without starting and committing any other transaction, or we have a power failure, the next time we mount the filesystem we will find the flag BTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE set in the item with the key BTRFS_QGROUP_STATUS_KE
ilesystem we will find the flag BTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE set in the item with the key BTRFS_QGROUP_STATUS_KEY but we will not find the incompat bit BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA set in the superblock, triggering an assertion failure at: btrfs_read_qgroup_config() -> qgroup_read_enable_gen() To fix this issue, set the BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA flag immediately after setting the BTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE. This ensures that both flags are flushed to disk within the same transaction. References: - https://git.kernel.org/stable/c/b87c9b9ba05ba6e8e2ee9ecd29a8c930b35648ed - https://git.kernel.org/stable/c/f2363e6fcc7938c5f0f6ac066fad0dd247598b51
CVE ID: CVE-2024-57807 State: PUBLISHED Published: 2025-01-11T12:39:53.645Z Last Updated: 2025-11-03T20:54:38.496Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: megaraid_sas: Fix for a potential deadlock This fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ---- ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex); lock(&shost->scan_mutex); Fix this by temporarily releasing the reset_mutex. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/78afb9bfad00c4aa58a424111d7edbcab9452f2b - https:/
CVE Program Container: References: - https://git.kernel.org/stable/c/78afb9bfad00c4aa58a424111d7edbcab9452f2b - https://git.kernel.org/stable/c/f36d024bd15ed356a80dda3ddc46d0a62aa55815 - https://git.kernel.org/stable/c/3c654998a3e8167a58b6c6fede545fe400a4b554 - https://git.kernel.org/stable/c/edadc693bfcc0f1ea08b8fa041c9361fd042410d - https://git.kernel.org/stable/c/f50783148ec98a1d38b87422e2ceaf2380b7b606 - https://git.kernel.org/stable/c/466ca39dbf5d0ba71c16b15c27478a9c7d4022a8 - https://git.kernel.org/stable/c/50740f4dc78b41dec7c8e39772619d5ba841ddd7
CVE ID: CVE-2024-57809 State: PUBLISHED Published: 2025-01-11T14:08:56.044Z Last Updated: 2025-05-04T10:05:16.796Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PCI: imx6: Fix suspend/resume support on i.MX6QDL The suspend/resume functionality is currently broken on the i.MX6QDL platform, as documented in the NXP errata (ERR005723): https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf This patch addresses the issue by sharing most of the suspend/resume sequences used by other i.MX devices, while avoiding modifications to critical registers that disrupt the PCIe functionality. It targets the same problem as the following downstream
ions to critical registers that disrupt the PCIe functionality. It targets the same problem as the following downstream commit: https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995 Unlike the downstream commit, this patch also resets the connected PCIe device if possible. Without this reset, certain drivers, such as ath10k or iwlwifi, will crash on resume. The device reset is also done by the driver on other i.MX platforms, making this patch consistent with existing practices. Upon resuming, the kernel will hang and display an error. Here's an example of the error encountered with the ath10k driver: ath10k_pci 0000:01:00.0: Unable to change power state from D3
n example of the error encountered with the ath10k driver: ath10k_pci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible Unhandled fault: imprecise external abort (0x1406) at 0x0106f944 Without this patch, suspend/resume will fail on i.MX6QDL devices if a PCIe device is connected. [kwilczynski: commit log, added tag for stable releases] References: - https://git.kernel.org/stable/c/ac43ea3d27a8f9beadf3af66c9ea4a566ebfff1f - https://git.kernel.org/stable/c/0a726f542d7c8cc0f9c5ed7df5a4bd4b59ac21b3
CVE ID: CVE-2024-57811 State: PUBLISHED Published: 2025-01-13T00:00:00 Last Updated: 2025-01-16T17:27:35.380Z Vendors: n/a Products: n/a Problem Types: n/a Description: In Eaton X303 3.5.16 - X303 3.5.17 Build 712, an attacker with network access to a XC-303 PLC can login as root over SSH. The root password is hardcoded in the firmware. NOTE: This vulnerability appears in versions that are no longer supported by Eaton. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://github.com/google/security-research/security/advisories/GHSA-xf7j-4x67-6h93
CVE ID: CVE-2024-57822 State: PUBLISHED Published: 2025-01-10T00:00:00.000Z Last Updated: 2025-11-03T17:31:26.627Z Severity: MEDIUM (CVSS 4 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) Vendors: librdf Products: Raptor RDF Syntax Library Problem Types: CWE-125 Description: In Raptor RDF Syntax Library through 2.0.16, there is a heap-based buffer over-read when parsing triples with the nquads parser in raptor_ntriples_parse_term_internal(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://github.com/pedrib/PoC/blob/master/fuzzing/raptor-fuzz.md - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067896 - https://github.com/dajobe/raptor/issues
ing/raptor-fuzz.md - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067896 - https://github.com/dajobe/raptor/issues/70
CVE ID: CVE-2024-57823 State: PUBLISHED Published: 2025-01-10T00:00:00.000Z Last Updated: 2025-11-03T17:31:27.613Z Severity: CRITICAL (CVSS 9.3 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) Vendors: librdf Products: Raptor RDF Syntax Library Problem Types: CWE-191 Description: In Raptor RDF Syntax Library through 2.0.16, there is an integer underflow when normalizing a URI with the turtle parser in raptor_uri_normalize_path(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://github.com/pedrib/PoC/blob/master/fuzzing/raptor-fuzz.md - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067896 - https://github.com/dajobe/raptor/issues/70
CVE ID: CVE-2024-57834 State: PUBLISHED Published: 2025-02-27T02:18:09.085Z Last Updated: 2025-11-03T19:32:45.160Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_thread syzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1] If dvb->mux is not initialized successfully by vidtv_mux_init() in the vidtv_start_streaming(), it will trigger null pointer dereference about mux in vidtv_mux_stop_thread(). Adjust the timing of streaming initialization and check it before stopping it. [1] KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 UID: 0 PID: 5842
t before stopping it. [1] KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f] CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471 Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8 RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125 RDX: 00000
RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125 RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128 RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188 R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710 FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Cal
000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450
.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f Additional Analyst Notes: - CVE Program Container: References: - htt
ommon.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/52d3512f9a7a52ef92864679b1e8e8aa16202c6a - https://git.kernel.org/stable/c/59a707ad952eb2ea8d59457d662b6f4138f17b08 - https://git.kernel.org/stable/c/86307e443c5844f38e1b98e2c51a4195c55576cd - https://git.kernel.org/stable/c/2c5601b99d79d196fe4a37159e3dfb38e778ea18 - https://git.kernel.org/stable/c/95432a37778c9c5dd105b7b9f19e9695c9e166cf - https://git.kernel.org/stable/c/904a8323cc8afa7eb9ce3e67303a2b3f2f787306 - https://git.kernel.org/stable/c/1221989555db711578a327a9367f1be46500cb48
CVE ID: CVE-2024-57835 State: PUBLISHED Published: 2025-04-05T16:11:11.314Z Last Updated: 2025-04-07T18:27:55.093Z Vendors: TANIGUCHI Products: Amon2::Auth::Site::LINE Problem Types: CWE-338 Description: Amon2::Auth::Site::LINE uses the String::Random module to generate nonce values. String::Random defaults to Perl's built-in predictable random number generator, the rand() function, which is not cryptographically secure Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://metacpan.org/release/SHLOMIF/String-Random-0.32/source/lib/String/Random.pm#L377 - https://metacpan.org/release/TANIGUCHI/Amon2-Auth-Site-LINE-0.04/source/lib/Amon2/Auth/Site/LINE.pm#L235 - https://metac
https://metacpan.org/release/TANIGUCHI/Amon2-Auth-Site-LINE-0.04/source/lib/Amon2/Auth/Site/LINE.pm#L235 - https://metacpan.org/release/TANIGUCHI/Amon2-Auth-Site-LINE-0.04/source/lib/Amon2/Auth/Site/LINE.pm#L255 - https://security.metacpan.org/docs/guides/random-data-for-security.html
CVE ID: CVE-2024-57838 State: PUBLISHED Published: 2025-01-11T14:08:56.951Z Last Updated: 2025-11-03T20:54:39.985Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: s390/entry: Mark IRQ entries to fix stack depot warnings The stack depot filters out everything outside of the top interrupt context as an uninteresting or irrelevant part of the stack traces. This helps with stack trace de-duplication, avoiding an explosion of saved stack traces that share the same IRQ context code path but originate from different randomly interrupted points, eventually exhausting the stack depot. Filtering uses in_irqentry_text() to identify functio
andomly interrupted points, eventually exhausting the stack depot. Filtering uses in_irqentry_text() to identify functions within the .irqentry.text and .softirqentry.text sections, which then become the last stack trace entries being saved. While __do_softirq() is placed into the .softirqentry.text section by common code, populating .irqentry.text is architecture-specific. Currently, the .irqentry.text section on s390 is empty, which prevents stack depot filtering and de-duplication and could result in warnings like: Stack depot reached limit capacity WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8 with PREEMPT and KASAN enabled. Fix this by moving the IO/E
286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8 with PREEMPT and KASAN enabled. Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into the .irqentry.text section and updating the kprobes blacklist to include the .irqentry.text section. This is done only for asynchronous interrupts and explicitly not for program checks, which are synchronous and where the context beyond the program check is important to preserve. Despite machine checks being somewhat in between, they are extremely rare, and preserving context when possible is also of value. SVCs and Restart Interrupts are not relevant, one being always at the boundary to user space and the other being a one-time
s and Restart Interrupts are not relevant, one being always at the boundary to user space and the other being a one-time thing. IRQ entries filtering is also optionally used in ftrace function graph, where the same logic applies. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/ca687fdce5b95f84d91d6e36ac77047771eb3dfc - https://git.kernel.org/stable/c/5bb7a2c3afcf8732dc65ea49c09147b07da1d993 - https://git.kernel.org/stable/c/1af22528fee8072b7adc007b8ca49cc4ea62689e - https://git.kernel.org/stable/c/473ffae3030188f1c6b80e1b3631a26b4adf7b32 - https://git.kernel.org/stable/c/45c9f2b856a075a34873d00788d2e8a250c1effd
CVE ID: CVE-2024-57839 State: PUBLISHED Published: 2025-01-11T14:30:56.149Z Last Updated: 2025-05-04T10:05:21.323Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Revert "readahead: properly shorten readahead when falling back to do_page_cache_ra()" This reverts commit 7c877586da3178974a8a94577b6045a48377ff25. Anders and Philippe have reported that recent kernels occasionally hang when used with NFS in readahead code. The problem has been bisected to 7c877586da3 ("readahead: properly shorten readahead when falling back to do_page_cache_ra()"). The cause of the problem is that ra->size can be shrunk by read_pages() call and subse
ing back to do_page_cache_ra()"). The cause of the problem is that ra->size can be shrunk by read_pages() call and subsequently we end up calling do_page_cache_ra() with negative (read huge positive) number of pages. Let's revert 7c877586da3 for now until we can find a proper way how the logic in read_pages() and page_cache_ra_order() can coexist. This can lead to reduced readahead throughput due to readahead window confusion but that's better than outright hangs. References: - https://git.kernel.org/stable/c/85351e4941a253e4c50fb7048bfc19b60b4ec44b - https://git.kernel.org/stable/c/a220d6b95b1ae12c7626283d7609f0a1438e6437
CVE ID: CVE-2024-57841 State: PUBLISHED Published: 2025-01-15T13:10:26.842Z Last Updated: 2025-11-03T20:54:41.406Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: fix memory leak in tcp_conn_request() If inet_csk_reqsk_queue_hash_add() return false, tcp_conn_request() will return without free the dst memory, which allocated in af_ops->route_req. Here is the kmemleak stack: unreferenced object 0xffff8881198631c0 (size 240): comm "softirq", pid 0, jiffies 4299266571 (age 1802.392s) hex dump (first 32 bytes): 00 10 9b 03 81 88 ff ff 80 98 da bc ff ff ff ff ................ 81 55 18 bb ff ff ff ff 00 00 00 00 00 00 00 00 .U....
00 10 9b 03 81 88 ff ff 80 98 da bc ff ff ff ff ................ 81 55 18 bb ff ff ff ff 00 00 00 00 00 00 00 00 .U.............. backtrace: [<ffffffffb93e8d4c>] kmem_cache_alloc+0x60c/0xa80 [<ffffffffba11b4c5>] dst_alloc+0x55/0x250 [<ffffffffba227bf6>] rt_dst_alloc+0x46/0x1d0 [<ffffffffba23050a>] __mkroute_output+0x29a/0xa50 [<ffffffffba23456b>] ip_route_output_key_hash+0x10b/0x240 [<ffffffffba2346bd>] ip_route_output_flow+0x1d/0x90 [<ffffffffba254855>] inet_csk_route_req+0x2c5/0x500 [<ffffffffba26b331>] tcp_conn_request+0x691/0x12c0 [<ffffffffba27bd08>] tcp_rcv_state_process+0x3c8/0x11b0 [<ffffffffba2965c6>] tcp_v4_do_rcv+0x156/0x3b0 [<ffffffffba299c98>] tcp_v4_rcv+0x1cf8/0x1d80 [<fffffff
cess+0x3c8/0x11b0 [<ffffffffba2965c6>] tcp_v4_do_rcv+0x156/0x3b0 [<ffffffffba299c98>] tcp_v4_rcv+0x1cf8/0x1d80 [<ffffffffba239656>] ip_protocol_deliver_rcu+0xf6/0x360 [<ffffffffba2399a6>] ip_local_deliver_finish+0xe6/0x1e0 [<ffffffffba239b8e>] ip_local_deliver+0xee/0x360 [<ffffffffba239ead>] ip_rcv+0xad/0x2f0 [<ffffffffba110943>] __netif_receive_skb_one_core+0x123/0x140 Call dst_release() to free the dst memory when inet_csk_reqsk_queue_hash_add() return false in tcp_conn_request(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/9d38959677291552d1b0ed2689a540af279b5bf8 - https://git.kernel.org/stable/c/de3f999bf8aee16
tps://git.kernel.org/stable/c/9d38959677291552d1b0ed2689a540af279b5bf8 - https://git.kernel.org/stable/c/de3f999bf8aee16e9da1c1224191abdc69e97c9d - https://git.kernel.org/stable/c/2af69905180b3fea12f9c1db374b153a06977021 - https://git.kernel.org/stable/c/b0b190218c78d8aeecfba36ea3a90063b3ede52d - https://git.kernel.org/stable/c/4f4aa4aa28142d53f8b06585c478476cfe325cfc
CVE ID: CVE-2024-57843 State: PUBLISHED Published: 2025-01-11T14:30:57.255Z Last Updated: 2025-05-04T10:05:24.256Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: virtio-net: fix overflow inside virtnet_rq_alloc When the frag just got a page, then may lead to regression on VM. Specially if the sysctl net.core.high_order_alloc_disable value is 1, then the frag always get a page when do refill. Which could see reliable crashes or scp failure (scp a file 100M in size to VM). The issue is that the virtnet_rq_dma takes up 16 bytes at the beginning of a new frag. When the frag size is larger than PAGE_SIZE, everything is fine. However
kes up 16 bytes at the beginning of a new frag. When the frag size is larger than PAGE_SIZE, everything is fine. However, if the frag is only one page and the total size of the buffer and virtnet_rq_dma is larger than one page, an overflow may occur. The commit f9dac92ba908 ("virtio_ring: enable premapped mode whatever use_dma_api") introduced this problem. And we reverted some commits to fix this in last linux version. Now we try to enable it and fix this bug directly. Here, when the frag size is not enough, we reduce the buffer len to fix this problem. References: - https://git.kernel.org/stable/c/a8f7d6963768b114ec9644ff0148dde4c104e84b - https://git.kernel.org/stable/c/67a11de8965c2ab19e
://git.kernel.org/stable/c/a8f7d6963768b114ec9644ff0148dde4c104e84b - https://git.kernel.org/stable/c/67a11de8965c2ab19e215fb6651d44847e068614 - https://git.kernel.org/stable/c/6aacd1484468361d1d04badfe75f264fa5314864
CVE ID: CVE-2024-57844 State: PUBLISHED Published: 2025-01-15T13:10:27.820Z Last Updated: 2025-05-04T10:05:25.766Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix fault on fd close after unbind If userspace holds an fd open, unbinds the device and then closes it, the driver shouldn't try to access the hardware. Protect it by using drm_dev_enter()/drm_dev_exit(). This fixes the following page fault: <6> [IGT] xe_wedged: exiting, ret=98 <1> BUG: unable to handle page fault for address: ffffc901bc5e508c <1> #PF: supervisor read access in kernel mode <1> #PF: error_code(0x0000) - not-present page ... <4> xe_lrc_update_ti
c <1> #PF: supervisor read access in kernel mode <1> #PF: error_code(0x0000) - not-present page ... <4> xe_lrc_update_timestamp+0x1c/0xd0 [xe] <4> xe_exec_queue_update_run_ticks+0x50/0xb0 [xe] <4> xe_exec_queue_fini+0x16/0xb0 [xe] <4> __guc_exec_queue_fini_async+0xc4/0x190 [xe] <4> guc_exec_queue_fini_async+0xa0/0xe0 [xe] <4> guc_exec_queue_fini+0x23/0x40 [xe] <4> xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> xe_file_close+0xd4/0x1a0 [xe] <4> drm_file_free+0x210/0x280 [drm] <4> drm_close_helper.isra.0+0x6d/0x80 [drm] <4> drm_release_noglobal+0x20/0x90 [drm] (cherry picked from commit 4ca1fd418338d4d135428a0eb1e16e3b3ce17ee8) References: - https://git.kernel.org/stable/c/924d43bd10a1f6723ac5181a6e
ommit 4ca1fd418338d4d135428a0eb1e16e3b3ce17ee8) References: - https://git.kernel.org/stable/c/924d43bd10a1f6723ac5181a6e6cc2196ba98cdd - https://git.kernel.org/stable/c/fe39b222a4139354d32ff9d46b88757f63f71d63
CVE ID: CVE-2024-57849 State: PUBLISHED Published: 2025-01-11T14:30:58.365Z Last Updated: 2025-11-03T20:54:42.821Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: s390/cpum_sf: Handle CPU hotplug remove during sampling CPU hotplug remove handling triggers the following function call sequence: CPUHP_AP_PERF_S390_SF_ONLINE --> s390_pmu_sf_offline_cpu() ... CPUHP_AP_PERF_ONLINE --> perf_event_exit_cpu() The s390 CPUMF sampling CPU hotplug handler invokes: s390_pmu_sf_offline_cpu() +--> cpusf_pmu_setup() +--> setup_pmc_cpu() +--> deallocate_buffers() This function de-allocates all sampling data buffers (SDBs) allocated for that CPU
_pmc_cpu() +--> deallocate_buffers() This function de-allocates all sampling data buffers (SDBs) allocated for that CPU at event initialization. It also clears the PMU_F_RESERVED bit. The CPU is gone and can not be sampled. With the event still being active on the removed CPU, the CPU event hotplug support in kernel performance subsystem triggers the following function calls on the removed CPU: perf_event_exit_cpu() +--> perf_event_exit_cpu_context() +--> __perf_event_exit_context() +--> __perf_remove_from_context() +--> event_sched_out() +--> cpumsf_pmu_del() +--> cpumsf_pmu_stop() +--> hw_perf_event_update() to stop and remove the event. During removal of the event, the sampling device dri
mu_stop() +--> hw_perf_event_update() to stop and remove the event. During removal of the event, the sampling device driver tries to read out the remaining samples from the sample data buffers (SDBs). But they have already been freed (and may have been re-assigned). This may lead to a use after free situation in which case the samples are most likely invalid. In the best case the memory has not been reassigned and still contains valid data. Remedy this situation and check if the CPU is still in reserved state (bit PMU_F_RESERVED set). In this case the SDBs have not been released an contain valid data. This is always the case when the event is removed (and no CPU hotplug off occured). If the