CVSS: -EPSS: 0%CPEs: 12EXPL: 0CVE-2024-42304 – ext4: make sure the first directory block is not a hole
https://notcve.org/view.php?id=CVE-2024-42304
In the Linux kernel, the following vulnerability has been resolved: ext4: make sure the first directory block is not a hole The syzbot constructs a directory that has no dirblock but is non-inline, i.e. the first directory block is a hole. And no errors are reported when creating files in this directory in the following flow. ext4_mknod ... ext4_add_entry // Read block 0 ext4_read_dirblock(dir, block, DIRENT) bh = ext4_bread(NULL, inode, block, 0) if (!bh && (type == INDEX || type == DIRENT_HTREE)) // The first directory block is a hole // But type == DIRENT, so no error is reported. After that, we get a directory block without '.' and '..' but with a valid dentry. This may cause some code that relies on dot or dotdot (such as make_indexed_dir()) to crash. Therefore when ext4_read_dirblock() finds that the first directory block is a hole report that the filesystem is corrupted and return an error to avoid loading corrupted data from disk causing something bad. • https://git.kernel.org/stable/c/3a17ca864baffc0c6f6e8aad525aa4365775a193 https://git.kernel.org/stable/c/4e19d6b65fb4fc42e352ce9883649e049da14743 https://git.kernel.org/stable/c/3f0307b0d2d8b333a6964fc4c820dc86896fd1cf https://git.kernel.org/stable/c/514631c2225c1fd556c799cc1893fb27b0f48f00 https://git.kernel.org/stable/c/7f1f86276515f6816a98f6ca3ef99c827d54642f https://git.kernel.org/stable/c/5021b7a5bdd6bb859eb648c3da71cdd6aae1d133 https://git.kernel.org/stable/c/d81d7e347d1f1f48a5634607d39eb90c161c8afe https://git.kernel.org/stable/c/e02f9941e8c011aa3eafa799def6a134c •
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: -EPSS: 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: 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 •