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 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26691 – KVM: arm64: Fix circular locking dependency
https://notcve.org/view.php?id=CVE-2024-26691
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix circular locking dependency The rule inside kvm enforces that the vcpu->mutex is taken *inside* kvm->lock. The rule is violated by the pkvm_create_hyp_vm() which acquires the kvm->lock while already holding the vcpu->mutex lock from kvm_vcpu_ioctl(). Avoid the circular locking dependency altogether by protecting the hyp vm handle with the config_lock, much like we already do for other forms of VM-scoped data. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: KVM: arm64: corrige la dependencia de bloqueo circular La regla dentro de kvm exige que vcpu->mutex se tome *dentro* de kvm->lock. La regla es violada por pkvm_create_hyp_vm() que adquiere el bloqueo kvm->mientras ya mantiene el bloqueo vcpu->mutex de kvm_vcpu_ioctl(). • https://git.kernel.org/stable/c/3d16cebf01127f459dcfeb79ed77bd68b124c228 https://git.kernel.org/stable/c/3ab1c40a1e915e350d9181a4603af393141970cc https://git.kernel.org/stable/c/10c02aad111df02088d1a81792a709f6a7eca6cc •