CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42303 – media: imx-pxp: Fix ERR_PTR dereference in pxp_probe()
https://notcve.org/view.php?id=CVE-2024-42303
In the Linux kernel, the following vulnerability has been resolved: media: imx-pxp: Fix ERR_PTR dereference in pxp_probe() devm_regmap_init_mmio() can fail, add a check and bail out in case of error. • https://git.kernel.org/stable/c/4e5bd3fdbeb3100d1f120999130afb2a7d41d82a https://git.kernel.org/stable/c/358bc85269d6a359fea597ef9fbb429cd3626e08 https://git.kernel.org/stable/c/5ab6ac4e9e165b0fe8a326308218337007224f05 https://git.kernel.org/stable/c/57e9ce68ae98551da9c161aaab12b41fe8601856 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-42302 – PCI/DPC: Fix use-after-free on concurrent DPC and hot-removal
https://notcve.org/view.php?id=CVE-2024-42302
In the Linux kernel, the following vulnerability has been resolved: PCI/DPC: Fix use-after-free on concurrent DPC and hot-removal Keith reports a use-after-free when a DPC event occurs concurrently to hot-removal of the same portion of the hierarchy: The dpc_handler() awaits readiness of the secondary bus below the Downstream Port where the DPC event occurred. To do so, it polls the config space of the first child device on the secondary bus. If that child device is concurrently removed, accesses to its struct pci_dev cause the kernel to oops. That's because pci_bridge_wait_for_secondary_bus() neglects to hold a reference on the child device. Before v6.3, the function was only called on resume from system sleep or on runtime resume. Holding a reference wasn't necessary back then because the pciehp IRQ thread could never run concurrently. • https://git.kernel.org/stable/c/d0292124bb5787a2f1ab1316509e801ca89c10fb https://git.kernel.org/stable/c/ffe2318405e605f1b3985ce188eff69e6d1d1baa https://git.kernel.org/stable/c/189f856e76f5463f59efb5fc18dcc1692d04c41a https://git.kernel.org/stable/c/53b54ad074de1896f8b021615f65b27f557ce874 https://git.kernel.org/stable/c/0081032082b5b45ca902b3c3d6986cb5cca69ff2 https://git.kernel.org/stable/c/c52f9e1a9eb40f13993142c331a6cfd334d4b91d https://git.kernel.org/stable/c/2c111413f38ca5cf87557cab89f6d82b0e3433e7 https://git.kernel.org/stable/c/f63df70b439bb8331358a306541893bf4 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42301 – dev/parport: fix the array out-of-bounds risk
https://notcve.org/view.php?id=CVE-2024-42301
In the Linux kernel, the following vulnerability has been resolved: dev/parport: fix the array out-of-bounds risk Fixed array out-of-bounds issues caused by sprintf by replacing it with snprintf for safer data copying, ensuring the destination buffer is not overflowed. Below is the stack trace I encountered during the actual issue: [ 66.575408s] [pid:5118,cpu4,QThread,4]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: do_hardware_base_addr+0xcc/0xd0 [parport] [ 66.575408s] [pid:5118,cpu4,QThread,5]CPU: 4 PID: 5118 Comm: QThread Tainted: G S W O 5.10.97-arm64-desktop #7100.57021.2 [ 66.575439s] [pid:5118,cpu4,QThread,6]TGID: 5087 Comm: EFileApp [ 66.575439s] [pid:5118,cpu4,QThread,7]Hardware name: HUAWEI HUAWEI QingYun PGUX-W515x-B081/SP1PANGUXM, BIOS 1.00.07 04/29/2024 [ 66.575439s] [pid:5118,cpu4,QThread,8]Call trace: [ 66.575469s] [pid:5118,cpu4,QThread,9] dump_backtrace+0x0/0x1c0 [ 66.575469s] [pid:5118,cpu4,QThread,0] show_stack+0x14/0x20 [ 66.575469s] [pid:5118,cpu4,QThread,1] dump_stack+0xd4/0x10c [ 66.575500s] [pid:5118,cpu4,QThread,2] panic+0x1d8/0x3bc [ 66.575500s] [pid:5118,cpu4,QThread,3] __stack_chk_fail+0x2c/0x38 [ 66.575500s] [pid:5118,cpu4,QThread,4] do_hardware_base_addr+0xcc/0xd0 [parport] • https://git.kernel.org/stable/c/166a0bddcc27de41fe13f861c8348e8e53e988c8 https://git.kernel.org/stable/c/47b3dce100778001cd76f7e9188944b5cb27a76d https://git.kernel.org/stable/c/a44f88f7576bc1916d8d6293f5c62fbe7cbe03e0 https://git.kernel.org/stable/c/c719b393374d3763e64900ee19aaed767d5a08d6 https://git.kernel.org/stable/c/7f4da759092a1a6ce35fb085182d02de8cc4cc84 https://git.kernel.org/stable/c/b579ea3516c371ecf59d073772bc45dfd28c8a0e https://git.kernel.org/stable/c/7789a1d6792af410aa9b39a1eb237ed24fa2170a https://git.kernel.org/stable/c/ab11dac93d2d568d151b1918d7b84c2d0 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42300 – erofs: fix race in z_erofs_get_gbuf()
https://notcve.org/view.php?id=CVE-2024-42300
In the Linux kernel, the following vulnerability has been resolved: erofs: fix race in z_erofs_get_gbuf() In z_erofs_get_gbuf(), the current task may be migrated to another CPU between `z_erofs_gbuf_id()` and `spin_lock(&gbuf->lock)`. Therefore, z_erofs_put_gbuf() will trigger the following issue which was found by stress test: <2>[772156.434168] kernel BUG at fs/erofs/zutil.c:58! .. <4>[772156.435007] <4>[772156.439237] CPU: 0 PID: 3078 Comm: stress Kdump: loaded Tainted: G E 6.10.0-rc7+ #2 <4>[772156.439239] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 1.0.0 01/01/2017 <4>[772156.439241] pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) <4>[772156.439243] pc : z_erofs_put_gbuf+0x64/0x70 [erofs] <4>[772156.439252] lr : z_erofs_lz4_decompress+0x600/0x6a0 [erofs] .. <6>[772156.445958] stress (3127): drop_caches: 1 <4>[772156.446120] Call trace: <4>[772156.446121] z_erofs_put_gbuf+0x64/0x70 [erofs] <4>[772156.446761] z_erofs_lz4_decompress+0x600/0x6a0 [erofs] <4>[772156.446897] z_erofs_decompress_queue+0x740/0xa10 [erofs] <4>[772156.447036] z_erofs_runqueue+0x428/0x8c0 [erofs] <4>[772156.447160] z_erofs_readahead+0x224/0x390 [erofs] .. • https://git.kernel.org/stable/c/f36f3010f67611a45d66e773bc91e4c66a9abab5 https://git.kernel.org/stable/c/49b22e06a947727a6d1c802d2d9ad92420b90fc5 https://git.kernel.org/stable/c/7dc5537c3f8be87e005f0844a7626c987914f8fd •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42299 – fs/ntfs3: Update log->page_{mask,bits} if log->page_size changed
https://notcve.org/view.php?id=CVE-2024-42299
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Update log->page_{mask,bits} if log->page_size changed If an NTFS file system is mounted to another system with different PAGE_SIZE from the original system, log->page_size will change in log_replay(), but log->page_{mask,bits} don't change correspondingly. This will cause a panic because "u32 bytes = log->page_size - page_off" will get a negative value in the later read_log_page(). • https://git.kernel.org/stable/c/b46acd6a6a627d876898e1c84d3f84902264b445 https://git.kernel.org/stable/c/0484adcb5fbcadd9ba0fd4485c42630f72e97da9 https://git.kernel.org/stable/c/b90ceffdc975502bc085ce8e79c6adeff05f9521 https://git.kernel.org/stable/c/2cac0df3324b5e287d8020bc0708f7d2dec88a6f https://git.kernel.org/stable/c/0a4ae2644e2a3b3b219aad9639fb2b0691d08420 https://git.kernel.org/stable/c/2fef55d8f78383c8e6d6d4c014b9597375132696 •