CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47122 – net: caif: fix memory leak in caif_device_notify
https://notcve.org/view.php?id=CVE-2021-47122
In the Linux kernel, the following vulnerability has been resolved: net: caif: fix memory leak in caif_device_notify In case of caif_enroll_dev() fail, allocated link_support won't be assigned to the corresponding structure. So simply free allocated pointer in case of error En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: caif: corrige la pérdida de memoria en caif_device_notify En caso de que falle caif_enroll_dev(), el link_support asignado no se asignará a la estructura correspondiente. Así que simplemente libera el puntero asignado en caso de error. • https://git.kernel.org/stable/c/7c18d2205ea76eef9674e59e1ecae4f332a53e9e https://git.kernel.org/stable/c/b042e2b2039565eb8f0eb51c14fbe1ef463c8cd8 https://git.kernel.org/stable/c/9348c1f10932f13b299cbc8b1bd5f780751fae49 https://git.kernel.org/stable/c/4bca2034b41c15b62d47a19158bb76235fd4455d https://git.kernel.org/stable/c/3be863c11cab725add9fef4237ed4e232c3fc3bb https://git.kernel.org/stable/c/f52f4fd67264c70cd0b4ba326962ebe12d9cba94 https://git.kernel.org/stable/c/af2806345a37313f01b1c9f15e046745b8ee2daa https://git.kernel.org/stable/c/6a0e317f61094d377335547e015dd2ff1 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47121 – net: caif: fix memory leak in cfusbl_device_notify
https://notcve.org/view.php?id=CVE-2021-47121
In the Linux kernel, the following vulnerability has been resolved: net: caif: fix memory leak in cfusbl_device_notify In case of caif_enroll_dev() fail, allocated link_support won't be assigned to the corresponding structure. So simply free allocated pointer in case of error. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: caif: corrige la pérdida de memoria en cfusbl_device_notify En caso de que falle caif_enroll_dev(), el link_support asignado no se asignará a la estructura correspondiente. Así que simplemente libera el puntero asignado en caso de error. • https://git.kernel.org/stable/c/7ad65bf68d705b445ef10b77ab50dab22be185ee https://git.kernel.org/stable/c/cc302e30a504e6b60a9ac8df7988646f46cd0294 https://git.kernel.org/stable/c/81afc61cb6e2b553f2c5f992fa79e0ae73857141 https://git.kernel.org/stable/c/e8b37f5009ea7095529790f022859711e6939c76 https://git.kernel.org/stable/c/9ea0ab48e755d8f29fe89eb235fb86176fdb597f https://git.kernel.org/stable/c/4d94f530cd24c85aede6e72b8923f371b45d6886 https://git.kernel.org/stable/c/46403c1f80b0d3f937ff9c4f5edc63bb64bc5051 https://git.kernel.org/stable/c/dde8686985ec24d6b00487080a906609b •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47119 – ext4: fix memory leak in ext4_fill_super
https://notcve.org/view.php?id=CVE-2021-47119
In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leak in ext4_fill_super Buffer head references must be released before calling kill_bdev(); otherwise the buffer head (and its page referenced by b_data) will not be freed by kill_bdev, and subsequently that bh will be leaked. If blocksizes differ, sb_set_blocksize() will kill current buffers and page cache by using kill_bdev(). And then super block will be reread again but using correct blocksize this time. sb_set_blocksize() didn't fully free superblock page and buffer head, and being busy, they were not freed and instead leaked. This can easily be reproduced by calling an infinite loop of: systemctl start <ext4_on_lvm>.mount, and systemctl stop <ext4_on_lvm>.mount ... since systemd creates a cgroup for each slice which it mounts, and the bh leak get amplified by a dying memory cgroup that also never gets freed, and memory consumption is much more easily noticed. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: corrige la pérdida de memoria en ext4_fill_super Las referencias del encabezado del búfer deben liberarse antes de llamar a kill_bdev(); de lo contrario, kill_bdev no liberará el encabezado del búfer (y su página a la que hace referencia b_data) y, posteriormente, se filtrará ese bh. Si los tamaños de los bloques difieren, sb_set_blocksize() eliminará los búferes actuales y el caché de la página usando kill_bdev(). Y luego el superbloque se volverá a leer, pero esta vez utilizando el tamaño de bloque correcto. sb_set_blocksize() no liberó completamente la página del superbloque y el encabezado del búfer y, al estar ocupados, no se liberaron y en su lugar se filtraron. • https://git.kernel.org/stable/c/ac27a0ec112a089f1a5102bc8dffc79c8c815571 https://git.kernel.org/stable/c/01d349a481f0591230300a9171330136f9159bcd https://git.kernel.org/stable/c/1385b23396d511d5233b8b921ac3058b3f86a5e1 https://git.kernel.org/stable/c/afd09b617db3786b6ef3dc43e28fe728cfea84df •
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 •