Page 303 of 2294 results (0.017 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: efi: fix panic in kdump kernel Check if get_next_variable() is actually valid pointer before calling it. In kdump kernel this method is set to NULL that causes panic during the kexec-ed kernel boot. Tested with QEMU and OVMF firmware. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: efi: arreglado el pánico en el kernel kdump. Compruebe si get_next_variable() es realmente un puntero válido antes de llamarlo. En el kernel kdump, este método está configurado en NULL, lo que provoca pánico durante el arranque del kernel kexec-ed. • https://git.kernel.org/stable/c/a8901f331b8b7f95a7315d033a22bc84c8365f35 https://git.kernel.org/stable/c/bad267f9e18f8e9e628abd1811d2899b1735a4e1 https://git.kernel.org/stable/c/b9d103aca85f082a343b222493f3cab1219aaaf4 https://git.kernel.org/stable/c/9114ba9987506bcfbb454f6e68558d68cb1abbde https://git.kernel.org/stable/c/7784135f134c13af17d9ffb39a57db8500bc60ff https://git.kernel.org/stable/c/090d2b4515ade379cd592fbc8931344945978210 https://git.kernel.org/stable/c/62b71cd73d41ddac6b1760402bbe8c4932e23531 https://access.redhat.com/security/cve/CVE-2024-35800 •

CVSS: 6.2EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Prevent crash when disable stream [Why] Disabling stream encoder invokes a function that no longer exists. [How] Check if the function declaration is NULL in disable stream encoder. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amd/display: evita fallos al deshabilitar la transmisión [Por qué] Al deshabilitar el codificador de transmisión se invoca una función que ya no existe. [Cómo] Compruebe si la declaración de función es NULL al desactivar el codificador de flujo. • https://git.kernel.org/stable/c/4356a2c3f296503c8b420ae8adece053960a9f06 https://git.kernel.org/stable/c/59772327d439874095516673b4b30c48bd83ca38 https://git.kernel.org/stable/c/2b17133a0a2e0e111803124dad09e803718d4a48 https://git.kernel.org/stable/c/72d72e8fddbcd6c98e1b02d32cf6f2b04e10bd1c • CWE-400: Uncontrolled Resource Consumption •

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

In the Linux kernel, the following vulnerability has been resolved: net: ll_temac: platform_get_resource replaced by wrong function The function platform_get_resource was replaced with devm_platform_ioremap_resource_byname and is called using 0 as name. This eventually ends up in platform_get_resource_byname in the call stack, where it causes a null pointer in strcmp. if (type == resource_type(r) && !strcmp(r->name, name)) It should have been replaced with devm_platform_ioremap_resource. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: net:ll_temac: platform_get_resource reemplazada por una función incorrecta La función platform_get_resource fue reemplazada por devm_platform_ioremap_resource_byname y se llama usando 0 como nombre. Esto eventualmente termina en platform_get_resource_byname en la pila de llamadas, donde genera un puntero null en strcmp. if (type == Resource_type(r) && !strcmp(r->name, name)) Debería haber sido reemplazado por devm_platform_ioremap_resource. • https://git.kernel.org/stable/c/bd69058f50d5ffa659423bcfa6fe6280ce9c760a https://git.kernel.org/stable/c/77c8cfdf808410be84be56aff7e0e186b8c5a879 https://git.kernel.org/stable/c/6d9395ba7f85bdb7af0b93272e537484ecbeff48 https://git.kernel.org/stable/c/553d294db94b5f139378022df480a9fb6c3ae39e https://git.kernel.org/stable/c/46efbdbc95a30951c2579caf97b6df2ee2b3bef3 https://git.kernel.org/stable/c/476eed5f1c22034774902a980aa48dc4662cb39a https://git.kernel.org/stable/c/7e9edb569fd9f688d887e36db8170f6e22bafbc8 https://git.kernel.org/stable/c/92c0c29f667870f17c0b764544bdf22ce •

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

In the Linux kernel, the following vulnerability has been resolved: dm-raid: really frozen sync_thread during suspend 1) commit f52f5c71f3d4 ("md: fix stopping sync thread") remove MD_RECOVERY_FROZEN from __md_stop_writes() and doesn't realize that dm-raid relies on __md_stop_writes() to frozen sync_thread indirectly. Fix this problem by adding MD_RECOVERY_FROZEN in md_stop_writes(), and since stop_sync_thread() is only used for dm-raid in this case, also move stop_sync_thread() to md_stop_writes(). 2) The flag MD_RECOVERY_FROZEN doesn't mean that sync thread is frozen, it only prevent new sync_thread to start, and it can't stop the running sync thread; In order to frozen sync_thread, after seting the flag, stop_sync_thread() should be used. 3) The flag MD_RECOVERY_FROZEN doesn't mean that writes are stopped, use it as condition for md_stop_writes() in raid_postsuspend() doesn't look correct. Consider that reentrant stop_sync_thread() do nothing, always call md_stop_writes() in raid_postsuspend(). 4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime, and if MD_RECOVERY_FROZEN is cleared while the array is suspended, new sync_thread can start unexpected. Fix this by disallow raid_message() to change sync_thread status during suspend. Note that after commit f52f5c71f3d4 ("md: fix stopping sync thread"), the test shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(), and with previous fixes, the test won't hang there anymore, however, the test will still fail and complain that ext4 is corrupted. And with this patch, the test won't hang due to stop_sync_thread() or fail due to ext4 is corrupted anymore. • https://git.kernel.org/stable/c/9dbd1aa3a81c6166608fec87994b6c464701f73a https://git.kernel.org/stable/c/af916cb66a80597f3523bc85812e790bcdcfd62b https://git.kernel.org/stable/c/eaa8fc9b092837cf2c754bde1a15d784ce9a85ab https://git.kernel.org/stable/c/16c4770c75b1223998adbeb7286f9a15c65fba73 •

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

In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region() Do the cache flush of converted pages in svm_register_enc_region() before dropping kvm->lock to fix use-after-free issues where region and/or its array of pages could be freed by a different task, e.g. if userspace has __unregister_enc_region_locked() already queued up for the region. Note, the "obvious" alternative of using local variables doesn't fully resolve the bug, as region->pages is also dynamically allocated. I.e. the region structure itself would be fine, but region->pages could be freed. Flushing multiple pages under kvm->lock is unfortunate, but the entire flow is a rare slow path, and the manual flush is only needed on CPUs that lack coherency for encrypted memory. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: SVM: Vaciar páginas bajo kvm->lock para arreglar UAF en svm_register_enc_region() Realice el vaciado de caché de las páginas convertidas en svm_register_enc_region() antes de eliminar kvm->lock para arreglar el uso -Problemas posteriores a la liberación en los que la región y/o su conjunto de páginas podrían liberarse mediante una tarea diferente, por ejemplo, si el espacio de usuario ya tiene __unregister_enc_region_locked() en cola para la región. Tenga en cuenta que la alternativa "obvia" de usar variables locales no resuelve completamente el error, ya que región->páginas también se asigna dinámicamente. Es decir, la estructura de la región en sí estaría bien, pero se podrían liberar regiones->páginas. • https://git.kernel.org/stable/c/4f627ecde7329e476a077bb0590db8f27bb8f912 https://git.kernel.org/stable/c/19a23da53932bc8011220bd8c410cb76012de004 https://git.kernel.org/stable/c/f1ecde00ce1694597f923f0d25f7a797c5243d99 https://git.kernel.org/stable/c/848bcb0a1d96f67d075465667d3a1ad4af56311e https://git.kernel.org/stable/c/2d13b79640b147bd77c34a5998533b2021a4122d https://git.kernel.org/stable/c/e126b508ed2e616d679d85fca2fbe77bb48bbdd7 https://git.kernel.org/stable/c/4868c0ecdb6cfde7c70cf478c46e06bb9c7e5865 https://git.kernel.org/stable/c/12f8e32a5a389a5d58afc67728c76e61b •