Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
033:0x7fe5e7b52479 Code: Unable to access opcode bytes at RIP 0x7fe5e7b5244f. RSP: 002b:00007ffd3c800398 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe5e7b52479 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 RBP: 00007fe5e7bcd2d0 R08: ffffffffffffffb8 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe5e7bcd2d0 R13: 0000000000000000 R14: 00007fe5e7bcdd20 R15: 00007fe5e7b24270 The crash can be also be reproduced with the following (with a tc recompiled to allow for sfq limits of 1): tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s ../iproute2-6.9.0/tc/tc qdisc add dev dum
of 1): tc qdisc add dev dummy0 handle 1: root tbf rate 1Kbit burst 100b lat 1s ../iproute2-6.9.0/tc/tc qdisc add dev dummy0 handle 2: parent 1:10 sfq limit 1 ifconfig dummy0 up ping -I dummy0 -f -c2 -W0.1 8.8.8.8 sleep 1 Scenario that triggers the crash: * the first packet is sent and queued in TBF and SFQ; qdisc qlen is 1 * TBF dequeues: it peeks from SFQ which moves the packet to the gso_skb list and keeps qdisc qlen set to 1. TBF is out of tokens so it schedules itself for later. * the second packet is sent and TBF tries to queues it to SFQ. qdisc qlen is now 2 and because the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however
se the SFQ limit is 1 the packet is dropped by SFQ. At this point qlen is 1, and all of the SFQ slots are empty, however q->tail is not NULL. At this point, assuming no more packets are queued, when sch_dequeue runs again it will decrement the qlen for the current empty slot causing an underflow and the subsequent out of bounds access. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/e12f6013d0a69660e8b99bfe381b9546ae667328 - https://git.kernel.org/stable/c/1e6d9d87626cf89eeffb4d943db12cb5b10bf961 - https://git.kernel.org/stable/c/1b562b7f9231432da40d12e19786c1bd7df653a7 - https://git.kernel.org/stable/c/35d0137305ae2f97260a9047f445bd4434bd6cc7
le/c/1b562b7f9231432da40d12e19786c1bd7df653a7 - https://git.kernel.org/stable/c/35d0137305ae2f97260a9047f445bd4434bd6cc7 - https://git.kernel.org/stable/c/833e9a1c27b82024db7ff5038a51651f48f05e5e - https://git.kernel.org/stable/c/7d8947f2153ee9c5ab4cb17861a11cc45f30e8c4 - https://git.kernel.org/stable/c/7fefc294204f10a3405f175f4ac2be16d63f135e - https://git.kernel.org/stable/c/10685681bafce6febb39770f3387621bf5d67d0b
CVE ID: CVE-2024-57997 State: PUBLISHED Published: 2025-02-27T02:07:17.371Z Last Updated: 2025-11-03T19:33:08.950Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: wcn36xx: fix channel survey memory allocation size KASAN reported a memory allocation issue in wcn->chan_survey due to incorrect size calculation. This commit uses kcalloc to allocate memory for wcn->chan_survey, ensuring proper initialization and preventing the use of uninitialized values when there are no frames on the channel. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/ae68efdff7a7a
yst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/ae68efdff7a7a42ab251cac79d8713de6f0dbaa0 - https://git.kernel.org/stable/c/e95f9c408ff8311f75eeabc8acf34a66670d8815 - https://git.kernel.org/stable/c/64c4dcaeac1dc1030e47883b04a617ca9a4f164e - https://git.kernel.org/stable/c/34cd2817708aec51ef1a6c007e0d6d5342a025d7 - https://git.kernel.org/stable/c/6200d947f050efdba4090dfefd8a01981363d954
CVE ID: CVE-2024-57998 State: PUBLISHED Published: 2025-02-27T02:07:17.965Z Last Updated: 2025-11-03T19:33:10.348Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: OPP: add index check to assert to avoid buffer overflow in _read_freq() Pass the freq index to the assert function to make sure we do not read a freq out of the opp->rates[] table when called from the indexed variants: dev_pm_opp_find_freq_exact_indexed() or dev_pm_opp_find_freq_ceil/floor_indexed(). Add a secondary parameter to the assert function, unused for assert_single_clk() then add assert_clk_index() which will check for the clock index when called from the _ind
nused for assert_single_clk() then add assert_clk_index() which will check for the clock index when called from the _indexed() find functions. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/774dd6f0f0a61c9c3848e025d7d9eeed1a7ca4cd - https://git.kernel.org/stable/c/eb6ffa0192ba83ece1a318b956265519c5c7dcec - https://git.kernel.org/stable/c/7d68c20638e50d5eb4576492a7958328ae445248 - https://git.kernel.org/stable/c/da2a6acc73933b7812c94794726e438cde39e037 - https://git.kernel.org/stable/c/d659bc68ed489022ea33342cfbda2911a81e7a0d
CVE ID: CVE-2024-57999 State: PUBLISHED Published: 2025-02-27T02:07:18.570Z Last Updated: 2025-05-04T10:08:04.729Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW Power Hypervisor can possibily allocate MMIO window intersecting with Dynamic DMA Window (DDW) range, which is over 32-bit addressing. These MMIO pages needs to be marked as reserved so that IOMMU doesn't map DMA buffers in this range. The current code is not marking these pages correctly which is resulting in LPAR to OOPS while booting. The stack is at below BUG: Unable to handle kernel data access on re
y which is resulting in LPAR to OOPS while booting. The stack is at below BUG: Unable to handle kernel data access on read at 0xc00800005cd40000 Faulting instruction address: 0xc00000000005cdac Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: af_packet rfkill ibmveth(X) lpfc(+) nvmet_fc nvmet nvme_keyring crct10dif_vpmsum nvme_fc nvme_fabrics nvme_core be2net(+) nvme_auth rtc_generic nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse configfs ip_tables x_tables xfs libcrc32c dm_service_time ibmvfc(X) scsi_transport_fc vmx_crypto gf128mul crc32c_vpmsum dm_mirror dm_region_hash dm_log dm_multipath dm_mod sd_mod scsi_dh_emc s
_transport_fc vmx_crypto gf128mul crc32c_vpmsum dm_mirror dm_region_hash dm_log dm_multipath dm_mod sd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua t10_pi crc64_rocksoft_generic crc64_rocksoft sg crc64 scsi_mod Supported: Yes, External CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950_149) hv:phyp pSeries Workqueue: events work_for_cpu_fn NIP: c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000 REGS: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR
S: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24228448 XER: 00000001 CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800 GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000 GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000 GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8
0000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8 GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800 NIP [c00000000005cdac] iommu_table_reserve_pages+0xac/0x100 LR [c00000000005e830] iommu_init_table+0x80/0x1e0 Call Trace: [c00001400c9ffa10] [c00000000005e810] iommu_init_table+0x60/0x1e0 (unreliable) [c00001400c9ffa90] [c00000000010356c] iommu_bypass_supported_pSeriesLP+0x9cc/0xe40 [c00001400c9ffc30] [c00000000005c300] dma_iommu_dma_supported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dma_supported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b1
ma_supported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dma_supported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b14c] dma_set_mask+0x3c/0x80 [c00001400c9ffd00] [c0080000555b715c] be_probe+0xc4/0xb90 [be2net] [c00001400c9ffdc0] [c000000000986f3c] local_pci_probe+0x6c/0x110 [c00001400c9ffe40] [c000000000188f28] work_for_cpu_fn+0x38/0x60 [c00001400c9ffe70] [c00000000018e454] process_one_work+0x314/0x620 [c00001400c9fff10] [c00000000018f280] worker_thread+0x2b0/0x620 [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150 [c00001400c9fffe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 There are 2 issues in the code 1. The index is "int" while the address is "unsigned long". This resu
el_thread+0x14/0x18 There are 2 issues in the code 1. The index is "int" while the address is "unsigned long". This results in negative value when setting the bitmap. 2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit address). MMIO address needs to be page shifted as well. References: - https://git.kernel.org/stable/c/7043d58ecd1381674f5b2c894deb6986a1a4896b - https://git.kernel.org/stable/c/d8cc20a8cceb3b5e8ad2e11365e3100ba36a27e9 - https://git.kernel.org/stable/c/8f70caad82e9c088ed93b4fea48d941ab6441886
CVE ID: CVE-2024-58000 State: PUBLISHED Published: 2025-02-27T02:07:19.155Z Last Updated: 2025-05-04T10:08:06.384Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: io_uring: prevent reg-wait speculations With *ENTER_EXT_ARG_REG instead of passing a user pointer with arguments for the waiting loop the user can specify an offset into a pre-mapped region of memory, in which case the [offset, offset + sizeof(io_uring_reg_wait)) will be intepreted as the argument. As we address a kernel array using a user given index, it'd be a subject to speculation type of exploits. Use array_index_nospec() to prevent that. Make sure to pass not the
, it'd be a subject to speculation type of exploits. Use array_index_nospec() to prevent that. Make sure to pass not the full region size but truncate by the maximum offset allowed considering the structure size. References: - https://git.kernel.org/stable/c/2a6de94df7bfa76d9850443547e7b3333f63a16a - https://git.kernel.org/stable/c/29b95ac917927ce9f95bf38797e16333ecb489b1
CVE ID: CVE-2024-58001 State: PUBLISHED Published: 2025-02-27T02:11:59.570Z Last Updated: 2025-11-03T19:33:13.130Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ocfs2: handle a symlink read error correctly Patch series "Convert ocfs2 to use folios". Mark did a conversion of ocfs2 to use folios and sent it to me as a giant patch for review ;-) So I've redone it as individual patches, and credited Mark for the patches where his code is substantially the same. It's not a bad way to do it; his patch had some bugs and my patches had some bugs. Hopefully all our bugs were different from each other. And hopefully Mark likes all the c
and my patches had some bugs. Hopefully all our bugs were different from each other. And hopefully Mark likes all the changes I made to his code! This patch (of 23): If we can't read the buffer, be sure to unlock the page before returning. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/cd3e22b206189cbb4a94229002141e1529f83746 - https://git.kernel.org/stable/c/afa8003f8db62e46c4b171cbf4cec2824148b4f7 - https://git.kernel.org/stable/c/8aee4184c5b79e486598c15aa80687c77f6f6e6e - https://git.kernel.org/stable/c/6e143eb4ab83c24e7ad3e3d8e7daa241d9c38377 - https://git.kernel.org/stable/c/b6833b38984d1e9f20dd80f9ec9050c10d687f30 - https://git.kernel.
ad3e3d8e7daa241d9c38377 - https://git.kernel.org/stable/c/b6833b38984d1e9f20dd80f9ec9050c10d687f30 - https://git.kernel.org/stable/c/52a326f93ceb9348264fddf7bab6e345db69e08c - https://git.kernel.org/stable/c/5e3b3ec7c3cb5ba5629a766e4f0926db72cf0a1f - https://git.kernel.org/stable/c/2b4c2094da6d84e69b843dd3317902e977bf64bd
CVE ID: CVE-2024-58002 State: PUBLISHED Published: 2025-02-27T02:12:00.223Z Last Updated: 2025-11-03T19:33:15.914Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Remove dangling pointers When an async control is written, we copy a pointer to the file handle that started the operation. That pointer will be used when the device is done. Which could be anytime in the future. If the user closes that file descriptor, its structure will be freed, and there will be one dangling pointer per pending async control, that the driver will try to use. Clean all the dangling pointers during release(). To avoid adding a perfor
ync control, that the driver will try to use. Clean all the dangling pointers during release(). To avoid adding a performance penalty in the most common case (no async operation), a counter has been introduced with some logic to make sure that it is properly handled. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/2a29413ace64627e178fd422dd8a5d95219a2c0b - https://git.kernel.org/stable/c/653993f46861f2971e95e9a0e36a34b49dec542c - https://git.kernel.org/stable/c/117f7a2975baa4b7d702d3f4830d5a4ebd0c6d50 - https://git.kernel.org/stable/c/ac18d781466252cd35a3e311e0a4b264260fd927 - https://git.kernel.org/stable/c/4dbaa738c583a0e947803c69e8996e88cf9
/stable/c/ac18d781466252cd35a3e311e0a4b264260fd927 - https://git.kernel.org/stable/c/4dbaa738c583a0e947803c69e8996e88cf98d971 - https://git.kernel.org/stable/c/438bda062b2c40ddd7df23b932e29ffe0a448cac - https://git.kernel.org/stable/c/9edc7d25f7e49c33a1ce7a5ffadea2222065516c - https://git.kernel.org/stable/c/221cd51efe4565501a3dbf04cc011b537dcce7fb
CVE ID: CVE-2024-58003 State: PUBLISHED Published: 2025-02-27T02:12:00.834Z Last Updated: 2025-05-04T10:08:10.796Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: i2c: ds90ub9x3: Fix extra fwnode_handle_put() The ub913 and ub953 drivers call fwnode_handle_put(priv->sd.fwnode) as part of their remove process, and if the driver is removed multiple times, eventually leads to put "overflow", possibly causing memory corruption or crash. The fwnode_handle_put() is a leftover from commit 905f88ccebb1 ("media: i2c: ds90ub9x3: Fix sub-device matching"), which changed the code related to the sd.fwnode, but missed removing these fwn
2c: ds90ub9x3: Fix sub-device matching"), which changed the code related to the sd.fwnode, but missed removing these fwnode_handle_put() calls. References: - https://git.kernel.org/stable/c/474d7baf91d37bc411fa60de5bbf03c9dd82e18a - https://git.kernel.org/stable/c/f4e4373322f8d4c19721831f7fb989e52d30dab0 - https://git.kernel.org/stable/c/70743d6a8b256225675711e7983825f1be86062d - https://git.kernel.org/stable/c/60b45ece41c5632a3a3274115a401cb244180646
CVE ID: CVE-2024-58004 State: PUBLISHED Published: 2025-02-27T02:12:01.426Z Last Updated: 2025-05-04T10:08:12.333Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: intel/ipu6: remove cpu latency qos request on error Fix cpu latency qos list corruption like below. It happens when we do not remove cpu latency request on error path and free corresponding memory. [ 30.634378] l7 kernel: list_add corruption. prev->next should be next (ffffffff9645e960), but was 0000000100100001. (prev=ffff8e9e877e20a8). [ 30.634388] l7 kernel: WARNING: CPU: 2 PID: 2008 at lib/list_debug.c:32 __list_add_valid_or_report+0x83/0xa0 <snip> [ 30.6346
34388] l7 kernel: WARNING: CPU: 2 PID: 2008 at lib/list_debug.c:32 __list_add_valid_or_report+0x83/0xa0 <snip> [ 30.634640] l7 kernel: Call Trace: [ 30.634650] l7 kernel: <TASK> [ 30.634659] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0 [ 30.634669] l7 kernel: ? __warn.cold+0x93/0xf6 [ 30.634678] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0 [ 30.634690] l7 kernel: ? report_bug+0xff/0x140 [ 30.634702] l7 kernel: ? handle_bug+0x58/0x90 [ 30.634712] l7 kernel: ? exc_invalid_op+0x17/0x70 [ 30.634723] l7 kernel: ? asm_exc_invalid_op+0x1a/0x20 [ 30.634733] l7 kernel: ? __list_add_valid_or_report+0x83/0xa0 [ 30.634742] l7 kernel: plist_add+0xdd/0x140 [ 30.634754] l7 kernel: pm_qos_update_t
_list_add_valid_or_report+0x83/0xa0 [ 30.634742] l7 kernel: plist_add+0xdd/0x140 [ 30.634754] l7 kernel: pm_qos_update_target+0xa0/0x1f0 [ 30.634764] l7 kernel: cpu_latency_qos_update_request+0x61/0xc0 [ 30.634773] l7 kernel: intel_dp_aux_xfer+0x4c7/0x6e0 [i915 1f824655ed04687c2b0d23dbce759fa785f6d033] References: - https://git.kernel.org/stable/c/1496ec94bd38bdb25ca13b1dd4f8e7a6176ea89d - https://git.kernel.org/stable/c/95275736185ecb71dc97a71d8d9d19e4ffb0a9eb - https://git.kernel.org/stable/c/facb541ff0805314e0b56e508f7d3cbd07af513c
CVE ID: CVE-2024-58005 State: PUBLISHED Published: 2025-02-27T02:12:02.232Z Last Updated: 2025-11-03T19:33:18.687Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tpm: Change to kvalloc() in eventlog/acpi.c The following failure was reported on HPE ProLiant D320: [ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0) [ 10.848132][ T1] ------------[ cut here ]------------ [ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330 [ 10.862827][ T1] Modules linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSU
linked in: [ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375 [ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024 [ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330 [ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1 [ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 000
[ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246 [ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000 [ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0 The above transcript shows that ACPI pointed a 16 MiB buffer for the log events because RSI maps to the 'order' parameter of __alloc_pages_noprof(). Address the bug by moving from devm_kmalloc() to devm_add_action() and kvmalloc() and devm_add_action(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a676c0401de59548a5bc1b7aaf98f556ae8ea6db - https://git.kernel.org/stable/c/0621d2599d6e02d05c85d6bbd58eaea2f15b3503 - https://git.k
59548a5bc1b7aaf98f556ae8ea6db - https://git.kernel.org/stable/c/0621d2599d6e02d05c85d6bbd58eaea2f15b3503 - https://git.kernel.org/stable/c/77779d1258a287f2c5c2c6aeae203e0996209c77 - https://git.kernel.org/stable/c/50365a6304a57266e8f4d3078060743c3b7a1e0d - https://git.kernel.org/stable/c/422d7f4e8d817be467986589c7968d3ea402f7da - https://git.kernel.org/stable/c/4c8bfe643bbd00b04ee8f9545ef33bf6a68c38db - https://git.kernel.org/stable/c/a3a860bc0fd6c07332e4911cf9a238d20de90173
CVE ID: CVE-2024-58006 State: PUBLISHED Published: 2025-02-27T02:12:02.932Z Last Updated: 2025-05-04T10:08:15.420Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar() In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") set_bar() was modified to support dynamically changing the backing physical address of a BAR that was already configured. This means that set_bar() can be called twice, without ever calling clear_bar() (as calling clear_bar() would clear the BAR's PCI address assigned by the host). This can only be done if
g clear_bar() (as calling clear_bar() would clear the BAR's PCI address assigned by the host). This can only be done if the new BAR size/flags does not differ from the existing BAR configuration. Add these missing checks. If we allow set_bar() to set e.g. a new BAR size that differs from the existing BAR size, the new address translation range will be smaller than the BAR size already determined by the host, which would mean that a read past the new BAR size would pass the iATU untranslated, which could allow the host to read memory not belonging to the new struct pci_epf_bar. While at it, add comments which clarifies the support for dynamically changing the physical address of a BAR. (Which
ar. While at it, add comments which clarifies the support for dynamically changing the physical address of a BAR. (Which was also missing.) References: - https://git.kernel.org/stable/c/b5cacfd067060c75088363ed3e19779078be2755 - https://git.kernel.org/stable/c/3229c15d6267de8e704b4085df8a82a5af2d63eb - https://git.kernel.org/stable/c/3708acbd5f169ebafe1faa519cb28adc56295546
CVE ID: CVE-2024-58007 State: PUBLISHED Published: 2025-02-27T02:12:03.593Z Last Updated: 2025-11-03T19:33:21.429Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: soc: qcom: socinfo: Avoid out of bounds read of serial number On MSM8916 devices, the serial number exposed in sysfs is constant and does not change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864 The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does not have support for the serial_num field in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not cor
eld in the socinfo struct. There is an existing check to avoid exposing the serial number in that case, but it's not correct: When checking the item_size returned by SMEM, we need to make sure the *end* of the serial_num is within bounds, instead of comparing with the *start* offset. The serial_number currently exposed on MSM8916 devices is just an out of bounds read of whatever comes after the socinfo struct in SMEM. Fix this by changing offsetof() to offsetofend(), so that the size of the field is also taken into account. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7445fa05317534bbd8b373c0eff8319187916030 - https://git.kernel.org/stable/
References: - https://git.kernel.org/stable/c/7445fa05317534bbd8b373c0eff8319187916030 - https://git.kernel.org/stable/c/2495c6598731b6d7f565140f2bd63ef4bc36ce7d - https://git.kernel.org/stable/c/2d09d3c9afa2fc422ac3df7c9b8534f350ee19dd - https://git.kernel.org/stable/c/9c88b3a3fae4d60641c3a45be66269d00eff33cd - https://git.kernel.org/stable/c/47470acd719d45c4c8c418c07962f74cc995652b - https://git.kernel.org/stable/c/407c928305c1a37232a63811c400ef616f85ccbc - https://git.kernel.org/stable/c/0a92feddae0634a0b87c04b19d343f6af97af700 - https://git.kernel.org/stable/c/22cf4fae6660b6e1a583a41cbf84e3046ca9ccd0
CVE ID: CVE-2024-58008 State: PUBLISHED Published: 2025-02-27T02:12:04.100Z Last Updated: 2025-05-04T13:01:49.877Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix improper sg use with CONFIG_VMAP_STACK=y With vmalloc stack addresses enabled (CONFIG_VMAP_STACK=y) DCP trusted keys can crash during en- and decryption of the blob encryption key via the DCP crypto driver. This is caused by improperly using sg_init_one() with vmalloc'd stack buffers (plain_key_blob). Fix this by always using kmalloc() for buffers we give to the DCP crypto driver. References: - https://git.kernel.org/stable/c/3192f1c54dddb9b5820