CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47320 – nfs: fix acl memory leak of posix_acl_create()
https://notcve.org/view.php?id=CVE-2021-47320
In the Linux kernel, the following vulnerability has been resolved: nfs: fix acl memory leak of posix_acl_create() When looking into another nfs xfstests report, I found acl and default_acl in nfs3_proc_create() and nfs3_proc_mknod() error paths are possibly leaked. Fix them in advance. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: nfs: corrige la pérdida de memoria acl de posix_acl_create(). Al buscar en otro informe de nfs xfstests, encontré que acl y default_acl en nfs3_proc_create() y las rutas de error de nfs3_proc_mknod() posiblemente se hayan filtrado. Arréglelos con anticipación. • https://git.kernel.org/stable/c/013cdf1088d7235da9477a2375654921d9b9ba9f https://git.kernel.org/stable/c/2e3960f276b4574a9bb0dfa31a7497302f6363b2 https://git.kernel.org/stable/c/cef9d9acb7c80ed6bace894b6334557fd493863b https://git.kernel.org/stable/c/8a2b308a54c5ec224fedc753617f99b29ffcd883 https://git.kernel.org/stable/c/0704f617040c397ae73c1f88f3956787ec5d6529 https://git.kernel.org/stable/c/d0b32dc1409f7e65e4fcc34e236462268e69a357 https://git.kernel.org/stable/c/4b515308ab875c7e8ada8e606fe0c64762da5ed4 https://git.kernel.org/stable/c/c8fc86e9df6a6a03f5a8e15a3b7a5c75f •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2021-47319 – virtio-blk: Fix memory leak among suspend/resume procedure
https://notcve.org/view.php?id=CVE-2021-47319
In the Linux kernel, the following vulnerability has been resolved: virtio-blk: Fix memory leak among suspend/resume procedure The vblk->vqs should be freed before we call init_vqs() in virtblk_restore(). En el kernel de Linux, se resolvió la siguiente vulnerabilidad: virtio-blk: corrige la pérdida de memoria entre el procedimiento de suspensión/reanudación. El vblk->vqs debe liberarse antes de llamar a init_vqs() en virtblk_restore(). • https://git.kernel.org/stable/c/381bde79d11e596002edfd914e6714291826967a https://git.kernel.org/stable/c/102d6bc6475ab09bab579c18704e6cf8d898e93c https://git.kernel.org/stable/c/863da837964c80c72e368a4f748c30d25daa1815 https://git.kernel.org/stable/c/600942d2fd49b90e44857d20c774b20d16f3130f https://git.kernel.org/stable/c/04c6e60b884cb5e94ff32af46867fb41d5848358 https://git.kernel.org/stable/c/cd24da0db9f75ca11eaf6060f0ccb90e2f3be3b0 https://git.kernel.org/stable/c/ca2b8ae93a6da9839dc7f9eb9199b18aa03c3dae https://git.kernel.org/stable/c/29a2f4a3214aa14d61cc9737c9f886dae •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47318 – arch_topology: Avoid use-after-free for scale_freq_data
https://notcve.org/view.php?id=CVE-2021-47318
In the Linux kernel, the following vulnerability has been resolved: arch_topology: Avoid use-after-free for scale_freq_data Currently topology_scale_freq_tick() (which gets called from scheduler_tick()) may end up using a pointer to "struct scale_freq_data", which was previously cleared by topology_clear_scale_freq_source(), as there is no protection in place here. The users of topology_clear_scale_freq_source() though needs a guarantee that the previously cleared scale_freq_data isn't used anymore, so they can free the related resources. Since topology_scale_freq_tick() is called from scheduler tick, we don't want to add locking in there. Use the RCU update mechanism instead (which is already used by the scheduler's utilization update path) to guarantee race free updates here. synchronize_rcu() makes sure that all RCU critical sections that started before it is called, will finish before it returns. And so the callers of topology_clear_scale_freq_source() don't need to worry about their callback getting called anymore. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arch_topology: Evite el use after free para scale_freq_data. • https://git.kernel.org/stable/c/01e055c120a46e78650b5f903088badbbdaae9ad https://git.kernel.org/stable/c/ccdf7e073170886bc370c613e269de610a794c4a https://git.kernel.org/stable/c/83150f5d05f065fb5c12c612f119015cabdcc124 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47317 – powerpc/bpf: Fix detecting BPF atomic instructions
https://notcve.org/view.php?id=CVE-2021-47317
In the Linux kernel, the following vulnerability has been resolved: powerpc/bpf: Fix detecting BPF atomic instructions Commit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other atomics in .imm") converted BPF_XADD to BPF_ATOMIC and added a way to distinguish instructions based on the immediate field. Existing JIT implementations were updated to check for the immediate field and to reject programs utilizing anything more than BPF_ADD (such as BPF_FETCH) in the immediate field. However, the check added to powerpc64 JIT did not look at the correct BPF instruction. Due to this, such programs would be accepted and incorrectly JIT'ed resulting in soft lockups, as seen with the atomic bounds test. Fix this by looking at the correct immediate value. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: powerpc/bpf: Corrección de la detección de instrucciones atómicas BPF. • https://git.kernel.org/stable/c/91c960b0056672e74627776655c926388350fa30 https://git.kernel.org/stable/c/7284dab07e4d51d453cc42851fae9ec4fac6ef2f https://git.kernel.org/stable/c/0d435b6d94b05dcfd836d758a63145aa566618e2 https://git.kernel.org/stable/c/419ac821766cbdb9fd85872bb3f1a589df05c94c •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2021-47316 – nfsd: fix NULL dereference in nfs3svc_encode_getaclres
https://notcve.org/view.php?id=CVE-2021-47316
In the Linux kernel, the following vulnerability has been resolved: nfsd: fix NULL dereference in nfs3svc_encode_getaclres In error cases the dentry may be NULL. Before 20798dfe249a, the encoder also checked dentry and d_really_is_positive(dentry), but that looks like overkill to me--zero status should be enough to guarantee a positive dentry. This isn't the first time we've seen an error-case NULL dereference hidden in the initialization of a local variable in an xdr encoder. But I went back through the other recent rewrites and didn't spot any similar bugs. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nfsd: corrige la desreferencia NULL en nfs3svc_encode_getaclres. En casos de error, la dentry puede ser NULL. Antes de 20798dfe249a, el codificador también verificaba dentry y d_really_is_positive(dentry), pero eso me parece excesivo: el estado cero debería ser suficiente para garantizar un dentry positivo. • https://git.kernel.org/stable/c/20798dfe249a01ad1b12eec7dbc572db5003244a https://git.kernel.org/stable/c/650e6f383a6eb40f7c0a010982a74ab4b6893870 https://git.kernel.org/stable/c/ab1016d39cc052064e32f25ad18ef8767a0ee3b8 https://git.kernel.org/stable/c/e79057d15d96ef19de4de6d7e479bae3d58a2a8d •