CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2021-47114 – ocfs2: fix data corruption by fallocate
https://notcve.org/view.php?id=CVE-2021-47114
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix data corruption by fallocate When fallocate punches holes out of inode size, if original isize is in the middle of last cluster, then the part from isize to the end of the cluster will be zeroed with buffer write, at that time isize is not yet updated to match the new size, if writeback is kicked in, it will invoke ocfs2_writepage()->block_write_full_page() where the pages out of inode size will be dropped. That will cause file corruption. Fix this by zero out eof blocks when extending the inode size. Running the following command with qemu-image 4.2.1 can get a corrupted coverted image file easily. qemu-img convert -p -t none -T none -f qcow2 $qcow_image \ -O qcow2 -o compat=1.1 $qcow_image.conv The usage of fallocate in qemu is like this, it first punches holes out of inode size, then extend the inode size. fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0 fallocate(11, 0, 2276196352, 65536) = 0 v1: https://www.spinics.net/lists/linux-fsdevel/msg193999.html v2: https://lore.kernel.org/linux-fsdevel/20210525093034.GB4112@quack2.suse.cz/T/ En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: corrige la corrupción de datos por fallocate Cuando fallocate perfora agujeros en el tamaño del inodo, si el isize original está en el medio del último clúster, entonces la parte desde isize hasta el final del clúster se pondrá a cero con la escritura en el búfer, en ese momento isize aún no se ha actualizado para que coincida con el nuevo tamaño, si se activa la reescritura, invocará ocfs2_writepage()->block_write_full_page() donde se eliminarán las páginas fuera del tamaño del inodo. Eso causará corrupción de archivos. Solucione este problema poniendo a cero los bloques eof al extender el tamaño del inodo. • https://git.kernel.org/stable/c/624fa7baa3788dc9e57840ba5b94bc22b03cda57 https://git.kernel.org/stable/c/33e03adafb29eedae1bae9cdb50c1385279fcf65 https://git.kernel.org/stable/c/a1700479524bb9cb5e8ae720236a6fabd003acae https://git.kernel.org/stable/c/cec4e857ffaa8c447f51cd8ab4e72350077b6770 https://git.kernel.org/stable/c/cc2edb99ea606a45182b5ea38cc8f4e583aa0774 https://git.kernel.org/stable/c/c8d5faee46242c3f33b8a71a4d7d52214785bfcc https://git.kernel.org/stable/c/0a31dd6fd2f4e7db538fb6eb1f06973d81f8dd3b https://git.kernel.org/stable/c/6bba4471f0cc1296fe3c2089b9e52442d •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47113 – btrfs: abort in rename_exchange if we fail to insert the second ref
https://notcve.org/view.php?id=CVE-2021-47113
In the Linux kernel, the following vulnerability has been resolved: btrfs: abort in rename_exchange if we fail to insert the second ref Error injection stress uncovered a problem where we'd leave a dangling inode ref if we failed during a rename_exchange. This happens because we insert the inode ref for one side of the rename, and then for the other side. If this second inode ref insert fails we'll leave the first one dangling and leave a corrupt file system behind. Fix this by aborting if we did the insert for the first inode ref. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: abortar en rename_exchange si no logramos insertar la segunda referencia. • https://git.kernel.org/stable/c/0df50d47d17401f9f140dfbe752a65e5d72f9932 https://git.kernel.org/stable/c/ff8de2cec65a8c8521faade12a31b39c80e49f5b https://git.kernel.org/stable/c/dc09ef3562726cd520c8338c1640872a60187af5 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47112 – x86/kvm: Teardown PV features on boot CPU as well
https://notcve.org/view.php?id=CVE-2021-47112
In the Linux kernel, the following vulnerability has been resolved: x86/kvm: Teardown PV features on boot CPU as well Various PV features (Async PF, PV EOI, steal time) work through memory shared with hypervisor and when we restore from hibernation we must properly teardown all these features to make sure hypervisor doesn't write to stale locations after we jump to the previously hibernated kernel (which can try to place anything there). For secondary CPUs the job is already done by kvm_cpu_down_prepare(), register syscore ops to do the same for boot CPU. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/kvm: Desmontaje de funciones PV también en la CPU de arranque Varias funciones PV (Async PF, PV EOI, tiempo de robo) funcionan a través de la memoria compartida con el hipervisor y cuando restauramos desde la hibernación Debemos eliminar adecuadamente todas estas características para asegurarnos de que el hipervisor no escriba en ubicaciones obsoletas después de saltar al kernel previamente hibernado (que puede intentar colocar cualquier cosa allí). Para las CPU secundarias, el trabajo ya lo realiza kvm_cpu_down_prepare(), registre syscore ops para hacer lo mismo para la CPU de arranque. • https://git.kernel.org/stable/c/7620a669111b52f224d006dea9e1e688e2d62c54 https://git.kernel.org/stable/c/38b858da1c58ad46519a257764e059e663b59ff2 https://git.kernel.org/stable/c/d1629b5b925de9b27979e929dae7fcb766daf6b6 https://git.kernel.org/stable/c/8b79feffeca28c5459458fe78676b081e87c93a4 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47110 – x86/kvm: Disable kvmclock on all CPUs on shutdown
https://notcve.org/view.php?id=CVE-2021-47110
In the Linux kernel, the following vulnerability has been resolved: x86/kvm: Disable kvmclock on all CPUs on shutdown Currenly, we disable kvmclock from machine_shutdown() hook and this only happens for boot CPU. We need to disable it for all CPUs to guard against memory corruption e.g. on restore from hibernate. Note, writing '0' to kvmclock MSR doesn't clear memory location, it just prevents hypervisor from updating the location so for the short while after write and while CPU is still alive, the clock remains usable and correct so we don't need to switch to some other clocksource. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: x86/kvm: deshabilite kvmclock en todas las CPU al apagar Actualmente, deshabilitamos kvmclock desde el enlace machine_shutdown() y esto solo sucede para la CPU de arranque. Necesitamos deshabilitarlo para todas las CPU para protegernos contra la corrupción de la memoria, por ejemplo, al restaurar desde la hibernación. Tenga en cuenta que escribir '0' en kvmclock MSR no borra la ubicación de la memoria, solo evita que el hipervisor actualice la ubicación, por lo que durante un breve período después de la escritura y mientras la CPU aún está activa, el reloj permanece utilizable y correcto, por lo que no lo necesitamos. para cambiar a alguna otra fuente de reloj. • https://git.kernel.org/stable/c/9084fe1b3572664ad276f427dce575f580c9799a https://git.kernel.org/stable/c/3b0becf8b1ecf642a9edaf4c9628ffc641e490d6 https://git.kernel.org/stable/c/1df2dc09926f61319116c80ee85701df33577d70 https://git.kernel.org/stable/c/c02027b5742b5aa804ef08a4a9db433295533046 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52607 – powerpc/mm: Fix null-pointer dereference in pgtable_cache_add
https://notcve.org/view.php?id=CVE-2023-52607
In the Linux kernel, the following vulnerability has been resolved: powerpc/mm: Fix null-pointer dereference in pgtable_cache_add kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/mm: corrige la desreferencia del puntero nulo en pgtable_cache_add kasprintf() devuelve un puntero a la memoria asignada dinámicamente que puede ser NULL en caso de falla. Asegúrese de que la asignación se haya realizado correctamente comprobando la validez del puntero. A possible null-pointer dereference was found in pgtable_cache_add in the Linux kernel. • https://git.kernel.org/stable/c/21e45a7b08d7cd98d6a53c5fc5111879f2d96611 https://git.kernel.org/stable/c/f6781add1c311c17eff43e14c786004bbacf901e https://git.kernel.org/stable/c/aa28eecb43cac6e20ef14dfc50b8892c1fbcda5b https://git.kernel.org/stable/c/ac3ed969a40357b0542d20f096a6d43acdfa6cc7 https://git.kernel.org/stable/c/d482d61025e303a2bef3733a011b6b740215cfa1 https://git.kernel.org/stable/c/145febd85c3bcc5c74d87ef9a598fc7d9122d532 https://git.kernel.org/stable/c/ffd29dc45bc0355393859049f6becddc3ed08f74 https://git.kernel.org/stable/c/f46c8a75263f97bda13c739ba1c90aced • CWE-395: Use of NullPointerException Catch to Detect NULL Pointer Dereference •