CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42305 – ext4: check dot and dotdot of dx_root before making dir indexed
https://notcve.org/view.php?id=CVE-2024-42305
In the Linux kernel, the following vulnerability has been resolved: ext4: check dot and dotdot of dx_root before making dir indexed Syzbot reports a issue as follows: ============================================ BUG: unable to handle page fault for address: ffffed11022e24fe PGD 23ffee067 P4D 23ffee067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0 Call Trace: <TASK> make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [inline] ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214 [...] ============================================ The immediate cause of this problem is that there is only one valid dentry for the block to be split during do_split, so split==0 results in out of bounds accesses to the map triggering the issue. do_split unsigned split dx_make_map count = 1 split = count/2 = 0; continued = hash2 == map[split - 1].hash; ---> map[4294967295] The maximum length of a filename is 255 and the minimum block size is 1024, so it is always guaranteed that the number of entries is greater than or equal to 2 when do_split() is called. But syzbot's crafted image has no dot and dotdot in dir, and the dentry distribution in dirblock is as follows: bus dentry1 hole dentry2 free |xx--|xx-------------|...............|xx-------------|...............| 0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024 So when renaming dentry1 increases its name_len length by 1, neither hole nor free is sufficient to hold the new dentry, and make_indexed_dir() is called. In make_indexed_dir() it is assumed that the first two entries of the dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root because they are treated as dot and dotdot, and only dentry2 is moved to the new leaf block. That's why count is equal to 1. Therefore add the ext4_check_dx_root() helper function to add more sanity checks to dot and dotdot before starting the conversion to avoid the above issue. • https://git.kernel.org/stable/c/ac27a0ec112a089f1a5102bc8dffc79c8c815571 https://git.kernel.org/stable/c/b80575ffa98b5bb3a5d4d392bfe4c2e03e9557db https://git.kernel.org/stable/c/19e13b4d7f0303186fcc891aba8d0de7c8fdbda8 https://git.kernel.org/stable/c/42d420517072028fb0eb852c358056b7717ba5aa https://git.kernel.org/stable/c/8afe06ed3be7a874b3cd82ef5f8959aca8d6429a https://git.kernel.org/stable/c/abb411ac991810c0bcbe51c2e76d2502bf611b5c https://git.kernel.org/stable/c/9d241b7a39af192d1bb422714a458982c7cc67a2 https://git.kernel.org/stable/c/cdd345321699042ece4a9d2e70754d239 •
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: 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: 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 •