Page 377 of 3806 results (0.014 seconds)

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

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: 0

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: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: xen-netback: take a reference to the RX task thread Do this in order to prevent the task from being freed if the thread returns (which can be triggered by the frontend) before the call to kthread_stop done as part of the backend tear down. Not taking the reference will lead to a use-after-free in that scenario. Such reference was taken before but dropped as part of the rework done in 2ac061ce97f4. Reintroduce the reference taking and add a comment this time explaining why it's needed. This is XSA-374 / CVE-2021-28691. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen-netback: toma una referencia al hilo de la tarea RX. Haga esto para evitar que la tarea se libere si el hilo regresa (que puede ser activado por el frontend) antes de que llamada a kthread_stop realizada como parte del desmontaje del backend. • https://git.kernel.org/stable/c/2ac061ce97f413bfbbdd768f7d2e0fda2e8170df https://git.kernel.org/stable/c/6b53db8c4c14b4e7256f058d202908b54a7b85b4 https://git.kernel.org/stable/c/caec9bcaeb1a5f03f2d406305355c853af10c13e https://git.kernel.org/stable/c/107866a8eb0b664675a260f1ba0655010fac1e08 •

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

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: -EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: neighbour: allow NUD_NOARP entries to be forced GCed IFF_POINTOPOINT interfaces use NUD_NOARP entries for IPv6. It's possible to fill up the neighbour table with enough entries that it will overflow for valid connections after that. This behaviour is more prevalent after commit 58956317c8de ("neighbor: Improve garbage collection") is applied, as it prevents removal from entries that are not NUD_FAILED, unless they are more than 5s old. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: vecino: permite forzar las entradas NUD_NOARP. Las interfaces GCed IFF_POINTOPOINT utilizan entradas NUD_NOARP para IPv6. Es posible llenar la tabla de vecinos con suficientes entradas para que después de eso se desborde de conexiones válidas. • https://git.kernel.org/stable/c/58956317c8de52009d1a38a721474c24aef74fe7 https://git.kernel.org/stable/c/d99029e6aab62aef0a0251588b2867e77e83b137 https://git.kernel.org/stable/c/d17d47da59f726dc4c87caebda3a50333d7e2fd3 https://git.kernel.org/stable/c/ddf088d7aaaaacfc836104f2e632b29b1d383cfc https://git.kernel.org/stable/c/7a6b1ab7475fd6478eeaf5c9d1163e7a18125c8f •