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

mm/slub: add missing TID updates on slab deactivation

The fastpath in slab_alloc_node() assumes that c->slab is stable as long as the TID stays the same. However, two places in __slab_alloc() currently don't update the TID when deactivating the CPU slab.

If multiple operations race the right way, this could lead to an object getting lost; or, in an even more unlikely situation, it could even lead to an object being freed onto the wrong slab's freelist, messing up the `inuse` counter and eventually causing a page to be freed to the page allocator while it still contains slab objects.

(I haven't actually tested these cases though, this is just based on looking at the code. Writing testcases for this stuff seems like it'd be a pain...)

The race leading to state inconsistency is (all operations on the same CPU and kmem_cache):

- task A: begin do_slab_free(): - read TID - read pcpu freelist (==NULL) - check `slab == c->slab` (true) - [PREEMPT A->B] - task B: begin slab_alloc_node(): - fastpath fails (`c->freelist` is NULL) - enter __slab_alloc() - slub_get_cpu_ptr() (disables preemption) - enter ___slab_alloc() - take local_lock_irqsave() - read c->freelist as NULL - get_freelist() returns NULL - write `c->slab = NULL` - drop local_unlock_irqrestore() - goto new_slab - slub_percpu_partial() is NULL - get_partial() returns NULL - slub_put_cpu…

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

mm/slub: add missing TID updates on slab deactivation

The fastpath in slab_alloc_node() assumes that c->slab is stable as long as the TID stays the same. However, two places in __slab_alloc() currently don't update the TID when deactivating the CPU slab.

If multiple operations race the right way, this could lead to an object getting lost; or, in an even more unlikely situation, it could even lead to an object being freed onto the wrong slab's freelist, messing up the `inuse` counter and eventually causing a page to be freed to the page allocator while it still contains slab objects.

(I haven't actually tested these cases though, this is just based on looking at the code. Writing testcases for this stuff seems like it'd be a pain...)

The race leading to state inconsistency is (all operations on the same CPU and kmem_cache):

- task A: begin do_slab_free(): - read TID - read pcpu freelist (==NULL) - check `slab == c->slab` (true) - [PREEMPT A->B] - task B: begin slab_alloc_node(): - fastpath fails (`c->freelist` is NULL) - enter __slab_alloc() - slub_get_cpu_ptr() (disables preemption) - enter ___slab_alloc() - take local_lock_irqsave() - read c->freelist as NULL - get_freelist() returns NULL - write `c->slab = NULL` - drop local_unlock_irqrestore() - goto new_slab - slub_percpu_partial() is NULL - get_partial() returns NULL - slub_put_cpu…

hw: cpu: AMD CPUs may transiently execute beyond unconditional direct branch kernel: ext4: kernel bug in ext4_write_inline_data_end() kernel: malicious data for FBIOPUT_VSCREENINFO ioctl may cause OOB write memory kernel: hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs kernel: mlxsw: thermal: Fix out-of-bounds memory accesses kernel: mlxsw: spectrum: Protect driver from buggy firmware kernel: net: stmmac: fix tc flower deletion for VLAN priority Rx steering kernel: can: etas_es58x: es58x_rx_err_msg(): fix memory leak in error path kernel: possible race condition in drivers/tty/tty_buffers.c kernel: KVM: NULL pointer dereference in kvm_mmu_invpcid_gva kernel: use-after-free in free_pipe_info() could lead to privilege escalation kernel: KVM: nVMX: missing IBPB when exiting from nested guest can lead to Spectre v2 attacks kernel: netfilter: nf_conntrack_irc message handling issue kernel: race condition in xfrm_probe_algs can lead to OOB read/write kernel: out-of-bounds read in fib_nh_match of the file net/ipv4/fib_semantics.c kernel: race condition in hugetlb_no_page() in mm/hugetlb.c kernel: memory leak in ipv6_renew_options() kernel: data races around icsk->icsk_af_ops in do_ipv6_setsockopt kernel: data races around sk->sk_prot kernel: memory leak in l2cap_recv_acldata of the file net/bluetooth/l2cap_core.c kernel: denial of service in follow_page_pte in mm/gup.c due to poisoned pte entry kernel: use-after-free after failed devlink relo…

Affected: Rocky Linux:8: kernel

The kernel packages contain the Linux kernel, the core of any Linux operating system.

Security Fix(es):

For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.

Additional Changes:

For detailed information on changes in this release, see the Rocky Linux SIG Cloud 8.10 Release Notes linked from the References section.

Security update for the Linux Kernel

Affected: Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:16.04:LTS: linux and 144 more

In the Linux kernel, the following vulnerability has been resolved: mm/slub: add missing TID updates on slab deactivation The fastpath in slab_alloc_node() assumes that c->slab is stable as long as the TID stays the same. However, two places in __slab_alloc() currently don't update the TID when deactivating the CPU slab. If multiple operations race the right way, this could lead to an object getting lost; or, in an even more unlikely situation, it could even lead to an object being freed onto the wrong slab's freelist, messing up the `inuse` counter and eventually causing a page to be freed to the page allocator while it still contains slab objects. (I haven't actually tested these cases though, this is just based on looking at the code. Writing testcases for this stuff seems like it'd be a pain...) The race leading to state inconsistency is (all operations on the same CPU and kmem_cache): - task A: begin do_slab_free(): - read TID - read pcpu freelist (==NULL) - check `slab == c->slab` (true) - [PREEMPT A->B] - task B: begin slab_alloc_node(): - fastpath fails (`c->freelist` is NULL) - enter __slab_alloc() - slub_get_cpu_ptr() (disables preemption) - enter ___slab_alloc() - take local_lock_irqsave() - read c->freelist as NULL - get_freelist() returns NULL - write `c->slab = NULL` - drop local_unlock_irqrestore() - goto new_slab - slub_percpu_partial() is NULL - get_partial() returns NULL - slub_put_cpu_ptr()…