CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42309 – drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes
https://notcve.org/view.php?id=CVE-2024-42309
In the Linux kernel, the following vulnerability has been resolved: drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes In psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. • https://git.kernel.org/stable/c/89c78134cc54dff016c83367912eb055637fa50c https://git.kernel.org/stable/c/13b5f3ee94bdbdc4b5f40582aab62977905aedee https://git.kernel.org/stable/c/d6ad202f73f8edba0cbc0065aa57a79ffe8fdcdc https://git.kernel.org/stable/c/6735d02ead7dd3adf74eb8b70aebd09e0ce78ec9 https://git.kernel.org/stable/c/7e52c62ff029f95005915c0a11863b5fb5185c8c https://git.kernel.org/stable/c/f70ffeca546452d1acd3a70ada56ecb2f3e7f811 https://git.kernel.org/stable/c/46d2ef272957879cbe30a884574320e7f7d78692 https://git.kernel.org/stable/c/475a5b3b7c8edf6e583a9eb59cf28ea77 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-42306 – udf: Avoid using corrupted block bitmap buffer
https://notcve.org/view.php?id=CVE-2024-42306
In the Linux kernel, the following vulnerability has been resolved: udf: Avoid using corrupted block bitmap buffer When the filesystem block bitmap is corrupted, we detect the corruption while loading the bitmap and fail the allocation with error. However the next allocation from the same bitmap will notice the bitmap buffer is already loaded and tries to allocate from the bitmap with mixed results (depending on the exact nature of the bitmap corruption). Fix the problem by using BH_verified bit to indicate whether the bitmap is valid or not. • https://git.kernel.org/stable/c/7648ea9896b31aff38830d81188f5b7a1773e4a8 https://git.kernel.org/stable/c/4ac54312f623c6d2ca30c36c1ef530c11f5aff64 https://git.kernel.org/stable/c/099bf90d7fc4622da9fd4727f6d318a0f12d10be https://git.kernel.org/stable/c/6ac8f2c8362afd2baa8e7b9c946597589e587d22 https://git.kernel.org/stable/c/1e0d4adf17e7ef03281d7b16555e7c1508c8ed2d https://git.kernel.org/stable/c/f862a9049c3f6e73a5504a1ac10ffd5bc253ab55 https://git.kernel.org/stable/c/4622cc1b6d86013e01c56b60b092b5e4726c8e52 https://git.kernel.org/stable/c/cae9e59cc41683408b70b9ab569f86548 •
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: 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 •