Most recent entries from all

bdu:2025-06540

EUVD-2026-344358

fkie_cve-2021-47011

In the Linux kernel, the following vulnerability has been resolved:

mm: memcontrol: slab: fix obtain a reference to a freeing memcg

Patch series "Use obj_cgroup APIs to charge kmem pages", v5.

Since Roman's series "The new cgroup slab memory controller" applied. All slab objects are charged with the new APIs of obj_cgroup. The new APIs introduce a struct obj_cgroup to charge slab objects. It prevents long-living objects from pinning the original memory cgroup in the memory. But there are still some corner objects (e.g. allocations larger than order-1 page on SLUB) which are not charged with the new APIs. Those objects (include the pages which are allocated from buddy allocator directly) are charged as kmem pages which still hold a reference to the memory cgroup.

E.g. We know that the kernel stack is charged as kmem pages because the size of the kernel stack can be greater than 2 pages (e.g. 16KB on x86_64 or arm64). If we create a thread (suppose the thread stack is charged to memory cgroup A) and then move it from memory cgroup A to memory cgroup B. Because the kernel stack of the thread hold a reference to the memory cgroup A. The thread can pin the memory cgroup A in the memory even if we remove the cgroup A. If we want to see this scenario by using the following script. We can see that the system has added 500 dying cgroups (This is not a real world issue, just a script to show that the large kmallocs are charged as kmem pages which can pin the memory cgr…

GHSA-jvv7-jhh3-m96v

In the Linux kernel, the following vulnerability has been resolved:

mm: memcontrol: slab: fix obtain a reference to a freeing memcg

Patch series "Use obj_cgroup APIs to charge kmem pages", v5.

gsd-2021-47011

RHSA-2021:4356 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update

kernel: Intel graphics card information leak. kernel: Overlayfs in the Linux kernel and shiftfs not restoring original value on error leading to a refcount underflow kernel: out-of-bounds reads in pinctrl subsystem. kernel: Improper input validation in some Intel(R) Ethernet E810 Adapter drivers kernel: Insufficient access control in some Intel(R) Ethernet E810 Adapter drivers kernel: Uncontrolled resource consumption in some Intel(R) Ethernet E810 Adapter drivers kernel: Fragmentation cache not cleared on reconnection kernel: Reassembling fragments encrypted under different keys kernel: wifi frame payload being parsed incorrectly as an L2 frame kernel: Forwarding EAPOL from unauthenticated wifi client kernel: accepting plaintext data frames in protected networks kernel: not verifying TKIP MIC of fragmented frames kernel: accepting fragmented plaintext frames in protected networks kernel: accepting unencrypted A-MSDU frames that start with RFC1042 header kernel: accepting plaintext broadcast fragments as full frames kernel: reassembling encrypted fragments with non-consecutive packet numbers kernel: reassembling mixed encrypted/plaintext fragments kernel: powerpc: RTAS calls can be used to compromise kernel integrity kernel: the copy-on-write implementation can grant unintended write access because of a race condition in a THP mapcount check kernel: locking inconsistency in drivers/tty/tty_io.c and drivers/tty/tty_jobctrl.c can lead to a read-after-free kernel: buffer overf…

UBUNTU-CVE-2021-47011

Affected: Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 54 more

In the Linux kernel, the following vulnerability has been resolved: mm: memcontrol: slab: fix obtain a reference to a freeing memcg Patch series "Use obj_cgroup APIs to charge kmem pages", v5. Since Roman's series "The new cgroup slab memory controller" applied. All slab objects are charged with the new APIs of obj_cgroup. The new APIs introduce a struct obj_cgroup to charge slab objects. It prevents long-living objects from pinning the original memory cgroup in the memory. But there are still some corner objects (e.g. allocations larger than order-1 page on SLUB) which are not charged with the new APIs. Those objects (include the pages which are allocated from buddy allocator directly) are charged as kmem pages which still hold a reference to the memory cgroup. E.g. We know that the kernel stack is charged as kmem pages because the size of the kernel stack can be greater than 2 pages (e.g. 16KB on x86_64 or arm64). If we create a thread (suppose the thread stack is charged to memory cgroup A) and then move it from memory cgroup A to memory cgroup B. Because the kernel stack of the thread hold a reference to the memory cgroup A. The thread can pin the memory cgroup A in the memory even if we remove the cgroup A. If we want to see this scenario by using the following script. We can see that the system has added 500 dying cgroups (This is not a real world issue, just a script to show that the large kmallocs are charged as kmem pages which can pin the memory cgroup…