CVSS: 4.1EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47118 – pid: take a reference when initializing `cad_pid`
https://notcve.org/view.php?id=CVE-2021-47118
In the Linux kernel, the following vulnerability has been resolved: pid: take a reference when initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never incremented, can therefore free the init task's struct pid early. As there can be dangling references to the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to struct pid in commit 9ec52099e4b8 ("[PATCH] replace cad_pid by a struct pid") from the pre-KASAN stone age of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`. Full KASAN splat below. ================================================================== BUG: KASAN: use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950 exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270: slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff ---truncated--- En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pid: toma una referencia al inicializar `cad_pid` Durante el arranque, kernel_init_freeable() inicializa `cad_pid` en la estructura pid de la tarea de inicio. • https://git.kernel.org/stable/c/9ec52099e4b8678a60e9f93e41ad87885d64f3e6 https://git.kernel.org/stable/c/764c2e892d1fe895392aff62fb353fdce43bb529 https://git.kernel.org/stable/c/f86c80515a8a3703e0ca2e56deb50fc2879c5ea4 https://git.kernel.org/stable/c/4dbd8808a591b49b717862e6e0081bcf14a87788 https://git.kernel.org/stable/c/d106f05432e60f9f62d456ef017687f5c73cb414 https://git.kernel.org/stable/c/2cd6eedfa6344f5ef5c3dac3aee57a39b5b46dff https://git.kernel.org/stable/c/7178be006d495ffb741c329012da289b62dddfe6 https://git.kernel.org/stable/c/b8ff869f20152fbe66b6c2e2715d26a2f • CWE-416: Use After Free •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47117 – ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed
https://notcve.org/view.php?id=CVE-2021-47117
In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug on in ext4_es_cache_extent as ext4_split_extent_at failed We got follow bug_on when run fsstress with injecting IO fault: [130747.323114] kernel BUG at fs/ext4/extents_status.c:762! [130747.323117] Internal error: Oops - BUG: 0 [#1] SMP ...... [130747.334329] Call trace: [130747.334553] ext4_es_cache_extent+0x150/0x168 [ext4] [130747.334975] ext4_cache_extents+0x64/0xe8 [ext4] [130747.335368] ext4_find_extent+0x300/0x330 [ext4] [130747.335759] ext4_ext_map_blocks+0x74/0x1178 [ext4] [130747.336179] ext4_map_blocks+0x2f4/0x5f0 [ext4] [130747.336567] ext4_mpage_readpages+0x4a8/0x7a8 [ext4] [130747.336995] ext4_readpage+0x54/0x100 [ext4] [130747.337359] generic_file_buffered_read+0x410/0xae8 [130747.337767] generic_file_read_iter+0x114/0x190 [130747.338152] ext4_file_read_iter+0x5c/0x140 [ext4] [130747.338556] __vfs_read+0x11c/0x188 [130747.338851] vfs_read+0x94/0x150 [130747.339110] ksys_read+0x74/0xf0 This patch's modification is according to Jan Kara's suggestion in: https://patchwork.ozlabs.org/project/linux-ext4/patch/20210428085158.3728201-1-yebin10@huawei.com/ "I see. Now I understand your patch. Honestly, seeing how fragile is trying to fix extent tree after split has failed in the middle, I would probably go even further and make sure we fix the tree properly in case of ENOSPC and EDQUOT (those are easily user triggerable). Anything else indicates a HW problem or fs corruption so I'd rather leave the extent tree as is and don't try to fix it (which also means we will not create overlapping extents)." • https://git.kernel.org/stable/c/e33bafad30d34cfa5e9787cb099cab05e2677fcb https://git.kernel.org/stable/c/5b3a9a2be59478b013a430ac57b0f3d65471b071 https://git.kernel.org/stable/c/d8116743ef5432336289256b2f7c117299213eb9 https://git.kernel.org/stable/c/569496aa3776eea1ff0d49d0174ac1b7e861e107 https://git.kernel.org/stable/c/920697b004e49cb026e2e15fe91be065bf0741b7 https://git.kernel.org/stable/c/d3b668b96ad3192c0581a248ae2f596cd054792a https://git.kernel.org/stable/c/48105dc98c9ca35af418746277b087cb2bc6df7c https://git.kernel.org/stable/c/082cd4ec240b8734a82a89ffb890216ac •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47116 – ext4: fix memory leak in ext4_mb_init_backend on error path.
https://notcve.org/view.php?id=CVE-2021-47116
In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leak in ext4_mb_init_backend on error path. Fix a memory leak discovered by syzbot when a file system is corrupted with an illegally large s_log_groups_per_flex. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: corrige la pérdida de memoria en ext4_mb_init_backend en la ruta de error. Solucione una pérdida de memoria descubierta por syzbot cuando un sistema de archivos está dañado con un s_log_groups_per_flex ilegalmente grande. • https://git.kernel.org/stable/c/2050c6e5b161e5e25ce3c420fef58b24fa388a49 https://git.kernel.org/stable/c/04fb2baa0b147f51db065a1b13a11954abe592d0 https://git.kernel.org/stable/c/a8867f4e3809050571c98de7a2d465aff5e4daf5 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47114 – ocfs2: fix data corruption by fallocate
https://notcve.org/view.php?id=CVE-2021-47114
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix data corruption by fallocate When fallocate punches holes out of inode size, if original isize is in the middle of last cluster, then the part from isize to the end of the cluster will be zeroed with buffer write, at that time isize is not yet updated to match the new size, if writeback is kicked in, it will invoke ocfs2_writepage()->block_write_full_page() where the pages out of inode size will be dropped. That will cause file corruption. Fix this by zero out eof blocks when extending the inode size. Running the following command with qemu-image 4.2.1 can get a corrupted coverted image file easily. qemu-img convert -p -t none -T none -f qcow2 $qcow_image \ -O qcow2 -o compat=1.1 $qcow_image.conv The usage of fallocate in qemu is like this, it first punches holes out of inode size, then extend the inode size. fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0 fallocate(11, 0, 2276196352, 65536) = 0 v1: https://www.spinics.net/lists/linux-fsdevel/msg193999.html v2: https://lore.kernel.org/linux-fsdevel/20210525093034.GB4112@quack2.suse.cz/T/ En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: corrige la corrupción de datos por fallocate Cuando fallocate perfora agujeros en el tamaño del inodo, si el isize original está en el medio del último clúster, entonces la parte desde isize hasta el final del clúster se pondrá a cero con la escritura en el búfer, en ese momento isize aún no se ha actualizado para que coincida con el nuevo tamaño, si se activa la reescritura, invocará ocfs2_writepage()->block_write_full_page() donde se eliminarán las páginas fuera del tamaño del inodo. Eso causará corrupción de archivos. Solucione este problema poniendo a cero los bloques eof al extender el tamaño del inodo. • https://git.kernel.org/stable/c/624fa7baa3788dc9e57840ba5b94bc22b03cda57 https://git.kernel.org/stable/c/33e03adafb29eedae1bae9cdb50c1385279fcf65 https://git.kernel.org/stable/c/a1700479524bb9cb5e8ae720236a6fabd003acae https://git.kernel.org/stable/c/cec4e857ffaa8c447f51cd8ab4e72350077b6770 https://git.kernel.org/stable/c/cc2edb99ea606a45182b5ea38cc8f4e583aa0774 https://git.kernel.org/stable/c/c8d5faee46242c3f33b8a71a4d7d52214785bfcc https://git.kernel.org/stable/c/0a31dd6fd2f4e7db538fb6eb1f06973d81f8dd3b https://git.kernel.org/stable/c/6bba4471f0cc1296fe3c2089b9e52442d •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47113 – btrfs: abort in rename_exchange if we fail to insert the second ref
https://notcve.org/view.php?id=CVE-2021-47113
In the Linux kernel, the following vulnerability has been resolved: btrfs: abort in rename_exchange if we fail to insert the second ref Error injection stress uncovered a problem where we'd leave a dangling inode ref if we failed during a rename_exchange. This happens because we insert the inode ref for one side of the rename, and then for the other side. If this second inode ref insert fails we'll leave the first one dangling and leave a corrupt file system behind. Fix this by aborting if we did the insert for the first inode ref. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: abortar en rename_exchange si no logramos insertar la segunda referencia. • https://git.kernel.org/stable/c/0df50d47d17401f9f140dfbe752a65e5d72f9932 https://git.kernel.org/stable/c/ff8de2cec65a8c8521faade12a31b39c80e49f5b https://git.kernel.org/stable/c/dc09ef3562726cd520c8338c1640872a60187af5 •