CVSS: 3.3EPSS: 0%CPEs: 6EXPL: 0CVE-2021-47000 – ceph: fix inode leak on getattr error in __fh_to_dentry
https://notcve.org/view.php?id=CVE-2021-47000
In the Linux kernel, the following vulnerability has been resolved: ceph: fix inode leak on getattr error in __fh_to_dentry En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ceph: corrige la fuga de inodo en el error getattr en __fh_to_dentry • https://git.kernel.org/stable/c/807460787179dee5f74906965eeb5f3ca2353992 https://git.kernel.org/stable/c/878dabb64117406abd40977b87544d05bb3031fc https://git.kernel.org/stable/c/10b7ddff50b3334414c0be4b6009671b18ba4845 https://git.kernel.org/stable/c/2ad8af2b70e986284050213230428b823b950a38 https://git.kernel.org/stable/c/bf45c9fe99aa8003d2703f1bd353f956dea47e40 https://git.kernel.org/stable/c/22fa4c8288f1ec40f6d62d7a32c57ac176f9f0bc https://git.kernel.org/stable/c/0a219432127d396120fc88cabd82785e0ff72a2f https://git.kernel.org/stable/c/1775c7ddacfcea29051c67409087578f8 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2021-46999 – sctp: do asoc update earlier in sctp_sf_do_dupcook_a
https://notcve.org/view.php?id=CVE-2021-46999
In the Linux kernel, the following vulnerability has been resolved: sctp: do asoc update earlier in sctp_sf_do_dupcook_a There's a panic that occurs in a few of envs, the call trace is as below: [] general protection fault, ... 0x29acd70f1000a: 0000 [#1] SMP PTI [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp] [] sctp_assoc_control_transport+0x1b9/0x210 [sctp] [] sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp] [] sctp_cmd_interpreter.isra.21+0x1231/0x1a10 [sctp] [] sctp_do_sm+0xc3/0x2a0 [sctp] [] sctp_generate_timeout_event+0x81/0xf0 [sctp] This is caused by a transport use-after-free issue. When processing a duplicate COOKIE-ECHO chunk in sctp_sf_do_dupcook_a(), both COOKIE-ACK and SHUTDOWN chunks are allocated with the transort from the new asoc. However, later in the sideeffect machine, the old asoc is used to send them out and old asoc's shutdown_last_sent_to is set to the transport that SHUTDOWN chunk attached to in sctp_cmd_setup_t2(), which actually belongs to the new asoc. After the new_asoc is freed and the old asoc T2 timeout, the old asoc's shutdown_last_sent_to that is already freed would be accessed in sctp_sf_t2_timer_expire(). Thanks Alexander and Jere for helping dig into this issue. To fix it, this patch is to do the asoc update first, then allocate the COOKIE-ACK and SHUTDOWN chunks with the 'updated' old asoc. This would make more sense, as a chunk from an asoc shouldn't be sent out with another asoc. We had fixed quite a few issues caused by this. • https://git.kernel.org/stable/c/db8bf823e70f239372c62f13e4eb6f08a1665e8c https://git.kernel.org/stable/c/a204d577be70e0a0a6023cf1b9859c9ebffaeecd https://git.kernel.org/stable/c/145cb2f7177d94bc54563ed26027e952ee0ae03c https://git.kernel.org/stable/c/a5ce8531ea508d270822b2bc6140c6198c8a2a7b https://git.kernel.org/stable/c/d624f2991b977821375fbd56c91b0c91d456a697 https://git.kernel.org/stable/c/b1b31948c0af44628e43353828453461bb74098f https://git.kernel.org/stable/c/f01988ecf3654f805282dce2d3bb9afe68d2691e https://git.kernel.org/stable/c/61b877bad9bb0d82b7d8841be50872557 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2021-46998 – ethernet:enic: Fix a use after free bug in enic_hard_start_xmit
https://notcve.org/view.php?id=CVE-2021-46998
In the Linux kernel, the following vulnerability has been resolved: ethernet:enic: Fix a use after free bug in enic_hard_start_xmit In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside enic_queue_wq_skb, if some error happens, the skb will be freed by dev_kfree_skb(skb). But the freed skb is still used in skb_tx_timestamp(skb). My patch makes enic_queue_wq_skb() return error and goto spin_unlock() incase of error. The solution is provided by Govind. See https://lkml.org/lkml/2021/4/30/961. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ethernet:enic: corrige un error de use after free en enic_hard_start_xmit. • https://git.kernel.org/stable/c/fb7516d42478ebc8e2f00efb76ef96f7b68fd8d3 https://git.kernel.org/stable/c/25a87b1f566b5eb2af2857a928f0e2310d900976 https://git.kernel.org/stable/c/f7f6f07774091a6ddd98500b85386c3c6afb30d3 https://git.kernel.org/stable/c/7afdd6aba95c8a526038e7abe283eeac3e4320f1 https://git.kernel.org/stable/c/6892396ebf04ea2c021d80e10f4075e014cd7cc3 https://git.kernel.org/stable/c/d90529392aaf498dafa95d212295d64b2cea4e24 https://git.kernel.org/stable/c/643001b47adc844ae33510c4bb93c236667008a3 •
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 •