Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
5332 is not affected as it is not PCIe based device. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 References: - https://git.kernel.org/stable/c/569972c5bdb839b0eaf8aba6ce76ea0b78e2acf8 - https://git.kernel.org/stable/c/d71ac5694b33c80f1de97d074f6fbdc6c01a9d61 - https://git.kernel.org/stable/c/7588a893cde5385ad308400ff167d29a29913b3a
CVE ID: CVE-2025-38415 State: PUBLISHED Published: 2025-07-25T13:32:09.711Z Last Updated: 2025-11-03T17:37:45.927Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Squashfs: check return result of sb_min_blocksize Syzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug. Syzkaller forks multiple processes which after mounting the Squashfs filesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in the process of mounting a Squashfs filesystem on /dev/loop0, the failure occurs. When this happens the following code in squashfs_fill_super()
g a Squashfs filesystem on /dev/loop0, the failure occurs. When this happens the following code in squashfs_fill_super() fails. ---- msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE); msblk->devblksize_log2 = ffz(~msblk->devblksize); ---- sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0. As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2 is set to 64. This subsequently causes the UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') This commit adds a check for a 0 return by sb_min_blocksize(). Additional Analyst Notes: - CVE Program Container: Refer
This commit adds a check for a 0 return by sb_min_blocksize(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/db7096ea160e40d78c67fce52e7cc51bde049497 - https://git.kernel.org/stable/c/549f9e3d7b60d53808c98b9fde49b4f46d0524a5 - https://git.kernel.org/stable/c/5c51aa862cbeed2f3887f0382a2708956710bd68 - https://git.kernel.org/stable/c/6abf6b78c6fb112eee495f5636ffcc350dd2ce25 - https://git.kernel.org/stable/c/4f99357dadbf9c979ad737156ad4c37fadf7c56b - https://git.kernel.org/stable/c/0aff95d9bc7fb5400ca8af507429c4b067bdb425 - https://git.kernel.org/stable/c/295ab18c2dbce8d0ac6ecf7c5187e16e1ac8b282 - https://git.kernel.org/stable/c/734aa85390ea69
ttps://git.kernel.org/stable/c/295ab18c2dbce8d0ac6ecf7c5187e16e1ac8b282 - https://git.kernel.org/stable/c/734aa85390ea693bb7eaf2240623d41b03705c84
CVE ID: CVE-2025-38416 State: PUBLISHED Published: 2025-07-25T14:00:17.849Z Last Updated: 2025-11-03T17:37:47.815Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: NFC: nci: uart: Set tty->disc_data only in success path Setting tty->disc_data before opening the NCI device means we need to clean it up on error paths. This also opens some short window if device starts sending data, even before NCIUARTSETDRIVER IOCTL succeeded (broken hardware?). Close the window by exposing tty->disc_data only on the success path, when opening of the NCI device and try_module_get() succeeds. The code differs in error path in one aspect: tty->disc_d
when opening of the NCI device and try_module_get() succeeds. The code differs in error path in one aspect: tty->disc_data won't be ever assigned thus NULL-ified. This however should not be relevant difference, because of "tty->disc_data=NULL" in nci_uart_tty_open(). Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a514fca2b8e95838a3ba600f31a18fa60b76d893 - https://git.kernel.org/stable/c/000bfbc6bc334a93fffca8f5aa9583e7b6356cb5 - https://git.kernel.org/stable/c/ac6992f72bd8e22679c1e147ac214de6a7093c23 - https://git.kernel.org/stable/c/dc7722619a9c307e9938d735cf4a2210d3d48dcb - https://git.kernel.org/stable/c/a8acc7080ad55c5402a1b818b300899824
g/stable/c/dc7722619a9c307e9938d735cf4a2210d3d48dcb - https://git.kernel.org/stable/c/a8acc7080ad55c5402a1b818b3008998247dda87 - https://git.kernel.org/stable/c/55c3dbd8389636161090a2b2b6d2d709b9602e9c - https://git.kernel.org/stable/c/e9799db771b2d574d5bf0dfb3177485e5f40d4d6 - https://git.kernel.org/stable/c/fc27ab48904ceb7e4792f0c400f1ef175edf16fe
CVE ID: CVE-2025-38417 State: PUBLISHED Published: 2025-07-25T14:05:41.821Z Last Updated: 2025-07-28T04:21:37.186Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ice: fix eswitch code memory leak in reset scenario Add simple eswitch mode checker in attaching VF procedure and allocate required port representor memory structures only in switchdev mode. The reset flows triggers VF (if present) detach/attach procedure. It might involve VF port representor(s) re-creation if the device is configured is switchdev mode (not legacy one). The memory was blindly allocated in current implementation, regardless of the mode and not freed if
e (not legacy one). The memory was blindly allocated in current implementation, regardless of the mode and not freed if in legacy mode. Kmemeleak trace: unreferenced object (percpu) 0x7e3bce5b888458 (size 40): comm "bash", pid 1784, jiffies 4295743894 hex dump (first 32 bytes on cpu 45): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): pcpu_alloc_noprof+0x4c4/0x7c0 ice_repr_create+0x66/0x130 [ice] ice_repr_create_vf+0x22/0x70 [ice] ice_eswitch_attach_vf+0x1b/0xa0 [ice] ice_reset_all_vfs+0x1dd/0x2f0 [ice] ice_pci_err_resume+0x3b/0xb0 [ice] pci_reset_function+0x8f/0x120 reset_store+0x56/0xa0 ker
set_all_vfs+0x1dd/0x2f0 [ice] ice_pci_err_resume+0x3b/0xb0 [ice] pci_reset_function+0x8f/0x120 reset_store+0x56/0xa0 kernfs_fop_write_iter+0x120/0x1b0 vfs_write+0x31c/0x430 ksys_write+0x61/0xd0 do_syscall_64+0x5b/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e Testing hints (ethX is PF netdev): - create at least one VF echo 1 > /sys/class/net/ethX/device/sriov_numvfs - trigger the reset echo 1 > /sys/class/net/ethX/device/reset References: - https://git.kernel.org/stable/c/d6715193de439b79f1d6a4c03593c7529239b545 - https://git.kernel.org/stable/c/e97a7a051b55f55f276c1568491d0ed7f890ee94 - https://git.kernel.org/stable/c/48c8b214974dc55283bd5f12e3a483b27c403bbc
CVE ID: CVE-2025-38418 State: PUBLISHED Published: 2025-07-25T14:05:42.836Z Last Updated: 2025-11-03T17:37:48.750Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: remoteproc: core: Release rproc->clean_table after rproc_attach() fails When rproc->state = RPROC_DETACHED is attached to remote processor through rproc_attach(), if rproc_handle_resources() returns failure, then the clean table should be released, otherwise the following memory leak will occur. unreferenced object 0xffff000086a99800 (size 1024): comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s) hex dump (first 32 bytes): 00 00 00 00 00 80 00 00 00 00 00
"kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s) hex dump (first 32 bytes): 00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............ 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............ backtrace: [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230 [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260 [<0000000037818dae>] kmemdup+0x34/0x60 [<00000000610f7f57>] rproc_boot+0x35c/0x56c [<0000000065f8871a>] rproc_add+0x124/0x17c [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4 [<000000003bcaa37d>] platform_probe+0x68/0xd8 [<00000000771577f9>] really_probe+0x110/0x27c [<00000000531fea59>] __driver_probe_device+
37d>] platform_probe+0x68/0xd8 [<00000000771577f9>] really_probe+0x110/0x27c [<00000000531fea59>] __driver_probe_device+0x78/0x12c [<0000000080036a04>] driver_probe_device+0x3c/0x118 [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8 [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4 [<000000001a53b53e>] __device_attach+0xfc/0x18c [<00000000d1a2a32c>] device_initial_probe+0x14/0x20 [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4 unreferenced object 0xffff0000864c9690 (size 16): Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/3562c09feeb8d8e9d102ce6840e8c7d57a7feb5c - https://git.kernel.org/stable/c/bf876fd9dc2d0c9fff96aef63d4346719f206fc1 - ht
3562c09feeb8d8e9d102ce6840e8c7d57a7feb5c - https://git.kernel.org/stable/c/bf876fd9dc2d0c9fff96aef63d4346719f206fc1 - https://git.kernel.org/stable/c/3ee979709e16a83b257bc9a544a7ff71fd445ea9 - https://git.kernel.org/stable/c/f4ef928ca504c996f9222eb2c59ac6d6eefd9c75 - https://git.kernel.org/stable/c/6fe9486d709e4a60990843832501ef6556440ca7 - https://git.kernel.org/stable/c/bcd241230fdbc6005230f80a4f8646ff5a84f15b
CVE ID: CVE-2025-38419 State: PUBLISHED Published: 2025-07-25T14:05:43.741Z Last Updated: 2025-11-03T17:37:49.707Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach() When rproc->state = RPROC_DETACHED and rproc_attach() is used to attach to the remote processor, if rproc_handle_resources() returns a failure, the resources allocated by imx_rproc_prepare() should be released, otherwise the following memory leak will occur. Since almost the same thing is done in imx_rproc_prepare() and rproc_resource_cleanup(), Function rproc_resource_cl
cur. Since almost the same thing is done in imx_rproc_prepare() and rproc_resource_cleanup(), Function rproc_resource_cleanup() is able to deal with empty lists so it is better to fix the "goto" statements in rproc_attach(). replace the "unprepare_device" goto statement with "clean_up_resources" and get rid of the "unprepare_device" label. unreferenced object 0xffff0000861c5d00 (size 128): comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............ backtrace: [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c [<00000000adbfb3e7>] __kmem_c
0 00 00 00 00 ............ backtrace: [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c [<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0 [<00000000521c0345>] kmalloc_trace+0x40/0x158 [<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8 [<000000002815755e>] imx_rproc_prepare+0xe0/0x180 [<0000000003f61b4e>] rproc_boot+0x2ec/0x528 [<00000000e7e994ac>] rproc_add+0x124/0x17c [<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4 [<00000000efc298a1>] platform_probe+0x68/0xd8 [<00000000110be6fe>] really_probe+0x110/0x27c [<00000000e245c0ae>] __driver_probe_device+0x78/0x12c [<00000000f61f6f5e>] driver_probe_device+0x3c/0x118 [<00000000a7874938>] __device_attach_driver+0xb8/0xf8 [<0000000065319e
00000000f61f6f5e>] driver_probe_device+0x3c/0x118 [<00000000a7874938>] __device_attach_driver+0xb8/0xf8 [<0000000065319e69>] bus_for_each_drv+0x84/0xe4 [<00000000db3eb243>] __device_attach+0xfc/0x18c [<0000000072e4e1a4>] device_initial_probe+0x14/0x20 Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c56d6ef2711ee51b54f160ad0f25a381561f0287 - https://git.kernel.org/stable/c/82208ce9505abb057afdece7c62a14687c52c9ca - https://git.kernel.org/stable/c/9515d74c9d1ae7308a02e8bd4f894eb8137cf8df - https://git.kernel.org/stable/c/92776ca0ccfe78b9bfe847af206bad641fb11121 - https://git.kernel.org/stable/c/5434d9f2fd68722b514c14b417b53a8af02c4d24 - https://
a0ccfe78b9bfe847af206bad641fb11121 - https://git.kernel.org/stable/c/5434d9f2fd68722b514c14b417b53a8af02c4d24 - https://git.kernel.org/stable/c/7692c9fbedd9087dc9050903f58095915458d9b1
CVE ID: CVE-2025-38420 State: PUBLISHED Published: 2025-07-25T14:16:41.479Z Last Updated: 2025-11-03T17:37:51.577Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: do not ping device which has failed to load firmware Syzkaller reports [1, 2] crashes caused by an attempts to ping the device which has failed to load firmware. Since such a device doesn't pass 'ieee80211_register_hw()', an internal workqueue managed by 'ieee80211_queue_work()' is not yet created and an attempt to queue work on it causes null-ptr-deref. [1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff [2] https://syzkaller.appspot.com/b
ses null-ptr-deref. [1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff [2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217 Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/0140d3d37f0f1759d1fdedd854c7875a86e15f8d - https://git.kernel.org/stable/c/8a3734a6f4c05fd24605148f21fb2066690d61b3 - https://git.kernel.org/stable/c/527fad1ae32ffa2d4853a1425fe1c8dbb8c9744c - https://git.kernel.org/stable/c/bfeede26e97ce4a15a0b961118de4a0e28c9907a - https://git.kernel.org/stable/c/4e9ab5c48ad5153cc908dd29abad0cd2a92951e4 - https://git.kernel.org/stable/c/301268dbaac8e9013719e162a000202eac8054be - https://git.kernel.org/stable/c/11e
92951e4 - https://git.kernel.org/stable/c/301268dbaac8e9013719e162a000202eac8054be - https://git.kernel.org/stable/c/11ef72b3312752c2ff92f3c1e64912be3228ed36 - https://git.kernel.org/stable/c/15d25307692312cec4b57052da73387f91a2e870
CVE ID: CVE-2025-38421 State: PUBLISHED Published: 2025-07-25T14:16:42.409Z Last Updated: 2025-07-28T04:21:43.366Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd: pmf: Use device managed allocations If setting up smart PC fails for any reason then this can lead to a double free when unloading amd-pmf. This is because dev->buf was freed but never set to NULL and is again freed in amd_pmf_remove(). To avoid subtle allocation bugs in failures leading to a double free change all allocations into device managed allocations. References: - https://git.kernel.org/stable/c/0d10b532f861253c283863522d59d099fcb0796d - http
evice managed allocations. References: - https://git.kernel.org/stable/c/0d10b532f861253c283863522d59d099fcb0796d - https://git.kernel.org/stable/c/d9db3a941270d92bbd1a6a6b54a10324484f2f2d
CVE ID: CVE-2025-38422 State: PUBLISHED Published: 2025-07-25T14:16:43.109Z Last Updated: 2025-11-03T17:37:52.511Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devices Maximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kb and 64 Kb respectively. Adjust max size definitions and return correct EEPROM length based on device. Also prevent out-of-bound read/write. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/6b4201d74d0a49af2123abf2c9d142e59566714b - https://git.kernel.org/stable/c/088279ff18cdc437d6fac5890
kernel.org/stable/c/6b4201d74d0a49af2123abf2c9d142e59566714b - https://git.kernel.org/stable/c/088279ff18cdc437d6fac5890e0c52c624f78a5b - https://git.kernel.org/stable/c/51318d644c993b3f7a60b8616a6a5adc1e967cd2 - https://git.kernel.org/stable/c/9c41d2a2aa3817946eb613522200cab55513ddaa - https://git.kernel.org/stable/c/3b9935586a9b54d2da27901b830d3cf46ad66a1e
CVE ID: CVE-2025-38423 State: PUBLISHED Published: 2025-07-25T14:16:43.940Z Last Updated: 2025-07-28T04:21:46.347Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd9375: Fix double free of regulator supplies Driver gets regulator supplies in probe path with devm_regulator_bulk_get(), so should not call regulator_bulk_free() in error and remove paths to avoid double free. References: - https://git.kernel.org/stable/c/c8228b5f3d74fd8ad4dfc79d5d601eb6fca5e63e - https://git.kernel.org/stable/c/ce30258c05d39b62a05c99016d7148b3bf60fbdc - https://git.kernel.org/stable/c/63fe298652d4eda07d738bfcbbc59d1343a675ef
CVE ID: CVE-2025-38424 State: PUBLISHED Published: 2025-07-25T14:16:44.846Z Last Updated: 2025-11-03T17:37:54.380Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: perf: Fix sample vs do_exit() Baisheng Gao reported an ARM64 crash, which Mark decoded as being a synchronous external abort -- most likely due to trying to access MMIO in bad ways. The crash further shows perf trying to do a user stack sample while in exit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the address space it is trying to access. It turns out that we stop perf after we tear down the userspace mm; a receipie for disaster, since perf likes to access
It turns out that we stop perf after we tear down the userspace mm; a receipie for disaster, since perf likes to access userspace for various reasons. Flip this order by moving up where we stop perf in do_exit(). Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER to abort when the current task does not have an mm (exit_mm() makes sure to set current->mm = NULL; before commencing with the actual teardown). Such that CPU wide events don't trip on this same problem. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/7b8f3c72175c6a63a95cf2e219f8b78e2baad34e - https://git.kernel.org/stable/c/507c9a595bad3abd107c6a8857d7fd125d89f386
e/c/7b8f3c72175c6a63a95cf2e219f8b78e2baad34e - https://git.kernel.org/stable/c/507c9a595bad3abd107c6a8857d7fd125d89f386 - https://git.kernel.org/stable/c/a9f6aab7910a0ef2895797f15c947f6d1053160f - https://git.kernel.org/stable/c/975ffddfa2e19823c719459d2364fcaa17673964 - https://git.kernel.org/stable/c/2ee6044a693735396bb47eeaba1ac3ae26c1c99b - https://git.kernel.org/stable/c/456019adaa2f5366b89c868dea9b483179bece54 - https://git.kernel.org/stable/c/7311970d07c4606362081250da95f2c7901fc0db - https://git.kernel.org/stable/c/4f6fc782128355931527cefe3eb45338abd8ab39
CVE ID: CVE-2025-38425 State: PUBLISHED Published: 2025-07-25T14:16:45.661Z Last Updated: 2025-11-03T17:37:55.331Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: i2c: tegra: check msg length in SMBUS block read For SMBUS block read, do not continue to read if the message length passed from the device is '0' or greater than the maximum allowed bytes. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c39d1a9ae4ad66afcecab124d7789722bfe909fa - https://git.kernel.org/stable/c/be5f6a65509cd5675362f15eb0440fb28b0f9d64 - https://git.kernel.org/stable/c/75a864f21ceeb8c1e8ce1b7589174fec2c3a
stable/c/be5f6a65509cd5675362f15eb0440fb28b0f9d64 - https://git.kernel.org/stable/c/75a864f21ceeb8c1e8ce1b7589174fec2c3a039e - https://git.kernel.org/stable/c/3f03f77ce688d02da284174e1884b6065d6159bd - https://git.kernel.org/stable/c/a6e04f05ce0b070ab39d5775580e65c7d943da0b
CVE ID: CVE-2025-38426 State: PUBLISHED Published: 2025-07-25T14:16:46.482Z Last Updated: 2025-07-28T11:16:57.653Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Add basic validation for RAS header If RAS header read from EEPROM is corrupted, it could result in trying to allocate huge memory for reading the records. Add some validation to header fields. References: - https://git.kernel.org/stable/c/b52f52bc5ba9feb026c0be600f8ac584fd12d187 - https://git.kernel.org/stable/c/5df0d6addb7e9b6f71f7162d1253762a5be9138e
CVE ID: CVE-2025-38427 State: PUBLISHED Published: 2025-07-25T14:16:47.305Z Last Updated: 2025-07-28T04:21:52.177Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: video: screen_info: Relocate framebuffers behind PCI bridges Apply PCI host-bridge window offsets to screen_info framebuffers. Fixes invalid access to I/O memory. Resources behind a PCI host bridge can be relocated by a certain offset in the kernel's CPU address range used for I/O. The framebuffer memory range stored in screen_info refers to the CPU addresses as seen during boot (where the offset is 0). During boot up, firmware may assign a different memory offset to t
ddresses as seen during boot (where the offset is 0). During boot up, firmware may assign a different memory offset to the PCI host bridge and thereby relocating the framebuffer address of the PCI graphics device as seen by the kernel. The information in screen_info must be updated as well. The helper pcibios_bus_to_resource() performs the relocation of the screen_info's framebuffer resource (given in PCI bus addresses). The result matches the I/O-memory resource of the PCI graphics device (given in CPU addresses). As before, we store away the information necessary to later update the information in screen_info itself. Commit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated EF
update the information in screen_info itself. Commit 78aa89d1dfba ("firmware/sysfb: Update screen_info for relocated EFI framebuffers") added the code for updating screen_info. It is based on similar functionality that pre-existed in efifb. Efifb uses a pointer to the PCI resource, while the newer code does a memcpy of the region. Hence efifb sees any updates to the PCI resource and avoids the issue. v3: - Only use struct pci_bus_region for PCI bus addresses (Bjorn) - Clarify address semantics in commit messages and comments (Bjorn) v2: - Fixed tags (Takashi, Ivan) - Updated information on efifb References: - https://git.kernel.org/stable/c/cc3cc41ed67054a03134bea42408c720eec0fa04 - https:/
ed information on efifb References: - https://git.kernel.org/stable/c/cc3cc41ed67054a03134bea42408c720eec0fa04 - https://git.kernel.org/stable/c/5c70e3ad85d2890d8af375333699429de26327f2 - https://git.kernel.org/stable/c/aeda386d86d79269a08f470dbdc53d13a91e51fa - https://git.kernel.org/stable/c/2f29b5c231011b94007d2c8a6d793992f2275db1
CVE ID: CVE-2025-38428 State: PUBLISHED Published: 2025-07-25T14:16:48.019Z Last Updated: 2025-11-03T17:37:57.365Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - check record size in ims_pcu_flash_firmware() The "len" variable comes from the firmware and we generally do trust firmware, but it's always better to double check. If the "len" is too large it could result in memory corruption when we do "memcpy(fragment->data, rec->data, len);" Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/c1b9d140b0807c6aee4bb53e1bfa4e391e3dc204 - https://git.kernel.org/stable/c/d63
rences: - https://git.kernel.org/stable/c/c1b9d140b0807c6aee4bb53e1bfa4e391e3dc204 - https://git.kernel.org/stable/c/d63706d9f73846106fde28b284f08e01b92ce9f1 - https://git.kernel.org/stable/c/e5a2481dc2a0b430f49276d7482793a8923631d6 - https://git.kernel.org/stable/c/8e03f1c7d50343bf21da54873301bc4fa647479f - https://git.kernel.org/stable/c/17474a56acf708bf6b2d174c06ed26abad0a9fd6 - https://git.kernel.org/stable/c/5a8cd6ae8393e2eaebf51d420d5374821ef2af87 - https://git.kernel.org/stable/c/74661516daee1eadebede8dc607b6830530096ec - https://git.kernel.org/stable/c/a95ef0199e80f3384eb992889322957d26c00102
CVE ID: CVE-2025-38429 State: PUBLISHED Published: 2025-07-25T14:16:48.698Z Last Updated: 2025-07-28T04:21:55.358Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bus: mhi: ep: Update read pointer only after buffer is written Inside mhi_ep_ring_add_element, the read pointer (rd_offset) is updated before the buffer is written, potentially causing race conditions where the host sees an updated read pointer before the buffer is actually written. Updating rd_offset prematurely can lead to the host accessing an uninitialized or incomplete element, resulting in data corruption. Invoke the buffer write before updating rd_offset to ensu