Page 182 of 2492 results (0.015 seconds)

CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: ieee802154: fix null deref in parse dev addr Fix a logic error that could result in a null deref if the user sets the mode incorrectly for the given addr type. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: ieee802154: corrige el deref null en analizar dev addr. Se corrige un error lógico que podría resultar en un deref null si el usuario configura el modo incorrectamente para el tipo de dirección dado. • https://git.kernel.org/stable/c/1f95741981c899c4724647291fec5faa3c777185 https://git.kernel.org/stable/c/c6998ccfefa652bac3f9b236821e392af43efa1e https://git.kernel.org/stable/c/5f728ec65485625e30f46e5b4917ff023ad29ea0 https://git.kernel.org/stable/c/d0f47648b87b6d5f204cb7f3cbce6d36dab85a67 https://git.kernel.org/stable/c/c7836de2cadd88bc2f20f2c5a3d4ef4c73aef627 https://git.kernel.org/stable/c/fdd51e34f45311ab6e48d2147cbc2904731b9993 https://git.kernel.org/stable/c/9fdd04918a452980631ecc499317881c1d120b70 https://access.redhat.com/security/cve/CVE-2021-47257 • CWE-476: NULL Pointer Dereference •

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

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: 8EXPL: 0

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: 0

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: 0

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 •