Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ram Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/5d40f1bdad3dd1a177f21a90ad4353c1ed40ba3a - https://git.kernel.org/stable/c/24f8e12d965b24f8aea762589e0e9fe2025c005e - https://git.kernel.org/stable/c/cc8f7940d9c2d45f67b3d1a2f2b7a829ca561bed - https://git.kernel.org/stable/c/92c4cfaee6872038563c5b6f2e8e613f9d84d47d
CVE ID: CVE-2022-48731 State: PUBLISHED Published: 2024-06-20T11:13:19.407Z Last Updated: 2025-05-04T08:21:55.868Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mm/kmemleak: avoid scanning potential huge holes When using devm_request_free_mem_region() and devm_memremap_pages() to add ZONE_DEVICE memory, if requested free mem region's end pfn were huge(e.g., 0x400000000), the node_end_pfn() will be also huge (see move_pfn_range_to_zone()). Thus it creates a huge hole between node_start_pfn() and node_end_pfn(). We found on some AMD APUs, amdkfd requested such a free mem region and created a huge hole. In such a case, following
. We found on some AMD APUs, amdkfd requested such a free mem region and created a huge hole. In such a case, following code snippet was just doing busy test_bit() looping on the huge hole. for (pfn = start_pfn; pfn < end_pfn; pfn++) { struct page *page = pfn_to_online_page(pfn); if (!page) continue; ... } So we got a soft lockup: watchdog: BUG: soft lockup - CPU#6 stuck for 26s! [bash:1221] CPU: 6 PID: 1221 Comm: bash Not tainted 5.15.0-custom #1 RIP: 0010:pfn_to_online_page+0x5/0xd0 Call Trace: ? kmemleak_scan+0x16a/0x440 kmemleak_write+0x306/0x3a0 ? common_file_perm+0x72/0x170 full_proxy_write+0x5c/0x90 vfs_write+0xb9/0x260 ksys_write+0x67/0xe0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x3b
/0x170 full_proxy_write+0x5c/0x90 vfs_write+0xb9/0x260 ksys_write+0x67/0xe0 __x64_sys_write+0x1a/0x20 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae I did some tests with the patch. (1) amdgpu module unloaded before the patch: real 0m0.976s user 0m0.000s sys 0m0.968s after the patch: real 0m0.981s user 0m0.000s sys 0m0.973s (2) amdgpu module loaded before the patch: real 0m35.365s user 0m0.000s sys 0m35.354s after the patch: real 0m1.049s user 0m0.000s sys 0m1.042s Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d3533ee20e9a0e2e8f60384da7450d43d1c63d1a - https://git.kernel.org/stable/c/352715593e81b91
tps://git.kernel.org/stable/c/d3533ee20e9a0e2e8f60384da7450d43d1c63d1a - https://git.kernel.org/stable/c/352715593e81b917ce1b321e794549815b850134 - https://git.kernel.org/stable/c/a5389c80992f0001ee505838fe6a8b20897ce96e - https://git.kernel.org/stable/c/cebb0aceb21ad91429617a40e3a17444fabf1529 - https://git.kernel.org/stable/c/c10a0f877fe007021d70f9cada240f42adc2b5db
CVE ID: CVE-2022-48732 State: PUBLISHED Published: 2024-06-20T11:13:20.065Z Last Updated: 2025-05-04T08:21:56.924Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix off by one in BIOS boundary checking Bounds checking when parsing init scripts embedded in the BIOS reject access to the last byte. This causes driver initialization to fail on Apple eMac's with GeForce 2 MX GPUs, leaving the system with no working console. This is probably only seen on OpenFirmware machines like PowerPC Macs because the BIOS image provided by OF is only the used parts of the ROM, not a power-of-two blocks read from PCI directly so PCs
the BIOS image provided by OF is only the used parts of the ROM, not a power-of-two blocks read from PCI directly so PCs always have empty bytes at the end that are never accessed. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/d4b746e60fd8eaa8016e144223abe91158edcdad - https://git.kernel.org/stable/c/909d3ec1bf9f0ec534bfc081b77c0836fea7b0e2 - https://git.kernel.org/stable/c/b2a21669ee98aafc41c6d42ef15af4dab9e6e882 - https://git.kernel.org/stable/c/acc887ba88333f5fec49631f12d8cc7ebd95781c - https://git.kernel.org/stable/c/f071d9fa857582d7bd77f4906691f73d3edeab73 - https://git.kernel.org/stable/c/d877e814a62b7de9069aef
it.kernel.org/stable/c/f071d9fa857582d7bd77f4906691f73d3edeab73 - https://git.kernel.org/stable/c/d877e814a62b7de9069aeff8bc1d979dfc996e06 - https://git.kernel.org/stable/c/e7c36fa8a1e63b08312162179c78a0c7795ea369 - https://git.kernel.org/stable/c/1b777d4d9e383d2744fc9b3a09af6ec1893c8b1a
CVE ID: CVE-2022-48733 State: PUBLISHED Published: 2024-06-20T11:13:20.737Z Last Updated: 2025-11-03T21:46:47.137Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free after failure to create a snapshot At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and then attach it to the transaction's list of pending snapshots. After that we call btrfs_commit_transaction(), and if that returns an error we jump to 'fail' label, where we kfree() the pending snapshot structure. This can result in a later use-after-free of the pending snapshot: 1) We allocated the pending snapshot and added it to the
can result in a later use-after-free of the pending snapshot: 1) We allocated the pending snapshot and added it to the transaction's list of pending snapshots; 2) We call btrfs_commit_transaction(), and it fails either at the first call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups(). In both cases, we don't abort the transaction and we release our transaction handle. We jump to the 'fail' label and free the pending snapshot structure. We return with the pending snapshot still in the transaction's list; 3) Another task commits the transaction. This time there's no error at all, and then during the transaction commit it accesses a pointer to the pending snapshot structure tha
re's no error at all, and then during the transaction commit it accesses a pointer to the pending snapshot structure that the snapshot creation task has already freed, resulting in a user-after-free. This issue could actually be detected by smatch, which produced the following warning: fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from list So fix this by not having the snapshot creation ioctl directly add the pending snapshot to the transaction's list. Instead add the pending snapshot to the transaction handle, and then at btrfs_commit_transaction() we add the snapshot to the list only when we can guarantee that any error returned after that point will r
transaction() we add the snapshot to the list only when we can guarantee that any error returned after that point will result in a transaction abort, in which case the ioctl code can safely free the pending snapshot and no one can access it anymore. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7e4c72dbaf62f8978af8321a24dbd35566d3a78a - https://git.kernel.org/stable/c/a7b717fa15165d3d9245614680bebc48a52ac05d - https://git.kernel.org/stable/c/9372fa1d73da5f1673921e365d0cd2c27ec7adc2 - https://git.kernel.org/stable/c/28b21c558a3753171097193b6f6602a94169093a
CVE ID: CVE-2022-48734 State: PUBLISHED Published: 2024-06-20T11:13:21.392Z Last Updated: 2025-05-04T08:22:04.232Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock between quota disable and qgroup rescan worker Quota disable ioctl starts a transaction before waiting for the qgroup rescan worker completes. However, this wait can be infinite and results in deadlock because of circular dependency among the quota disable ioctl, the qgroup rescan worker and the other task with transaction such as block group relocation task. The deadlock happens with the steps following: 1) Task A calls ioctl to disable quota. It s
block group relocation task. The deadlock happens with the steps following: 1) Task A calls ioctl to disable quota. It starts a transaction and waits for qgroup rescan worker completes. 2) Task B such as block group relocation task starts a transaction and joins to the transaction that task A started. Then task B commits to the transaction. In this commit, task B waits for a commit by task A. 3) Task C as the qgroup rescan worker starts its job and starts a transaction. In this transaction start, task C waits for completion of the transaction that task A started and task B committed. This deadlock was found with fstests test case btrfs/115 and a zoned null_blk device. The test case enables a
committed. This deadlock was found with fstests test case btrfs/115 and a zoned null_blk device. The test case enables and disables quota, and the block group reclaim was triggered during the quota disable by chance. The deadlock was also observed by running quota enable and disable in parallel with 'btrfs balance' command on regular null_blk devices. An example report of the deadlock: [372.469894] INFO: task kworker/u16:6:103 blocked for more than 122 seconds. [372.479944] Not tainted 5.16.0-rc8 #7 [372.485067] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [372.493898] task:kworker/u16:6 state:D stack: 0 pid: 103 ppid: 2 flags:0x00004000 [372.503285] Workqueue: b
is message. [372.493898] task:kworker/u16:6 state:D stack: 0 pid: 103 ppid: 2 flags:0x00004000 [372.503285] Workqueue: btrfs-qgroup-rescan btrfs_work_helper [btrfs] [372.510782] Call Trace: [372.514092] <TASK> [372.521684] __schedule+0xb56/0x4850 [372.530104] ? io_schedule_timeout+0x190/0x190 [372.538842] ? lockdep_hardirqs_on+0x7e/0x100 [372.547092] ? _raw_spin_unlock_irqrestore+0x3e/0x60 [372.555591] schedule+0xe0/0x270 [372.561894] btrfs_commit_transaction+0x18bb/0x2610 [btrfs] [372.570506] ? btrfs_apply_pending_changes+0x50/0x50 [btrfs] [372.578875] ? free_unref_page+0x3f2/0x650 [372.585484] ? finish_wait+0x270/0x270 [372.591594] ? release_extent_buffer+0x224/0x420 [btrfs] [372.599264] b
3f2/0x650 [372.585484] ? finish_wait+0x270/0x270 [372.591594] ? release_extent_buffer+0x224/0x420 [btrfs] [372.599264] btrfs_qgroup_rescan_worker+0xc13/0x10c0 [btrfs] [372.607157] ? lock_release+0x3a9/0x6d0 [372.613054] ? btrfs_qgroup_account_extent+0xda0/0xda0 [btrfs] [372.620960] ? do_raw_spin_lock+0x11e/0x250 [372.627137] ? rwlock_bug.part.0+0x90/0x90 [372.633215] ? lock_is_held_type+0xe4/0x140 [372.639404] btrfs_work_helper+0x1ae/0xa90 [btrfs] [372.646268] process_one_work+0x7e9/0x1320 [372.652321] ? lock_release+0x6d0/0x6d0 [372.658081] ? pwq_dec_nr_in_flight+0x230/0x230 [372.664513] ? rwlock_bug.part.0+0x90/0x90 [372.670529] worker_thread+0x59e/0xf90 [372.676172] ? process_one_work+0x1
30 [372.664513] ? rwlock_bug.part.0+0x90/0x90 [372.670529] worker_thread+0x59e/0xf90 [372.676172] ? process_one_work+0x1320/0x1320 [372.682440] kthread+0x3b9/0x490 [372.687550] ? _raw_spin_unlock_irq+0x24/0x50 [372.693811] ? set_kthread_struct+0x100/0x100 [372.700052] ret_from_fork+0x22/0x30 [372.705517] </TASK> [372.709747] INFO: task btrfs-transacti:2347 blocked for more than 123 seconds. [372.729827] Not tainted 5.16.0-rc8 #7 [372.745907] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [372.767106] task:btrfs-transacti state:D stack: 0 pid: 2347 ppid: 2 flags:0x00004000 [372.787776] Call Trace: [372.801652] <TASK> [372.812961] __schedule+0xb56/0x4850 [372.830011]
ppid: 2 flags:0x00004000 [372.787776] Call Trace: [372.801652] <TASK> [372.812961] __schedule+0xb56/0x4850 [372.830011] ? io_schedule_timeout+0x190/0x190 [372.852547] ? lockdep_hardirqs_on+0x7e/0x100 [372.871761] ? _raw_spin_unlock_irqrestore+0x3e/0x60 [372.886792] schedule+0xe0/0x270 [372.901685] wait_current_trans+0x22c/0x310 [btrfs] [372.919743] ? btrfs_put_transaction+0x3d0/0x3d0 [btrfs] [372.938923] ? finish_wait+0x270/0x270 [372.959085] ? join_transaction+0xc7 ---truncated--- Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/26b3901d20bf9da2c6a00cb1fb48932166f80a45 - https://git.kernel.org/stable/c/32747e01436aac8
tps://git.kernel.org/stable/c/26b3901d20bf9da2c6a00cb1fb48932166f80a45 - https://git.kernel.org/stable/c/32747e01436aac8ef93fe85b5b523b4f3b52f040 - https://git.kernel.org/stable/c/89d4cca583fc9594ee7d1a0bc986886d6fb587e6 - https://git.kernel.org/stable/c/31198e58c09e21d4f65c49d2361f76b87aca4c3f - https://git.kernel.org/stable/c/e804861bd4e69cc5fe1053eedcb024982dde8e48
CVE ID: CVE-2022-48735 State: PUBLISHED Published: 2024-06-20T11:13:22.065Z Last Updated: 2025-05-21T08:43:52.277Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: Fix UAF of leds class devs at unbinding The LED class devices that are created by HD-audio codec drivers are registered via devm_led_classdev_register() and associated with the HD-audio codec device. Unfortunately, it turned out that the devres release doesn't work for this case; namely, since the codec resource release happens before the devm call chain, it triggers a NULL dereference or a UAF for a stale set_brightness_delay callback. For fixing the bug, t
evm call chain, it triggers a NULL dereference or a UAF for a stale set_brightness_delay callback. For fixing the bug, this patch changes the LED class device register and unregister in a manual manner without devres, keeping the instances in hda_gen_spec. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/a7de1002135cf94367748ffc695a29812d7633b5 - https://git.kernel.org/stable/c/0e629052f013eeb61494d4df2f1f647c2a9aef47 - https://git.kernel.org/stable/c/813e9f3e06d22e29872d4fd51b54992d89cf66c8 - https://git.kernel.org/stable/c/549f8ffc7b2f7561bea7f90930b6c5104318e87b
CVE ID: CVE-2022-48736 State: REJECTED Published: 2024-06-20T11:13:22.729Z Last Updated: 2024-07-05T06:43:37.045Z Description: No description available.
CVE ID: CVE-2022-48737 State: REJECTED Published: 2024-06-20T11:13:23.368Z Last Updated: 2024-07-05T06:43:53.123Z Description: No description available.
CVE ID: CVE-2022-48738 State: PUBLISHED Published: 2024-06-20T11:13:24.032Z Last Updated: 2025-05-04T08:22:06.336Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: ops: Reject out of bounds values in snd_soc_put_volsw() We don't currently validate that the values being set are within the range we advertised to userspace as being valid, do so and reject any values that are out of range. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/40f598698129b5ceaf31012f9501b775c7b6e57d - https://git.kernel.org/stable/c/586ef863c94354a7e00e5ae5ef01443d1dc99bc7 - ht
40f598698129b5ceaf31012f9501b775c7b6e57d - https://git.kernel.org/stable/c/586ef863c94354a7e00e5ae5ef01443d1dc99bc7 - https://git.kernel.org/stable/c/65a61b1f56f5386486757930069fbdce94af08bf - https://git.kernel.org/stable/c/68fd718724284788fc5f379e0b7cac541429ece7 - https://git.kernel.org/stable/c/a9394f21fba027147bf275b083c77955864c366a - https://git.kernel.org/stable/c/9e8895f1b3d4433f6d78aa6578e9db61ca6e6830 - https://git.kernel.org/stable/c/bb72d2dda85564c66d909108ea6903937a41679d - https://git.kernel.org/stable/c/817f7c9335ec01e0f5e8caffc4f1dcd5e458a4c0
CVE ID: CVE-2022-48739 State: PUBLISHED Published: 2024-06-20T11:13:24.693Z Last Updated: 2025-05-04T08:22:07.385Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: hdmi-codec: Fix OOB memory accesses Correct size of iec_status array by changing it to the size of status array of the struct snd_aes_iec958. This fixes out-of-bounds slab read accesses made by memcpy() of the hdmi-codec driver. This problem is reported by KASAN. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/10007bd96b6c4c3cfaea9e76c311b06a07a5e260 - https://git.kernel.org/stable/c/1552e6
ces: - https://git.kernel.org/stable/c/10007bd96b6c4c3cfaea9e76c311b06a07a5e260 - https://git.kernel.org/stable/c/1552e66be325a21d7eff49f46013fb402165a0ac - https://git.kernel.org/stable/c/06feec6005c9d9500cd286ec440aabf8b2ddd94d
CVE ID: CVE-2022-48740 State: PUBLISHED Published: 2024-06-20T11:13:25.346Z Last Updated: 2025-05-04T08:22:08.622Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: selinux: fix double free of cond_list on error paths On error path from cond_read_list() and duplicate_policydb_cond_list() the cond_list_destroy() gets called a second time in caller functions, resulting in NULL pointer deref. Fix this by resetting the cond_list_len to 0 in cond_list_destroy(), making subsequent calls a noop. Also consistently reset the cond_list pointer to NULL after freeing. [PM: fix line lengths in the description] Additional Analyst Notes: - CISA
the cond_list pointer to NULL after freeing. [PM: fix line lengths in the description] Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/f446089a268c8fc6908488e991d28a9b936293db - https://git.kernel.org/stable/c/70caa32e6d81f45f0702070c0e4dfe945e92fbd7 - https://git.kernel.org/stable/c/7ed9cbf7ac0d4ed86b356e1b944304ae9ee450d4 - https://git.kernel.org/stable/c/186edf7e368c40d06cf727a1ad14698ea67b74ad
CVE ID: CVE-2022-48741 State: PUBLISHED Published: 2024-06-20T11:13:25.990Z Last Updated: 2025-05-04T08:22:09.751Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ovl: fix NULL pointer dereference in copy up warning This patch is fixing a NULL pointer dereference to get a recently introduced warning message working. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/e6b678c1a3673de6a5d2f4e22bb725a086a0701a - https://git.kernel.org/stable/c/9c7f8a35c5a83740c0e3ea540b6ad145c50d79aa - https://git.kernel.org/stable/c/4ee7e4a6c9b298da44029ed9ec8ed23ae49cc209
CVE ID: CVE-2022-48742 State: PUBLISHED Published: 2024-06-20T11:13:26.653Z Last Updated: 2025-05-04T08:22:10.792Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink() While looking at one unrelated syzbot bug, I found the replay logic in __rtnl_newlink() to potentially trigger use-after-free. It is better to clear master_dev and m_ops inside the loop, in case we have to replay it. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/2cf180360d66bd657e606c1217e0e668e6faa303 - https://git.kernel.org
ichment: References: - https://git.kernel.org/stable/c/2cf180360d66bd657e606c1217e0e668e6faa303 - https://git.kernel.org/stable/c/7d9211678c0f0624f74cdff36117ab8316697bb8 - https://git.kernel.org/stable/c/a01e60a1ec6bef9be471fb7182a33c6d6f124e93 - https://git.kernel.org/stable/c/bd43771ee9759dd9dfae946bff190e2c5a120de5 - https://git.kernel.org/stable/c/3bbe2019dd12b8d13671ee6cda055d49637b4c39 - https://git.kernel.org/stable/c/def5e7070079b2a214b3b1a2fbec623e6fbfe34a - https://git.kernel.org/stable/c/36a9a0aee881940476b254e0352581401b23f210 - https://git.kernel.org/stable/c/c6f6f2444bdbe0079e41914a35081530d0409963
CVE ID: CVE-2022-48743 State: PUBLISHED Published: 2024-06-20T11:13:27.312Z Last Updated: 2025-05-04T12:43:38.834Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: amd-xgbe: Fix skb data length underflow There will be BUG_ON() triggered in include/linux/skbuff.h leading to intermittent kernel panic, when the skb length underflow is detected. Fix this by dropping the packet if such length underflows are seen because of inconsistencies in the hardware descriptors. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/9924c80bd484340191e586110ca22bff23a49f2e -
ment: - CVE Program Container: References: - https://git.kernel.org/stable/c/9924c80bd484340191e586110ca22bff23a49f2e - https://git.kernel.org/stable/c/617f9934bb37993b9813832516f318ba874bcb7d - https://git.kernel.org/stable/c/34aeb4da20f93ac80a6291a2dbe7b9c6460e9b26 - https://git.kernel.org/stable/c/9892742f035f7aa7dcd2bb0750effa486db89576 - https://git.kernel.org/stable/c/4d3fcfe8464838b3920bc2b939d888e0b792934e - https://git.kernel.org/stable/c/db6fd92316a254be2097556f01bccecf560e53ce - https://git.kernel.org/stable/c/e8f73f620fee5f52653ed2da360121e4446575c5 - https://git.kernel.org/stable/c/5aac9108a180fc06e28d4e7fb00247ce603b72ee
CVE ID: CVE-2022-48744 State: PUBLISHED Published: 2024-06-20T11:13:27.979Z Last Updated: 2025-05-04T08:22:13.252Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Avoid field-overflowing memcpy() In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Use flexible arrays instead of zero-element arrays (which look like they are always overflowing) and split the cross-field memcpy() into two halves that can be appropriately bounds-checked by the compiler. We were doing: #define ETH_HLEN 14 #
memcpy() into two halves that can be appropriately bounds-checked by the compiler. We were doing: #define ETH_HLEN 14 #define VLAN_HLEN 4 ... #define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN) ... struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi); ... struct mlx5_wqe_eth_seg *eseg = &wqe->eth; struct mlx5_wqe_data_seg *dseg = wqe->data; ... memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE); target is wqe->eth.inline_hdr.start (which the compiler sees as being 2 bytes in size), but copying 18, intending to write across start (really vlan_tci, 2 bytes). The remaining 16 bytes get written into wqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr (8 bytes
. The remaining 16 bytes get written into wqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr (8 bytes). struct mlx5e_tx_wqe { struct mlx5_wqe_ctrl_seg ctrl; /* 0 16 */ struct mlx5_wqe_eth_seg eth; /* 16 16 */ struct mlx5_wqe_data_seg data[]; /* 32 0 */ /* size: 32, cachelines: 1, members: 3 */ /* last cacheline: 32 bytes */ }; struct mlx5_wqe_eth_seg { u8 swp_outer_l4_offset; /* 0 1 */ u8 swp_outer_l3_offset; /* 1 1 */ u8 swp_inner_l4_offset; /* 2 1 */ u8 swp_inner_l3_offset; /* 3 1 */ u8 cs_flags; /* 4 1 */ u8 swp_flags; /* 5 1 */ __be16 mss; /* 6 2 */ __be32 flow_table_metadata; /* 8 4 */ union { struct { __be16 sz; /* 12 2 */ u8 start[2]; /* 14 2 */ } inline_hdr; /* 12
_be32 flow_table_metadata; /* 8 4 */ union { struct { __be16 sz; /* 12 2 */ u8 start[2]; /* 14 2 */ } inline_hdr; /* 12 4 */ struct { __be16 type; /* 12 2 */ __be16 vlan_tci; /* 14 2 */ } insert; /* 12 4 */ __be32 trailer; /* 12 4 */ }; /* 12 4 */ /* size: 16, cachelines: 1, members: 9 */ /* last cacheline: 16 bytes */ }; struct mlx5_wqe_data_seg { __be32 byte_count; /* 0 4 */ __be32 lkey; /* 4 4 */ __be64 addr; /* 8 8 */ /* size: 16, cachelines: 1, members: 3 */ /* last cacheline: 16 bytes */ }; So, split the memcpy() so the compiler can reason about the buffer sizes. "pahole" shows no size nor member offset changes to struct mlx5e_tx_wqe nor struct mlx5e_umr_wqe. "objdump -d" shows no mean
ole" shows no size nor member offset changes to struct mlx5e_tx_wqe nor struct mlx5e_umr_wqe. "objdump -d" shows no meaningful object code changes (i.e. only source line number induced differences and optimizations). Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/8fbdf8c8b8ab82beab882175157650452c46493e - https://git.kernel.org/stable/c/ad5185735f7dab342fdd0dd41044da4c9ccfef67