CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47111 – xen-netback: take a reference to the RX task thread
https://notcve.org/view.php?id=CVE-2021-47111
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: 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: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47109 – neighbour: allow NUD_NOARP entries to be forced GCed
https://notcve.org/view.php?id=CVE-2021-47109
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 •
CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26630 – mm: cachestat: fix folio read-after-free in cache walk
https://notcve.org/view.php?id=CVE-2024-26630
In the Linux kernel, the following vulnerability has been resolved: mm: cachestat: fix folio read-after-free in cache walk In cachestat, we access the folio from the page cache's xarray to compute its page offset, and check for its dirty and writeback flags. However, we do not hold a reference to the folio before performing these actions, which means the folio can concurrently be released and reused as another folio/page/slab. Get around this altogether by just using xarray's existing machinery for the folio page offsets and dirty/writeback states. This changes behavior for tmpfs files to now always report zeroes in their dirty and writeback counters. This is okay as tmpfs doesn't follow conventional writeback cache behavior: its pages get "cleaned" during swapout, after which they're no longer resident etc. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: cachestat: corrige read-after-free la publicación en cache walk En cachestat, accedemos a la publicación desde la matriz x de la caché de la página para calcular su desplazamiento de página y comprobar si está sucia y banderas de reescritura. Sin embargo, no mantenemos una referencia al folio antes de realizar estas acciones, lo que significa que el folio se puede liberar y reutilizar simultáneamente como otro folio/página/losa. • https://git.kernel.org/stable/c/cf264e1329fb0307e044f7675849f9f38b44c11a https://git.kernel.org/stable/c/ba60fdf75e89ea762bb617be578dc47f27655117 https://git.kernel.org/stable/c/fe7e008e0ce728252e4ec652cceebcc62211657c https://git.kernel.org/stable/c/3a75cb05d53f4a6823a32deb078de1366954a804 https://access.redhat.com/security/cve/CVE-2024-26630 https://bugzilla.redhat.com/show_bug.cgi?id=2269436 • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 13EXPL: 0CVE-2024-26629 – nfsd: fix RELEASE_LOCKOWNER
https://notcve.org/view.php?id=CVE-2024-26629
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix RELEASE_LOCKOWNER The test on so_count in nfsd4_release_lockowner() is nonsense and harmful. Revert to using check_for_locks(), changing that to not sleep. First: harmful. As is documented in the kdoc comment for nfsd4_release_lockowner(), the test on so_count can transiently return a false positive resulting in a return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is clearly a protocol violation and with the Linux NFS client it can cause incorrect behaviour. If RELEASE_LOCKOWNER is sent while some other thread is still processing a LOCK request which failed because, at the time that request was received, the given owner held a conflicting lock, then the nfsd thread processing that LOCK request can hold a reference (conflock) to the lock owner that causes nfsd4_release_lockowner() to return an incorrect error. The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so it knows that the error is impossible. It assumes the lock owner was in fact released so it feels free to use the same lock owner identifier in some later locking request. When it does reuse a lock owner identifier for which a previous RELEASE failed, it will naturally use a lock_seqid of zero. However the server, which didn't release the lock owner, will expect a larger lock_seqid and so will respond with NFS4ERR_BAD_SEQID. So clearly it is harmful to allow a false positive, which testing so_count allows. The test is nonsense because ... well... it doesn't mean anything. so_count is the sum of three different counts. 1/ the set of states listed on so_stateids 2/ the set of active vfs locks owned by any of those states 3/ various transient counts such as for conflicting locks. When it is tested against '2' it is clear that one of these is the transient reference obtained by find_lockowner_str_locked(). • https://git.kernel.org/stable/c/3097f38e91266c7132c3fdb7e778fac858c00670 https://git.kernel.org/stable/c/e2fc17fcc503cfca57b5d1dd3b646ca7eebead97 https://git.kernel.org/stable/c/ce3c4ad7f4ce5db7b4f08a1e237d8dd94b39180b https://git.kernel.org/stable/c/fea1d0940301378206955264a01778700fc9c16f https://git.kernel.org/stable/c/2ec65dc6635d1976bd1dbf2640ff7f810b2f6dd1 https://git.kernel.org/stable/c/ef481b262bba4f454351eec43f024fec942c2d4c https://git.kernel.org/stable/c/10d75984495f7fe62152c3b0dbfa3f0a6b739c9b https://git.kernel.org/stable/c/a2235bc65ade40982c3d09025cdd34bc5 • CWE-393: Return of Wrong Status Code •