cve/published/2025/CVE-2025-37774.mbox - pub/scm/linux/security/vulns - Git at Google

 From bippy-1.2.0 Mon Sep 17 00:00:00 2001
 From: Greg Kroah-Hartman <gregkh@kernel.org>
 To: <linux-cve-announce@vger.kernel.org>
 Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
 Subject: CVE-2025-37774: slab: ensure slab->obj_exts is clear in a newly allocated slab page

 Description
 ===========

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

 slab: ensure slab->obj_exts is clear in a newly allocated slab page

 ktest recently reported crashes while running several buffered io tests
 with __alloc_tagging_slab_alloc_hook() at the top of the crash call stack.
 The signature indicates an invalid address dereference with low bits of
 slab->obj_exts being set. The bits were outside of the range used by
 page_memcg_data_flags and objext_flags and hence were not masked out
 by slab_obj_exts() when obtaining the pointer stored in slab->obj_exts.
 The typical crash log looks like this:

 00510 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
 00510 Mem abort info:
 00510   ESR = 0x0000000096000045
 00510   EC = 0x25: DABT (current EL), IL = 32 bits
 00510   SET = 0, FnV = 0
 00510   EA = 0, S1PTW = 0
 00510   FSC = 0x05: level 1 translation fault
 00510 Data abort info:
 00510   ISV = 0, ISS = 0x00000045, ISS2 = 0x00000000
 00510   CM = 0, WnR = 1, TnD = 0, TagAccess = 0
 00510   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
 00510 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000104175000
 00510 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
 00510 Internal error: Oops: 0000000096000045 [#1]  SMP
 00510 Modules linked in:
 00510 CPU: 10 UID: 0 PID: 7692 Comm: cat Not tainted 6.15.0-rc1-ktest-g189e17946605 #19327 NONE
 00510 Hardware name: linux,dummy-virt (DT)
 00510 pstate: 20001005 (nzCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--)
 00510 pc : __alloc_tagging_slab_alloc_hook+0xe0/0x190
 00510 lr : __kmalloc_noprof+0x150/0x310
 00510 sp : ffffff80c87df6c0
 00510 x29: ffffff80c87df6c0 x28: 000000000013d1ff x27: 000000000013d200
 00510 x26: ffffff80c87df9e0 x25: 0000000000000000 x24: 0000000000000001
 00510 x23: ffffffc08041953c x22: 000000000000004c x21: ffffff80c0002180
 00510 x20: fffffffec3120840 x19: ffffff80c4821000 x18: 0000000000000000
 00510 x17: fffffffec3d02f00 x16: fffffffec3d02e00 x15: fffffffec3d00700
 00510 x14: fffffffec3d00600 x13: 0000000000000200 x12: 0000000000000006
 00510 x11: ffffffc080bb86c0 x10: 0000000000000000 x9 : ffffffc080201e58
 00510 x8 : ffffff80c4821060 x7 : 0000000000000000 x6 : 0000000055555556
 00510 x5 : 0000000000000001 x4 : 0000000000000010 x3 : 0000000000000060
 00510 x2 : 0000000000000000 x1 : ffffffc080f50cf8 x0 : ffffff80d801d000
 00510 Call trace:
 00510  __alloc_tagging_slab_alloc_hook+0xe0/0x190 (P)
 00510  __kmalloc_noprof+0x150/0x310
 00510  __bch2_folio_create+0x5c/0xf8
 00510  bch2_folio_create+0x2c/0x40
 00510  bch2_readahead+0xc0/0x460
 00510  read_pages+0x7c/0x230
 00510  page_cache_ra_order+0x244/0x3a8
 00510  page_cache_async_ra+0x124/0x170
 00510  filemap_readahead.isra.0+0x58/0xa0
 00510  filemap_get_pages+0x454/0x7b0
 00510  filemap_read+0xdc/0x418
 00510  bch2_read_iter+0x100/0x1b0
 00510  vfs_read+0x214/0x300
 00510  ksys_read+0x6c/0x108
 00510  __arm64_sys_read+0x20/0x30
 00510  invoke_syscall.constprop.0+0x54/0xe8
 00510  do_el0_svc+0x44/0xc8
 00510  el0_svc+0x18/0x58
 00510  el0t_64_sync_handler+0x104/0x130
 00510  el0t_64_sync+0x154/0x158
 00510 Code: d5384100 f9401c01 b9401aa3 b40002e1 (f8227881)
 00510 ---[ end trace 0000000000000000 ]---
 00510 Kernel panic - not syncing: Oops: Fatal exception
 00510 SMP: stopping secondary CPUs
 00510 Kernel Offset: disabled
 00510 CPU features: 0x0000,000000e0,00000410,8240500b
 00510 Memory Limit: none

 Investigation indicates that these bits are already set when we allocate
 slab page and are not zeroed out after allocation. We are not yet sure
 why these crashes start happening only recently but regardless of the
 reason, not initializing a field that gets used later is wrong. Fix it
 by initializing slab->obj_exts during slab page allocation.

 The Linux kernel CVE team has assigned CVE-2025-37774 to this issue.


 Affected and fixed versions
 ===========================

 	Issue introduced in 6.10 with commit 21c690a349baab895dc68ab70d291e1598d7109d and fixed in 6.12.25 with commit 8baa747193591410a853bac9c3710142dfa4937b
 	Issue introduced in 6.10 with commit 21c690a349baab895dc68ab70d291e1598d7109d and fixed in 6.14.4 with commit 28bef6622a1a874fe63aceeb0c684fab75afb3ae
 	Issue introduced in 6.10 with commit 21c690a349baab895dc68ab70d291e1598d7109d and fixed in 6.15 with commit d2f5819b6ed357c0c350c0616b6b9f38be59adf6

 Please see https://www.kernel.org for a full list of currently supported
 kernel versions by the kernel community.

 Unaffected versions might change over time as fixes are backported to
 older supported kernel versions.  The official CVE entry at
 	https://cve.org/CVERecord/?id=CVE-2025-37774
 will be updated if fixes are backported, please check that for the most
 up to date information about this issue.


 Affected files
 ==============

 The file(s) affected by this issue are:
 	mm/slub.c


 Mitigation
 ==========

 The Linux kernel CVE team recommends that you update to the latest
 stable kernel version for this, and many other bugfixes.  Individual
 changes are never tested alone, but rather are part of a larger kernel
 release.  Cherry-picking individual commits is not recommended or
 supported by the Linux kernel community at all.  If however, updating to
 the latest release is impossible, the individual changes to resolve this
 issue can be found at these commits:
 	https://git.kernel.org/stable/c/8baa747193591410a853bac9c3710142dfa4937b
 	https://git.kernel.org/stable/c/28bef6622a1a874fe63aceeb0c684fab75afb3ae
 	https://git.kernel.org/stable/c/d2f5819b6ed357c0c350c0616b6b9f38be59adf6
	From bippy-1.2.0 Mon Sep 17 00:00:00 2001
	From: Greg Kroah-Hartman <gregkh@kernel.org>
	To: <linux-cve-announce@vger.kernel.org>
	Reply-to: <cve@kernel.org>, <linux-kernel@vger.kernel.org>
	Subject: CVE-2025-37774: slab: ensure slab->obj_exts is clear in a newly allocated slab page

	Description
	===========

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

	slab: ensure slab->obj_exts is clear in a newly allocated slab page

	ktest recently reported crashes while running several buffered io tests
	with __alloc_tagging_slab_alloc_hook() at the top of the crash call stack.
	The signature indicates an invalid address dereference with low bits of
	slab->obj_exts being set. The bits were outside of the range used by
	page_memcg_data_flags and objext_flags and hence were not masked out
	by slab_obj_exts() when obtaining the pointer stored in slab->obj_exts.
	The typical crash log looks like this:

	00510 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010
	00510 Mem abort info:
	00510 ESR = 0x0000000096000045
	00510 EC = 0x25: DABT (current EL), IL = 32 bits
	00510 SET = 0, FnV = 0
	00510 EA = 0, S1PTW = 0
	00510 FSC = 0x05: level 1 translation fault
	00510 Data abort info:
	00510 ISV = 0, ISS = 0x00000045, ISS2 = 0x00000000
	00510 CM = 0, WnR = 1, TnD = 0, TagAccess = 0
	00510 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
	00510 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000104175000
	00510 [0000000000000010] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
	00510 Internal error: Oops: 0000000096000045 [#1] SMP
	00510 Modules linked in:
	00510 CPU: 10 UID: 0 PID: 7692 Comm: cat Not tainted 6.15.0-rc1-ktest-g189e17946605 #19327 NONE
	00510 Hardware name: linux,dummy-virt (DT)
	00510 pstate: 20001005 (nzCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--)
	00510 pc : __alloc_tagging_slab_alloc_hook+0xe0/0x190
	00510 lr : __kmalloc_noprof+0x150/0x310
	00510 sp : ffffff80c87df6c0
	00510 x29: ffffff80c87df6c0 x28: 000000000013d1ff x27: 000000000013d200
	00510 x26: ffffff80c87df9e0 x25: 0000000000000000 x24: 0000000000000001
	00510 x23: ffffffc08041953c x22: 000000000000004c x21: ffffff80c0002180
	00510 x20: fffffffec3120840 x19: ffffff80c4821000 x18: 0000000000000000
	00510 x17: fffffffec3d02f00 x16: fffffffec3d02e00 x15: fffffffec3d00700
	00510 x14: fffffffec3d00600 x13: 0000000000000200 x12: 0000000000000006
	00510 x11: ffffffc080bb86c0 x10: 0000000000000000 x9 : ffffffc080201e58
	00510 x8 : ffffff80c4821060 x7 : 0000000000000000 x6 : 0000000055555556
	00510 x5 : 0000000000000001 x4 : 0000000000000010 x3 : 0000000000000060
	00510 x2 : 0000000000000000 x1 : ffffffc080f50cf8 x0 : ffffff80d801d000
	00510 Call trace:
	00510 __alloc_tagging_slab_alloc_hook+0xe0/0x190 (P)
	00510 __kmalloc_noprof+0x150/0x310
	00510 __bch2_folio_create+0x5c/0xf8
	00510 bch2_folio_create+0x2c/0x40
	00510 bch2_readahead+0xc0/0x460
	00510 read_pages+0x7c/0x230
	00510 page_cache_ra_order+0x244/0x3a8
	00510 page_cache_async_ra+0x124/0x170
	00510 filemap_readahead.isra.0+0x58/0xa0
	00510 filemap_get_pages+0x454/0x7b0
	00510 filemap_read+0xdc/0x418
	00510 bch2_read_iter+0x100/0x1b0
	00510 vfs_read+0x214/0x300
	00510 ksys_read+0x6c/0x108
	00510 __arm64_sys_read+0x20/0x30
	00510 invoke_syscall.constprop.0+0x54/0xe8
	00510 do_el0_svc+0x44/0xc8
	00510 el0_svc+0x18/0x58
	00510 el0t_64_sync_handler+0x104/0x130
	00510 el0t_64_sync+0x154/0x158
	00510 Code: d5384100 f9401c01 b9401aa3 b40002e1 (f8227881)
	00510 ---[ end trace 0000000000000000 ]---
	00510 Kernel panic - not syncing: Oops: Fatal exception
	00510 SMP: stopping secondary CPUs
	00510 Kernel Offset: disabled
	00510 CPU features: 0x0000,000000e0,00000410,8240500b
	00510 Memory Limit: none

	Investigation indicates that these bits are already set when we allocate
	slab page and are not zeroed out after allocation. We are not yet sure
	why these crashes start happening only recently but regardless of the
	reason, not initializing a field that gets used later is wrong. Fix it
	by initializing slab->obj_exts during slab page allocation.

	The Linux kernel CVE team has assigned CVE-2025-37774 to this issue.


	Affected and fixed versions
	===========================

	Issue introduced in 6.10 with commit 21c690a349baab895dc68ab70d291e1598d7109d and fixed in 6.12.25 with commit 8baa747193591410a853bac9c3710142dfa4937b
	Issue introduced in 6.10 with commit 21c690a349baab895dc68ab70d291e1598d7109d and fixed in 6.14.4 with commit 28bef6622a1a874fe63aceeb0c684fab75afb3ae
	Issue introduced in 6.10 with commit 21c690a349baab895dc68ab70d291e1598d7109d and fixed in 6.15 with commit d2f5819b6ed357c0c350c0616b6b9f38be59adf6

	Please see https://www.kernel.org for a full list of currently supported
	kernel versions by the kernel community.

	Unaffected versions might change over time as fixes are backported to
	older supported kernel versions. The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2025-37774
	will be updated if fixes are backported, please check that for the most
	up to date information about this issue.


	Affected files
	==============

	The file(s) affected by this issue are:
	mm/slub.c


	Mitigation
	==========

	The Linux kernel CVE team recommends that you update to the latest
	stable kernel version for this, and many other bugfixes. Individual
	changes are never tested alone, but rather are part of a larger kernel
	release. Cherry-picking individual commits is not recommended or
	supported by the Linux kernel community at all. If however, updating to
	the latest release is impossible, the individual changes to resolve this
	issue can be found at these commits:
	https://git.kernel.org/stable/c/8baa747193591410a853bac9c3710142dfa4937b
	https://git.kernel.org/stable/c/28bef6622a1a874fe63aceeb0c684fab75afb3ae
	https://git.kernel.org/stable/c/d2f5819b6ed357c0c350c0616b6b9f38be59adf6