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: 4.7EPSS: 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 https://access.redhat.com/security/cve/CVE-2024-26691 https://bugzilla.redhat.com/show_bug.cgi?id=2273098 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 6.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26690 – net: stmmac: protect updates of 64-bit statistics counters
https://notcve.org/view.php?id=CVE-2024-26690
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: protect updates of 64-bit statistics counters As explained by a comment in <linux/u64_stats_sync.h>, write side of struct u64_stats_sync must ensure mutual exclusion, or one seqcount update could be lost on 32-bit platforms, thus blocking readers forever. Such lockups have been observed in real world after stmmac_xmit() on one CPU raced with stmmac_napi_poll_tx() on another CPU. To fix the issue without introducing a new lock, split the statics into three parts: 1. fields updated only under the tx queue lock, 2. fields updated only during NAPI poll, 3. fields updated only from interrupt context, Updates to fields in the first two groups are already serialized through other locks. It is sufficient to split the existing struct u64_stats_sync so that each group has its own. Note that tx_set_ic_bit is updated from both contexts. Split this counter so that each context gets its own, and calculate their sum to get the total value in stmmac_get_ethtool_stats(). For the third group, multiple interrupts may be processed by different CPUs at the same time, but interrupts on the same CPU will not nest. Move fields from this group to a newly created per-cpu struct stmmac_pcpu_stats. • https://git.kernel.org/stable/c/133466c3bbe171f826294161db203f7670bb30c8 https://git.kernel.org/stable/c/9680b2ab54ba8d72581100e8c45471306101836e https://git.kernel.org/stable/c/e6af0f082a4b87b99ad033003be2a904a1791b3f https://git.kernel.org/stable/c/38cc3c6dcc09dc3a1800b5ec22aef643ca11eab8 •