CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46997 – arm64: entry: always set GIC_PRIO_PSR_I_SET during entry
https://notcve.org/view.php?id=CVE-2021-46997
In the Linux kernel, the following vulnerability has been resolved: arm64: entry: always set GIC_PRIO_PSR_I_SET during entry Zenghui reports that booting a kernel with "irqchip.gicv3_pseudo_nmi=1" on the command line hits a warning during kernel entry, due to the way we manipulate the PMR. Early in the entry sequence, we call lockdep_hardirqs_off() to inform lockdep that interrupts have been masked (as the HW sets DAIF wqhen entering an exception). Architecturally PMR_EL1 is not affected by exception entry, and we don't set GIC_PRIO_PSR_I_SET in the PMR early in the exception entry sequence, so early in exception entry the PMR can indicate that interrupts are unmasked even though they are masked by DAIF. If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the exception entry paths, and hence lockdep_hardirqs_off() will WARN() that something is amiss. We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during exception entry so that kernel code sees a consistent environment. We must also update local_daif_inherit() to undo this, as currently only touches DAIF. For other paths, local_daif_restore() will update both DAIF and the PMR. With this done, we can remove the existing special cases which set this later in the entry code. We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with local_daif_save(), as this will warn if it ever encounters (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. • https://git.kernel.org/stable/c/2a9b3e6ac69a8bf177d8496a11e749e2dc72fa22 https://git.kernel.org/stable/c/51524fa8b5f7b879ba569227738375d283b79382 https://git.kernel.org/stable/c/e67a83f078005461b59b4c776e6b5addd11725fa https://git.kernel.org/stable/c/d8d52005f57bbb4a4ec02f647e2555d327135c68 https://git.kernel.org/stable/c/4d6a38da8e79e94cbd1344aa90876f0f805db705 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46996 – netfilter: nftables: Fix a memleak from userdata error path in new objects
https://notcve.org/view.php?id=CVE-2021-46996
In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: Fix a memleak from userdata error path in new objects Release object name if userdata allocation fails. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nftables: corrige una fuga de memoria de la ruta de error de los datos del usuario en objetos nuevos. Libera el nombre del objeto si falla la asignación de los datos del usuario. • https://git.kernel.org/stable/c/b131c96496b369c7b14125e7c50e89ac7cec8051 https://git.kernel.org/stable/c/2c784a500f5edd337258b0fdb2f31bc9abde1a23 https://git.kernel.org/stable/c/59fa98bfa1f4013d658d990cac88c87b46ff410c https://git.kernel.org/stable/c/dd3bebf515f336214a91994348a2b86b9a1d3d7f https://git.kernel.org/stable/c/85dfd816fabfc16e71786eda0a33a7046688b5b0 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-46995 – can: mcp251xfd: mcp251xfd_probe(): fix an error pointer dereference in probe
https://notcve.org/view.php?id=CVE-2021-46995
In the Linux kernel, the following vulnerability has been resolved: can: mcp251xfd: mcp251xfd_probe(): fix an error pointer dereference in probe When we converted this code to use dev_err_probe() we accidentally removed a return. It means that if devm_clk_get() it will lead to an Oops when we call clk_get_rate() on the next line. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: mcp251xfd: mcp251xfd_probe(): corrige una desreferencia de puntero de error en la sonda Cuando convertimos este código para usar dev_err_probe() eliminamos accidentalmente un retorno. Significa que si devm_clk_get() generará un Ups cuando llamemos a clk_get_rate() en la siguiente línea. • https://git.kernel.org/stable/c/cf8ee6de2543a0fa6d9471ddbb7216464a9681a1 https://git.kernel.org/stable/c/15f8f96ec7fc35024d4e03296e4d838fcea33d83 https://git.kernel.org/stable/c/4cc7faa406975b460aa674606291dea197c1210c •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2021-46994 – can: mcp251x: fix resume from sleep before interface was brought up
https://notcve.org/view.php?id=CVE-2021-46994
In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix resume from sleep before interface was brought up Since 8ce8c0abcba3 the driver queues work via priv->restart_work when resuming after suspend, even when the interface was not previously enabled. This causes a null dereference error as the workqueue is only allocated and initialized in mcp251x_open(). To fix this we move the workqueue init to mcp251x_can_probe() as there is no reason to do it later and repeat it whenever mcp251x_open() is called. [mkl: fix error handling in mcp251x_stop()] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: can: mcp251x: corregir la reanudación desde la suspensión antes de que se activara la interfaz. Desde 8ce8c0abcba3, las colas de controladores funcionan a través de priv->restart_work cuando se reanudan después de la suspensión, incluso cuando la interfaz no estaba habilitada previamente. Esto provoca un error de desreferencia nula ya que la cola de trabajo solo se asigna e inicializa en mcp251x_open(). Para solucionar este problema, movemos el inicio de la cola de trabajo a mcp251x_can_probe() ya que no hay razón para hacerlo más tarde y repetirlo cada vez que se llama a mcp251x_open(). • https://git.kernel.org/stable/c/8ce8c0abcba314e1fe954a1840f6568bf5aef2ef https://git.kernel.org/stable/c/eecb4df8ec9f896b19ee05bfa632ac6c1dcd8f21 https://git.kernel.org/stable/c/6f8f1c27b577de15f69fefce3c502bb6300d825c https://git.kernel.org/stable/c/e1e10a390fd9479209c4d834d916ca5e6d5d396b https://git.kernel.org/stable/c/03c427147b2d3e503af258711af4fc792b89b0af •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2021-46993 – sched: Fix out-of-bound access in uclamp
https://notcve.org/view.php?id=CVE-2021-46993
In the Linux kernel, the following vulnerability has been resolved: sched: Fix out-of-bound access in uclamp Util-clamp places tasks in different buckets based on their clamp values for performance reasons. However, the size of buckets is currently computed using a rounding division, which can lead to an off-by-one error in some configurations. For instance, with 20 buckets, the bucket size will be 1024/20=51. A task with a clamp of 1024 will be mapped to bucket id 1024/51=20. Sadly, correct indexes are in range [0,19], hence leading to an out of bound memory access. Clamp the bucket id to fix the issue. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: sched: corrige el acceso fuera de los límites en uclamp Util-clamp coloca las tareas en diferentes depósitos según sus valores de fijación por razones de rendimiento. • https://git.kernel.org/stable/c/69842cba9ace84849bb9b8edcdf2cefccd97901c https://git.kernel.org/stable/c/687f523c134b7f0bd040ee1230f6d17990d54172 https://git.kernel.org/stable/c/f7347c85490b92dd144fa1fba9e1eca501656ab3 https://git.kernel.org/stable/c/3da3f804b82a0a382d523a21acf4cf3bb35f936d https://git.kernel.org/stable/c/42ee47c7e3569d9a0e2cb5053c496d97d380472f https://git.kernel.org/stable/c/6d2f8909a5fabb73fe2a63918117943986c39b6c •