CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26696 – nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()
https://notcve.org/view.php?id=CVE-2024-26696
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix hang in nilfs_lookup_dirty_data_buffers() Syzbot reported a hang issue in migrate_pages_batch() called by mbind() and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2. While migrate_pages_batch() locks a folio and waits for the writeback to complete, the log writer thread that should bring the writeback to completion picks up the folio being written back in nilfs_lookup_dirty_data_buffers() that it calls for subsequent log creation and was trying to lock the folio. Thus causing a deadlock. In the first place, it is unexpected that folios/pages in the middle of writeback will be updated and become dirty. Nilfs2 adds a checksum to verify the validity of the log being written and uses it for recovery at mount, so data changes during writeback are suppressed. Since this is broken, an unclean shutdown could potentially cause recovery to fail. Investigation revealed that the root cause is that the wait for writeback completion in nilfs_page_mkwrite() is conditional, and if the backing device does not require stable writes, data may be modified without waiting. Fix these issues by making nilfs_page_mkwrite() wait for writeback to finish regardless of the stable write requirement of the backing device. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nilfs2: corrige un bloqueo en nilfs_lookup_dirty_data_buffers() Syzbot informó un problema de bloqueo en migrar_pages_batch() llamado por mbind() y nilfs_lookup_dirty_data_buffers() llamado en el escritor de registros de nilfs2. • https://git.kernel.org/stable/c/1d1d1a767206fbe5d4c69493b7e6d2a8d08cc0a0 https://git.kernel.org/stable/c/228742b2ddfb99dfd71e5a307e6088ab6836272e https://git.kernel.org/stable/c/862ee4422c38be5c249844a684b00d0dbe9d1e46 https://git.kernel.org/stable/c/98a4026b22ff440c7f47056481bcbbe442f607d6 https://git.kernel.org/stable/c/7e9b622bd0748cc104d66535b76d9b3535f9dc0f https://git.kernel.org/stable/c/8494ba2c9ea00a54d5b50e69b22c55a8958bce32 https://git.kernel.org/stable/c/ea5ddbc11613b55e5128c85f57b08f907abd9b28 https://git.kernel.org/stable/c/e38585401d464578d30f5868ff4ca5447 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26695 – crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked
https://notcve.org/view.php?id=CVE-2024-26695
In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked The SEV platform device can be shutdown with a null psp_master, e.g., using DEBUG_TEST_DRIVER_REMOVE. Found using KASAN: [ 137.148210] ccp 0000:23:00.1: enabling device (0000 -> 0002) [ 137.162647] ccp 0000:23:00.1: no command queues available [ 137.170598] ccp 0000:23:00.1: sev enabled [ 137.174645] ccp 0000:23:00.1: psp enabled [ 137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI [ 137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7] [ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311 [ 137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180 [ 137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c [ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216 [ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e [ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0 [ 137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66 [ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28 [ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8 [ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000 [ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0 [ 137.182693] Call Trace: [ 137.182693] <TASK> [ 137.182693] ? show_regs+0x6c/0x80 [ 137.182693] ? __die_body+0x24/0x70 [ 137.182693] ? die_addr+0x4b/0x80 [ 137.182693] ? • https://git.kernel.org/stable/c/87af9b0b45666ca3dd6b10c0ece691c740b0f750 https://git.kernel.org/stable/c/f831d2882c843d44100016aeb4332e9c4b560805 https://git.kernel.org/stable/c/1b05ece0c931536c0a38a9385e243a7962e933f6 https://git.kernel.org/stable/c/fcb04178c05b88a98921e262da9f7cb21cfff118 https://git.kernel.org/stable/c/d87bbd10fc01b52c814113643f2707d2d10b0319 https://git.kernel.org/stable/c/58054faf3bd29cd0b949b77efcb6157f66f401ed https://git.kernel.org/stable/c/7535ec350a5f09b5756a7607f5582913f21200f4 https://git.kernel.org/stable/c/8731fe001a60581794ed9cf65da8cd304 •
CVSS: 4.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26694 – wifi: iwlwifi: fix double-free bug
https://notcve.org/view.php?id=CVE-2024-26694
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: fix double-free bug The storage for the TLV PC register data wasn't done like all the other storage in the drv->fw area, which is cleared at the end of deallocation. Therefore, the freeing must also be done differently, explicitly NULL'ing it out after the free, since otherwise there's a nasty double-free bug here if a file fails to load after this has been parsed, and we get another free later (e.g. because no other file exists.) Fix that by adding the missing NULL assignment. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: iwlwifi: corrige el error de doble liberación El almacenamiento de los datos de registro de PC TLV no se realizó como el resto del almacenamiento en el área drv->fw, que se borra en el fin de la desasignación. Por lo tanto, la liberación también debe realizarse de manera diferente, anulándolo explícitamente después de la liberación, ya que de lo contrario hay un desagradable error de doble liberación aquí si un archivo no se carga después de haber sido analizado y obtenemos otra liberación más tarde (por ejemplo porque no existe ningún otro archivo). • https://git.kernel.org/stable/c/5e31b3df86ec6fbb925eee77fe2c450099c61dff https://git.kernel.org/stable/c/ab9d4bb9a1892439b3123fc52b19e32b9cdf80ad https://git.kernel.org/stable/c/d24eb9a27bea8fe5237fa71be274391d9d51eff2 https://git.kernel.org/stable/c/353d321f63f7dbfc9ef58498cc732c9fe886a596 https://access.redhat.com/security/cve/CVE-2024-26694 https://bugzilla.redhat.com/show_bug.cgi?id=2273092 • CWE-415: Double Free •
CVSS: 4.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26693 – wifi: iwlwifi: mvm: fix a crash when we run out of stations
https://notcve.org/view.php?id=CVE-2024-26693
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix a crash when we run out of stations A DoS tool that injects loads of authentication frames made our AP crash. The iwl_mvm_is_dup() function couldn't find the per-queue dup_data which was not allocated. The root cause for that is that we ran out of stations in the firmware and we didn't really add the station to the firmware, yet we didn't return an error to mac80211. Mac80211 was thinking that we have the station and because of that, sta_info::uploaded was set to 1. This allowed ieee80211_find_sta_by_ifaddr() to return a valid station object, but that ieee80211_sta didn't have any iwl_mvm_sta object initialized and that caused the crash mentioned earlier when we got Rx on that station. En el kernel de Linux se ha solucionado la siguiente vulnerabilidad: wifi: iwlwifi: mvm: soluciona un fallo cuando nos quedamos sin estaciones Una herramienta DoS que inyecta un montón de marcos de autenticación hacía que nuestro AP fallara. La función iwl_mvm_is_dup() no pudo encontrar los datos dup_data por cola que no estaban asignados. • https://git.kernel.org/stable/c/57974a55d995468a9a476e24693eb741c649b25f https://git.kernel.org/stable/c/00f4eb31b8193f6070ce24df636883f9c104ca95 https://git.kernel.org/stable/c/c12f0f4d4caf23b1bfdc2602b6b70d56bdcd6aa7 https://git.kernel.org/stable/c/b7198383ef2debe748118996f627452281cf27d7 https://access.redhat.com/security/cve/CVE-2024-26693 https://bugzilla.redhat.com/show_bug.cgi?id=2273094 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26692 – smb: Fix regression in writes when non-standard maximum write size negotiated
https://notcve.org/view.php?id=CVE-2024-26692
In the Linux kernel, the following vulnerability has been resolved: smb: Fix regression in writes when non-standard maximum write size negotiated The conversion to netfs in the 6.3 kernel caused a regression when maximum write size is set by the server to an unexpected value which is not a multiple of 4096 (similarly if the user overrides the maximum write size by setting mount parm "wsize", but sets it to a value that is not a multiple of 4096). When negotiated write size is not a multiple of 4096 the netfs code can skip the end of the final page when doing large sequential writes, causing data corruption. This section of code is being rewritten/removed due to a large netfs change, but until that point (ie for the 6.3 kernel until now) we can not support non-standard maximum write sizes. Add a warning if a user specifies a wsize on mount that is not a multiple of 4096 (and round down), also add a change where we round down the maximum write size if the server negotiates a value that is not a multiple of 4096 (we also have to check to make sure that we do not round it down to zero). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: smb: se corrigió la regresión en las escrituras cuando se negoció un tamaño de escritura máximo no estándar. La conversión a netfs en el kernel 6.3 provocó una regresión cuando el servidor estableció el tamaño de escritura máximo en un valor inesperado. que no es un múltiplo de 4096 (de manera similar, si el usuario anula el tamaño máximo de escritura configurando el parámetro de montaje "wsize", pero lo establece en un valor que no es un múltiplo de 4096). Cuando el tamaño de escritura negociado no es un múltiplo de 4096, el código netfs puede omitir el final de la página final al realizar escrituras secuenciales grandes, lo que provoca corrupción de datos. • https://git.kernel.org/stable/c/d08089f649a0cfb2099c8551ac47eef0cc23fdf2 https://git.kernel.org/stable/c/4145ccff546ea868428b3e0fe6818c6261b574a9 https://git.kernel.org/stable/c/63c35afd50e28b49c5b75542045a8c42b696dab9 https://git.kernel.org/stable/c/4860abb91f3d7fbaf8147d54782149bb1fc45892 •