Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2021-46937 State: PUBLISHED Published: 2024-02-27T09:44:03.421Z Last Updated: 2025-05-04T07:00:41.751Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/damon/dbgfs: fix 'struct pid' leaks in 'dbgfs_target_ids_write()' DAMON debugfs interface increases the reference counts of 'struct pid's for targets from the 'target_ids' file write callback ('dbgfs_target_ids_write()'), but decreases the counts only in DAMON monitoring termination callback ('dbgfs_before_terminate()'). Therefore, when 'target_ids' file is repeatedly written without DAMON monitoring start/termination, the reference count is not decreased and theref
' file is repeatedly written without DAMON monitoring start/termination, the reference count is not decreased and therefore memory for the 'struct pid' cannot be freed. This commit fixes this issue by decreasing the reference counts when 'target_ids' is written. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/ffe4a1ba1a82c416a6b3a09d46594f6a885ae141 - https://git.kernel.org/stable/c/ebb3f994dd92f8fb4d70c7541091216c1e10cb71
CVE ID: CVE-2021-46938 State: PUBLISHED Published: 2024-02-27T18:40:26.850Z Last Updated: 2025-05-04T07:00:42.785Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm rq: fix double free of blk_mq_tag_set in dev remove after table load fails When loading a device-mapper table for a request-based mapped device, and the allocation/initialization of the blk_mq_tag_set for the device fails, a following device remove will cause a double free. E.g. (dmesg): device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device device-mapper: ioctl: unable to set up device queue for new table. Unable to handle kernel pointer
d dm-mq mapped device device-mapper: ioctl: unable to set up device queue for new table. Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0305e098835de000 TEID: 0305e098835de803 Fault in home space mode while using kernel ASCE. AS:000000025efe0007 R3:0000000000000024 Oops: 0038 ilc:3 [#1] SMP Modules linked in: ... lots of modules ... Supported: Yes, External CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G W X 5.3.18-53-default #1 SLE15-SP3 Hardware name: IBM 8561 T01 7I2 (LPAR) Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 000000000000004a 00000002
eca (kfree+0x42/0x330) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000 000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000 000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640 00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8 Krnl Code: 000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58 #000000025e368ec4: e3b010000008 ag %r11,0(%r1) >000000025e368eca: e310b0080004 lg %r1,8(%r11) 000000025e368ed0: a7110001 tmll %r1,1 000000025e368ed4: a7740129 brc 7,25e369126 000000025e368ed8: e320b0080004 lg %r2,8(%
0000025e368ed0: a7110001 tmll %r1,1 000000025e368ed4: a7740129 brc 7,25e369126 000000025e368ed8: e320b0080004 lg %r2,8(%r11) 000000025e368ede: b904001b lgr %r1,%r11 Call Trace: [<000000025e368eca>] kfree+0x42/0x330 [<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8 [<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod] [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod] [<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod] [<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod] [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod] [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod] [<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0 [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40 [<000000025e8
2/0x38 [dm_mod] [<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0 [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40 [<000000025e8c15ac>] system_call+0xd8/0x2c8 Last Breaking-Event-Address: [<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8 Kernel panic - not syncing: Fatal exception: panic_on_oops When allocation/initialization of the blk_mq_tag_set fails in dm_mq_init_request_queue(), it is uninitialized/freed, but the pointer is not reset to NULL; so when dev_remove() later gets into dm_mq_cleanup_mapped_device() it sees the pointer and tries to uninitialize and free it again. Fix this by setting the pointer to NULL in dm_mq_init_request_queue() error-handling. Also set it to NULL in dm_mq_cleanup_
this by setting the pointer to NULL in dm_mq_init_request_queue() error-handling. Also set it to NULL in dm_mq_cleanup_mapped_device(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/8ae0185255eaf05bd66f4215c81e99bf01140fd9 - https://git.kernel.org/stable/c/b42c0a33dfdd451d9be62dd5de58c39f2750b6e3 - https://git.kernel.org/stable/c/772b9f59657665af3b68d24d12b9d172d31f0dfb - https://git.kernel.org/stable/c/a992a283c0b77d0a7c2c348add0e6a21fb1dab67 - https://git.kernel.org/stable/c/1cb02dc76f4c0a2749a02b26469512d6984252e9 - https://git.kernel.org/stable/c/6086f957416a6e87236c06079fcaba7a3998aeca - https://git.kernel.org/
b26469512d6984252e9 - https://git.kernel.org/stable/c/6086f957416a6e87236c06079fcaba7a3998aeca - https://git.kernel.org/stable/c/d757bf4c69cda3c3ab7f775dfabbf5a80e2f6f9d - https://git.kernel.org/stable/c/8e947c8f4a5620df77e43c9c75310dc510250166
CVE ID: CVE-2021-46939 State: PUBLISHED Published: 2024-02-27T18:40:27.471Z Last Updated: 2025-05-04T07:00:43.860Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tracing: Restructure trace_clock_global() to never block It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock
x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ? trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ? pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ? trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0 With the following RIP: RI
me_optional+0x90/0x90 ? trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0 With the following RIP: RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200 Since the fix to the recursion detection would allow a single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and then trying to take it again: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* lock taken */ (something else gets traced by function graph tracer) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* DEAD LOCK! */ Tracing should *never* block, as it can lead to st
) { arch_spin_lock() { queued_spin_lock_slowpath() { /* DEAD LOCK! */ Tracing should *never* block, as it can lead to strange lockups like the above. Restructure the trace_clock_global() code to instead of simply taking a lock to update the recorded "prev_time" simply use it, as two events happening on two different CPUs that calls this at the same time, really doesn't matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails, simply try again the next time. If it failed to be taken, that means something else is already updating it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761 Additional Analyst Notes: - CISA ADP Vulnrichment: - C
it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/91ca6f6a91f679c8645d7f3307e03ce86ad518c4 - https://git.kernel.org/stable/c/859b47a43f5a0e5b9a92b621dc6ceaad39fb5c8b - https://git.kernel.org/stable/c/1fca00920327be96f3318224f502e4d5460f9545 - https://git.kernel.org/stable/c/d43d56dbf452ccecc1ec735cd4b6840118005d7c - https://git.kernel.org/stable/c/c64da3294a7d59a4bf6874c664c13be892f15f44 - https://git.kernel.org/stable/c/a33614d52e97fc8077eb0b292189ca7d964cc534 - https://git.kernel.org/stable/c/6e2418576228eeb12e7ba82edb8f9500623942ff - https://git.kernel.
7eb0b292189ca7d964cc534 - https://git.kernel.org/stable/c/6e2418576228eeb12e7ba82edb8f9500623942ff - https://git.kernel.org/stable/c/2a1bd74b8186d7938bf004f5603f25b84785f63e - https://git.kernel.org/stable/c/aafe104aa9096827a429bc1358f8260ee565b7cc
CVE ID: CVE-2021-46940 State: PUBLISHED Published: 2024-02-27T18:40:28.063Z Last Updated: 2025-05-04T07:00:44.951Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tools/power turbostat: Fix offset overflow issue in index converting The idx_to_offset() function returns type int (32-bit signed), but MSR_PKG_ENERGY_STAT is u32 and would be interpreted as a negative number. The end result is that it hits the if (offset < 0) check in update_msr_sum() which prevents the timer callback from updating the stat in the background when long durations are used. The similar issue exists in offset_to_idx() and update_msr_sum(). Fix this issue
ckground when long durations are used. The similar issue exists in offset_to_idx() and update_msr_sum(). Fix this issue by converting the 'int' to 'off_t' accordingly. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/ea6803ff2cd1a2d7d880256bf562172b708a76ff - https://git.kernel.org/stable/c/dbdf22fc825fdb1d97f23230064e0f9819471628 - https://git.kernel.org/stable/c/337b1546cde87fb8588ddaedf0201b769baa572a - https://git.kernel.org/stable/c/13a779de4175df602366d129e41782ad7168cef0
CVE ID: CVE-2021-46941 State: PUBLISHED Published: 2024-02-27T18:40:28.664Z Last Updated: 2025-05-04T07:00:51.266Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: Do core softreset when switch mode According to the programming guide, to switch mode for DRD controller, the driver needs to do the following. To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(devic
egisters sequence To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing registers sequence Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferry's testing platform[2]. So, apply the required steps along with some fixes to Yu Chen's and John Stultz's version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCT
to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device. [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/ Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/fce7bbcd07d59ac30dba8ce225316b3b4c1c7b50 - https://git.kernel.org/stable/c/800f58217626c8b147aa40660e572ed8a0d56e3b - https://git.kernel.org/stable/c/1c10fd60c8595ea7ff7e29d3cf1fa88069941da3 - https://git.kernel.org/stable/c/f88359e1588b85cf
ps://git.kernel.org/stable/c/1c10fd60c8595ea7ff7e29d3cf1fa88069941da3 - https://git.kernel.org/stable/c/f88359e1588b85cf0e8209ab7d6620085f3441d9
CVE ID: CVE-2021-46942 State: PUBLISHED Published: 2024-02-27T18:40:29.280Z Last Updated: 2025-05-04T07:00:52.314Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: io_uring: fix shared sqpoll cancellation hangs [ 736.982891] INFO: task iou-sqp-4294:4295 blocked for more than 122 seconds. [ 736.982897] Call Trace: [ 736.982901] schedule+0x68/0xe0 [ 736.982903] io_uring_cancel_sqpoll+0xdb/0x110 [ 736.982908] io_sqpoll_cancel_cb+0x24/0x30 [ 736.982911] io_run_task_work_head+0x28/0x50 [ 736.982913] io_sq_thread+0x4e3/0x720 We call io_uring_cancel_sqpoll() one by one for each ctx either in sq_thread() itself or via task works, and it'
3/0x720 We call io_uring_cancel_sqpoll() one by one for each ctx either in sq_thread() itself or via task works, and it's intended to cancel all requests of a specified context. However the function uses per-task counters to track the number of inflight requests, so it counts more requests than available via currect io_uring ctx and goes to sleep for them to appear (e.g. from IRQ), that will never happen. Cancel a bit more than before, i.e. all ctxs that share sqpoll and continue to use shared counters. Don't forget that we should not remove ctx from the list before running that task_work sqpoll-cancel, otherwise the function wouldn't be able to find the context and will hang. Additional Ana
that task_work sqpoll-cancel, otherwise the function wouldn't be able to find the context and will hang. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/cb5e0b3d0f993a6268c1a2c7ede2f9aa0c17ef68 - https://git.kernel.org/stable/c/734551df6f9bedfbefcd113ede665945e9de0b99
CVE ID: CVE-2021-46943 State: PUBLISHED Published: 2024-02-27T18:40:29.903Z Last Updated: 2025-05-04T07:00:53.807Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: staging/intel-ipu3: Fix set_fmt error handling If there in an error during a set_fmt, do not overwrite the previous sizes with the invalid config. Without this patch, v4l2-compliance ends up allocating 4GiB of RAM and causing the following OOPs [ 38.662975] ipu3-imgu 0000:00:05.0: swiotlb buffer is full (sz: 4096 bytes) [ 38.662980] DMA: Out of SW-IOMMU space for 4096 bytes at device 0000:00:05.0 [ 38.663010] general protection fault: 0000 [#1] PREEMPT SMP Addit
SW-IOMMU space for 4096 bytes at device 0000:00:05.0 [ 38.663010] general protection fault: 0000 [#1] PREEMPT SMP Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/a03fb1e8a110658215a4cefc3e2ad53279e496a6 - https://git.kernel.org/stable/c/c6b81b897f6f9445d57f8d47c4e060ec21556137 - https://git.kernel.org/stable/c/34892ea938387d83ffcfb7775ec55f0f80767916 - https://git.kernel.org/stable/c/6fb617e37a39db0a3eca4489431359d0bdf3b9bc - https://git.kernel.org/stable/c/ad91849996f9dd79741a961fd03585a683b08356
CVE ID: CVE-2021-46944 State: PUBLISHED Published: 2024-02-27T18:40:30.494Z Last Updated: 2025-05-04T07:00:55.061Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: staging/intel-ipu3: Fix memory leak in imu_fmt We are losing the reference to an allocated memory if try. Change the order of the check to avoid that. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/ff792ae52005c85a2d829c153e08d99a356e007d - https://git.kernel.org/stable/c/517f6f570566a863c2422b843c8b7d099474f6a9 - https://git.kernel.org/stable/c/14d0e99c3ef6b0648535a31bf2eaabb4eff97b9e -
c/517f6f570566a863c2422b843c8b7d099474f6a9 - https://git.kernel.org/stable/c/14d0e99c3ef6b0648535a31bf2eaabb4eff97b9e - https://git.kernel.org/stable/c/74ba0adb5e983503b18a96121d965cad34ac7ce3 - https://git.kernel.org/stable/c/3630901933afba1d16c462b04d569b7576339223
CVE ID: CVE-2021-46945 State: PUBLISHED Published: 2024-02-27T18:40:31.095Z Last Updated: 2025-05-04T07:00:56.295Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: always panic when errors=panic is specified Before commit 014c9caa29d3 ("ext4: make ext4_abort() use __ext4_error()"), the following series of commands would trigger a panic: 1. mount /dev/sda -o ro,errors=panic test 2. mount /dev/sda -o remount,abort test After commit 014c9caa29d3, remounting a file system using the test mount option "abort" will no longer trigger a panic. This commit will restore the behaviour immediately before commit 014c9caa29d3. (However, n
ll no longer trigger a panic. This commit will restore the behaviour immediately before commit 014c9caa29d3. (However, note that the Linux kernel's behavior has not been consistent; some previous kernel versions, including 5.4 and 4.19 similarly did not panic after using the mount option "abort".) This also makes a change to long-standing behaviour; namely, the following series commands will now cause a panic, when previously it did not: 1. mount /dev/sda -o ro,errors=panic test 2. echo test > /sys/fs/ext4/sda/trigger_fs_error However, this makes ext4's behaviour much more consistent, so this is a good thing. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: Referen
consistent, so this is a good thing. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/64e1eebe2131183174f4fbb6b1491355f96c6cde - https://git.kernel.org/stable/c/1e9ea8f4637026b8e965128953f2da061ccae9c4 - https://git.kernel.org/stable/c/ac2f7ca51b0929461ea49918f27c11b680f28995
CVE ID: CVE-2021-46946 State: REJECTED Published: 2024-02-27T18:40:31.680Z Last Updated: 2024-03-08T10:09:17.569Z Description: No description available.
CVE ID: CVE-2021-46947 State: PUBLISHED Published: 2024-02-27T18:40:32.277Z Last Updated: 2025-05-04T07:00:57.499Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sfc: adjust efx->xdp_tx_queue_count with the real number of initialized queues efx->xdp_tx_queue_count is initially initialized to num_possible_cpus() and is later used to allocate and traverse efx->xdp_tx_queues lookup array. However, we may end up not initializing all the array slots with real queues during probing. This results, for example, in a NULL pointer dereference, when running "# ethtool -S <iface>", similar to below [2570283.664955][T4126959] BUG: kernel NU
ULL pointer dereference, when running "# ethtool -S <iface>", similar to below [2570283.664955][T4126959] BUG: kernel NULL pointer dereference, address: 00000000000000f8 [2570283.681283][T4126959] #PF: supervisor read access in kernel mode [2570283.695678][T4126959] #PF: error_code(0x0000) - not-present page [2570283.710013][T4126959] PGD 0 P4D 0 [2570283.721649][T4126959] Oops: 0000 [#1] SMP PTI [2570283.734108][T4126959] CPU: 23 PID: 4126959 Comm: ethtool Tainted: G O 5.10.20-cloudflare-2021.3.1 #1 [2570283.752641][T4126959] Hardware name: <redacted> [2570283.781408][T4126959] RIP: 0010:efx_ethtool_get_stats+0x2ca/0x330 [sfc] [2570283.796073][T4126959] Code: 00 85 c0 74 39 48 8b 95 a8 0f 0
6959] RIP: 0010:efx_ethtool_get_stats+0x2ca/0x330 [sfc] [2570283.796073][T4126959] Code: 00 85 c0 74 39 48 8b 95 a8 0f 00 00 48 85 d2 74 2d 31 c0 eb 07 48 8b 95 a8 0f 00 00 48 63 c8 49 83 c4 08 83 c0 01 48 8b 14 ca <48> 8b 92 f8 00 00 00 49 89 54 24 f8 39 85 a0 0f 00 00 77 d7 48 8b [2570283.831259][T4126959] RSP: 0018:ffffb79a77657ce8 EFLAGS: 00010202 [2570283.845121][T4126959] RAX: 0000000000000019 RBX: ffffb799cd0c9280 RCX: 0000000000000018 [2570283.860872][T4126959] RDX: 0000000000000000 RSI: ffff96dd970ce000 RDI: 0000000000000005 [2570283.876525][T4126959] RBP: ffff96dd86f0a000 R08: ffff96dd970ce480 R09: 000000000000005f [2570283.892014][T4126959] R10: ffffb799cd0c9fff R11: ffffb799cd0c9
86f0a000 R08: ffff96dd970ce480 R09: 000000000000005f [2570283.892014][T4126959] R10: ffffb799cd0c9fff R11: ffffb799cd0c9000 R12: ffffb799cd0c94f8 [2570283.907406][T4126959] R13: ffffffffc11b1090 R14: ffff96dd970ce000 R15: ffffffffc11cd66c [2570283.922705][T4126959] FS: 00007fa7723f8740(0000) GS:ffff96f51fac0000(0000) knlGS:0000000000000000 [2570283.938848][T4126959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2570283.952524][T4126959] CR2: 00000000000000f8 CR3: 0000001a73e6e006 CR4: 00000000007706e0 [2570283.967529][T4126959] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [2570283.982400][T4126959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [25
0 DR2: 0000000000000000 [2570283.982400][T4126959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [2570283.997308][T4126959] PKRU: 55555554 [2570284.007649][T4126959] Call Trace: [2570284.017598][T4126959] dev_ethtool+0x1832/0x2830 Fix this by adjusting efx->xdp_tx_queue_count after probing to reflect the true value of initialized slots in efx->xdp_tx_queues. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/ebeac958b690123a0b40aa61f688f2f170035fad - https://git.kernel.org/stable/c/99ba0ea616aabdc8e26259fd722503e012199a76
CVE ID: CVE-2021-46948 State: PUBLISHED Published: 2024-02-27T18:40:32.895Z Last Updated: 2025-05-04T07:00:58.597Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sfc: farch: fix TX queue lookup in TX event handling We're starting from a TXQ label, not a TXQ type, so efx_channel_get_tx_queue() is inappropriate (and could return NULL, leading to panics). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/bf2b941d0a6f2d3b9f5fa3c4c21bdd54f71ce253 - https://git.kernel.org/stable/c/35c7a83ad1bb1d48ae249346e61b1132bcbf9052 - https://git.kernel.org/stable/c/e531db1e
53 - https://git.kernel.org/stable/c/35c7a83ad1bb1d48ae249346e61b1132bcbf9052 - https://git.kernel.org/stable/c/e531db1ea6f98c9612cb2de093a107c7eadfb96c - https://git.kernel.org/stable/c/83b09a1807415608b387c7bc748d329fefc5617e
CVE ID: CVE-2021-46949 State: PUBLISHED Published: 2024-02-27T18:40:33.496Z Last Updated: 2025-05-04T07:00:59.755Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sfc: farch: fix TX queue lookup in TX flush done handling We're starting from a TXQ instance number ('qid'), not a TXQ type, so efx_get_tx_queue() is inappropriate (and could return NULL, leading to panics). Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/fb791572d6747ef385f628450f8d57cd132e6e5a - https://git.kernel.org/stable/c/a1570985ec04116cc665b760faf666a104154170 - https://git.kernel.org/st
50f8d57cd132e6e5a - https://git.kernel.org/stable/c/a1570985ec04116cc665b760faf666a104154170 - https://git.kernel.org/stable/c/98d91180748986bfb6dfb3e72765f3225719a647 - https://git.kernel.org/stable/c/5b1faa92289b53cad654123ed2bc8e10f6ddd4ac