CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47256 – mm/memory-failure: make sure wait for page writeback in memory_failure
https://notcve.org/view.php?id=CVE-2021-47256
In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure: make sure wait for page writeback in memory_failure Our syzkaller trigger the "BUG_ON(!list_empty(&inode->i_wb_list))" in clear_inode: kernel BUG at fs/inode.c:519! Internal error: Oops - BUG: 0 [#1] SMP Modules linked in: Process syz-executor.0 (pid: 249, stack limit = 0x00000000a12409d7) CPU: 1 PID: 249 Comm: syz-executor.0 Not tainted 4.19.95 Hardware name: linux,dummy-virt (DT) pstate: 80000005 (Nzcv daif -PAN -UAO) pc : clear_inode+0x280/0x2a8 lr : clear_inode+0x280/0x2a8 Call trace: clear_inode+0x280/0x2a8 ext4_clear_inode+0x38/0xe8 ext4_free_inode+0x130/0xc68 ext4_evict_inode+0xb20/0xcb8 evict+0x1a8/0x3c0 iput+0x344/0x460 do_unlinkat+0x260/0x410 __arm64_sys_unlinkat+0x6c/0xc0 el0_svc_common+0xdc/0x3b0 el0_svc_handler+0xf8/0x160 el0_svc+0x10/0x218 Kernel panic - not syncing: Fatal exception A crash dump of this problem show that someone called __munlock_pagevec to clear page LRU without lock_page: do_mmap -> mmap_region -> do_munmap -> munlock_vma_pages_range -> __munlock_pagevec. As a result memory_failure will call identify_page_state without wait_on_page_writeback. And after truncate_error_page clear the mapping of this page. end_page_writeback won't call sb_clear_inode_writeback to clear inode->i_wb_list. • https://git.kernel.org/stable/c/0bc1f8b0682caa39f45ce1e0228ebf43acb46111 https://git.kernel.org/stable/c/d05267fd27a5c4f54e06daefa3035995d765ca0c https://git.kernel.org/stable/c/6d210d547adc2218ef8b5bcf23518c5f2f1fd872 https://git.kernel.org/stable/c/566345aaabac853aa866f53a219c4b02a6beb527 https://git.kernel.org/stable/c/9e379da727a7a031be9b877cde7b9c34a0fb8306 https://git.kernel.org/stable/c/28788dc5c70597395b6b451dae4549bbaa8e2c56 https://git.kernel.org/stable/c/e8675d291ac007e1c636870db880f837a9ea112a •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47255 – kvm: LAPIC: Restore guard to prevent illegal APIC register access
https://notcve.org/view.php?id=CVE-2021-47255
In the Linux kernel, the following vulnerability has been resolved: kvm: LAPIC: Restore guard to prevent illegal APIC register access Per the SDM, "any access that touches bytes 4 through 15 of an APIC register may cause undefined behavior and must not be executed." Worse, such an access in kvm_lapic_reg_read can result in a leak of kernel stack contents. Prior to commit 01402cf81051 ("kvm: LAPIC: write down valid APIC registers"), such an access was explicitly disallowed. Restore the guard that was removed in that commit. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: kvm: LAPIC: Restaurar protección para evitar el acceso ilegal al registro APIC. • https://git.kernel.org/stable/c/01402cf81051f796dac7c60ca11d6147153ca46a https://git.kernel.org/stable/c/bf99ea52970caeb4583bdba1192c1f9b53b12c84 https://git.kernel.org/stable/c/018685461a5b9a9a70e664ac77aef0d7415a3fd5 https://git.kernel.org/stable/c/a2aff09807fbe4018c269d3773a629949058b210 https://git.kernel.org/stable/c/218bf772bddd221489c38dde6ef8e917131161f6 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47254 – gfs2: Fix use-after-free in gfs2_glock_shrink_scan
https://notcve.org/view.php?id=CVE-2021-47254
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix use-after-free in gfs2_glock_shrink_scan The GLF_LRU flag is checked under lru_lock in gfs2_glock_remove_from_lru() to remove the glock from the lru list in __gfs2_glock_put(). On the shrink scan path, the same flag is cleared under lru_lock but because of cond_resched_lock(&lru_lock) in gfs2_dispose_glock_lru(), progress on the put side can be made without deleting the glock from the lru list. Keep GLF_LRU across the race window opened by cond_resched_lock(&lru_lock) to ensure correct behavior on both sides - clear GLF_LRU after list_del under lru_lock. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gfs2: corrige use-after-free en gfs2_glock_shrink_scan. El indicador GLF_LRU se marca en lru_lock en gfs2_glock_remove_from_lru() para eliminar el glock de la lista lru en __gfs2_glock_put(). En la ruta de escaneo de reducción, la misma bandera se borra en lru_lock pero debido a cond_resched_lock(&lru_lock) en gfs2_dispose_glock_lru(), se puede avanzar en el lado de venta sin eliminar la glock de la lista de lru. Mantenga GLF_LRU en la ventana de ejecución abierta por cond_resched_lock(&lru_lock) para garantizar un comportamiento correcto en ambos lados; borre GLF_LRU después de list_del en lru_lock. • https://git.kernel.org/stable/c/38ce329534500bf4ae71f81df6a37a406cf187b4 https://git.kernel.org/stable/c/92869945cc5b78ee8a1ef90336fe070893e3458a https://git.kernel.org/stable/c/0364742decb0f02bc183404868b82896f7992595 https://git.kernel.org/stable/c/094bf5670e762afa243d2c41a5c4ab71c7447bf4 https://git.kernel.org/stable/c/86fd5b27db743a0ce0cc245e3a34813b2aa6ec1d https://git.kernel.org/stable/c/a61156314b66456ab6a291ed5deba1ebd002ab3c https://git.kernel.org/stable/c/e87ef30fe73e7e10d2c85bdcc778dcec24dca553 https://git.kernel.org/stable/c/1ab19c5de4c537ec0d9b21020395a5b5a •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47253 – drm/amd/display: Fix potential memory leak in DMUB hw_init
https://notcve.org/view.php?id=CVE-2021-47253
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix potential memory leak in DMUB hw_init [Why] On resume we perform DMUB hw_init which allocates memory: dm_resume->dm_dmub_hw_init->dc_dmub_srv_create->kzalloc That results in memory leak in suspend/resume scenarios. [How] Allocate memory for the DC wrapper to DMUB only if it was not allocated before. No need to reallocate it on suspend/resume. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: corrige una posible pérdida de memoria en DMUB hw_init [Por qué] Al reanudar ejecutamos DMUB hw_init que asigna memoria: dm_resume->dm_dmub_hw_init->dc_dmub_srv_create->kzalloc Eso resulta en pérdida de memoria en escenarios de suspensión/reanudación. [Cómo] Asigne memoria para el contenedor DC a DMUB solo si no se asignó antes. No es necesario reasignarlo al suspender/reanudar. • https://git.kernel.org/stable/c/9e8c2af010463197315fa54a6c17e74988b5259c https://git.kernel.org/stable/c/aa000f828e60ac15d6340f606ec4a673966f5b0b https://git.kernel.org/stable/c/c5699e2d863f58221044efdc3fa712dd32d55cde •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47252 – batman-adv: Avoid WARN_ON timing related checks
https://notcve.org/view.php?id=CVE-2021-47252
In the Linux kernel, the following vulnerability has been resolved: batman-adv: Avoid WARN_ON timing related checks The soft/batadv interface for a queued OGM can be changed during the time the OGM was queued for transmission and when the OGM is actually transmitted by the worker. But WARN_ON must be used to denote kernel bugs and not to print simple warnings. A warning can simply be printed using pr_warn. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: batman-adv: Evite comprobaciones relacionadas con el tiempo WARN_ON. La interfaz soft/batadv para un MDS en cola se puede cambiar durante el tiempo que el MDS estuvo en cola para transmisión y cuando el MDS realmente se transmite por el trabajador. Pero WARN_ON debe usarse para indicar errores del kernel y no para imprimir simples advertencias. • https://git.kernel.org/stable/c/ef0a937f7a1450d3a133ccd83c9c7d07587e7a00 https://git.kernel.org/stable/c/45011f2973f6b52cf50db397bb27bf805f5f0e7f https://git.kernel.org/stable/c/6031daaaf6d5c359c99dfffa102e332df234ff09 https://git.kernel.org/stable/c/77a99aad5bc3ea105806ebae6be3cbadc2fc615e https://git.kernel.org/stable/c/e8e9d2968a9d08bf5c683afca182f1537edebf8d https://git.kernel.org/stable/c/e7fbd8184fa9e85f0d648c499841cb7ff6dec9f4 https://git.kernel.org/stable/c/282baa8104af44e04c4af3e7f933b44267c7f86f https://git.kernel.org/stable/c/2eb4e0b3631832a4291c8bf4c9db873f6 •