* CVE-2023-52560: mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
@ 2024-03-02 21:59 Greg Kroah-Hartman
2024-03-05 16:51 ` Michal Hocko
0 siblings, 1 reply; 6+ messages in thread
From: Greg Kroah-Hartman @ 2024-03-02 21:59 UTC (permalink / raw)
To: linux-cve-announce; +Cc: Greg Kroah-Hartman
Description
===========
In the Linux kernel, the following vulnerability has been resolved:
mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y
and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.
Since commit 9f86d624292c ("mm/damon/vaddr-test: remove unnecessary
variables"), the damon_destroy_ctx() is removed, but still call
damon_new_target() and damon_new_region(), the damon_region which is
allocated by kmem_cache_alloc() in damon_new_region() and the damon_target
which is allocated by kmalloc in damon_new_target() are not freed. And
the damon_region which is allocated in damon_new_region() in
damon_set_regions() is also not freed.
So use damon_destroy_target to free all the damon_regions and damon_target.
unreferenced object 0xffff888107c9a940 (size 64):
comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk
60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff `...............
backtrace:
[<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
[<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
[<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
[<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff8881079cc740 (size 56):
comm "kunit_try_catch", pid 1069, jiffies 4294670592 (age 732.761s)
hex dump (first 32 bytes):
05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................
6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
backtrace:
[<ffffffff819bc492>] damon_new_region+0x22/0x1c0
[<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
[<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888107c9ac40 (size 64):
comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk
a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff ........x.v.....
backtrace:
[<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
[<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
[<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
[<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff8881079ccc80 (size 56):
comm "kunit_try_catch", pid 1071, jiffies 4294670595 (age 732.843s)
hex dump (first 32 bytes):
05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................
6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
backtrace:
[<ffffffff819bc492>] damon_new_region+0x22/0x1c0
[<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
[<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888107c9af40 (size 64):
comm "kunit_try_catch", pid 1073, jiffies 4294670597 (age 733.011s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b ............kkkk
20 a2 76 07 81 88 ff ff b8 a6 76 07 81 88 ff ff .v.......v.....
backtrace:
[<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
[<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
[<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
[<ffffffff819c877e>] damon_test_apply_three_regions3+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810776a200 (size 56):
comm "kunit_try_catch", pid 1073, jiffies 4294670597 (age 733.011s)
hex dump (first 32 bytes):
05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ................
6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
backtrace:
[<ffffffff819bc492>] damon_new_region+0x22/0x1c0
[<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
[<ffffffff819c877e>] damon_test_apply_three_regions3+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810776a740 (size 56):
comm "kunit_try_catch", pid 1073, jiffies 4294670597 (age 733.025s)
hex dump (first 32 bytes):
3d 00 00 00 00 00 00 00 3f 00 00 00 00 00 00 00 =.......?.......
6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
backtrace:
[<ffffffff819bc492>] damon_new_region+0x22/0x1c0
[<ffffffff819bfcc2>] damon_set_regions+0x4c2/0x8e0
[<ffffffff819c7dbb>] damon_do_test_apply_three_regions.constprop.0+0xfb/0x3e0
[<ffffffff819c877e>] damon_test_apply_three_regions3+0x21e/0x260
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff888108038240 (size 64):
comm "kunit_try_catch", pid 1075, jiffies 4294670600 (age 733.022s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 03 00 00 00 6b 6b 6b 6b ............kkkk
48 ad 76 07 81 88 ff ff 98 ae 76 07 81 88 ff ff H.v.......v.....
backtrace:
[<ffffffff817e0167>] kmalloc_trace+0x27/0xa0
[<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0
[<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
[<ffffffff819c898d>] damon_test_apply_three_regions4+0x1cd/0x210
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
unreferenced object 0xffff88810776ad28 (size 56):
comm "kunit_try_catch", pid 1075, jiffies 4294670600 (age 733.022s)
hex dump (first 32 bytes):
05 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 ................
6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk....kkkk
backtrace:
[<ffffffff819bc492>] damon_new_region+0x22/0x1c0
[<ffffffff819bfcc2>] damon_set_regions+0x4c2/0x8e0
[<ffffffff819c7dbb>] damon_do_test_apply_three_regions.constprop.0+0xfb/0x3e0
[<ffffffff819c898d>] damon_test_apply_three_regions4+0x1cd/0x210
[<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90
[<ffffffff81237cf6>] kthread+0x2b6/0x380
[<ffffffff81097add>] ret_from_fork+0x2d/0x70
[<ffffffff81003791>] ret_from_fork_asm+0x11/0x20
The Linux kernel CVE team has assigned CVE-2023-52560 to this issue.
Affected and fixed versions
===========================
Issue introduced in 5.16 with commit 9f86d624292c and fixed in 6.1.56 with commit 9a4fe81a8644
Issue introduced in 5.16 with commit 9f86d624292c and fixed in 6.5.6 with commit 6b522001693a
Issue introduced in 5.16 with commit 9f86d624292c and fixed in 6.6 with commit 45120b15743f
Please see https://www.kernel.org or 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-2023-52560
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/damon/vaddr-test.h
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/9a4fe81a8644b717d57d81ce5849e16583b13fe8
https://git.kernel.org/stable/c/6b522001693aa113d97a985abc5f6932972e8e86
https://git.kernel.org/stable/c/45120b15743fa7c0aa53d5db6dfb4c8f87be4abd
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CVE-2023-52560: mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
2024-03-02 21:59 CVE-2023-52560: mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions() Greg Kroah-Hartman
@ 2024-03-05 16:51 ` Michal Hocko
2024-03-05 22:25 ` Greg Kroah-Hartman
0 siblings, 1 reply; 6+ messages in thread
From: Michal Hocko @ 2024-03-05 16:51 UTC (permalink / raw)
To: cve, linux-kernel; +Cc: Greg Kroah-Hartman
On Sat 02-03-24 22:59:54, Greg KH wrote:
> Description
> ===========
>
> In the Linux kernel, the following vulnerability has been resolved:
>
> mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
>
> When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y
> and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.
This is a kunit test case AFAICS. Is this really a CVE material?
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CVE-2023-52560: mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
2024-03-05 16:51 ` Michal Hocko
@ 2024-03-05 22:25 ` Greg Kroah-Hartman
2024-03-06 7:49 ` Michal Hocko
0 siblings, 1 reply; 6+ messages in thread
From: Greg Kroah-Hartman @ 2024-03-05 22:25 UTC (permalink / raw)
To: Michal Hocko; +Cc: cve, linux-kernel
On Tue, Mar 05, 2024 at 05:51:11PM +0100, Michal Hocko wrote:
> On Sat 02-03-24 22:59:54, Greg KH wrote:
> > Description
> > ===========
> >
> > In the Linux kernel, the following vulnerability has been resolved:
> >
> > mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
> >
> > When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y
> > and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.
>
> This is a kunit test case AFAICS. Is this really a CVE material?
People run kunit tests on real systems (again, we do not dictate use
cases.) So yes, fixing a memory leak that can be triggered is resolving
a weakness and so should get a CVE I would think, right?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CVE-2023-52560: mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
2024-03-05 22:25 ` Greg Kroah-Hartman
@ 2024-03-06 7:49 ` Michal Hocko
2024-03-06 8:42 ` Greg Kroah-Hartman
0 siblings, 1 reply; 6+ messages in thread
From: Michal Hocko @ 2024-03-06 7:49 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: cve, linux-kernel
On Tue 05-03-24 22:25:11, Greg KH wrote:
> On Tue, Mar 05, 2024 at 05:51:11PM +0100, Michal Hocko wrote:
> > On Sat 02-03-24 22:59:54, Greg KH wrote:
> > > Description
> > > ===========
> > >
> > > In the Linux kernel, the following vulnerability has been resolved:
> > >
> > > mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
> > >
> > > When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y
> > > and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.
> >
> > This is a kunit test case AFAICS. Is this really a CVE material?
>
> People run kunit tests on real systems (again, we do not dictate use
> cases.) So yes, fixing a memory leak that can be triggered is resolving
> a weakness and so should get a CVE I would think, right?
This is stretching the meaning of CVE beyond my imagination. Up to you
to decide but I yet have to see a real production system that casually
runs unit test just for <looking for a reason .... but failed>.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CVE-2023-52560: mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
2024-03-06 7:49 ` Michal Hocko
@ 2024-03-06 8:42 ` Greg Kroah-Hartman
2024-03-06 8:56 ` Michal Hocko
0 siblings, 1 reply; 6+ messages in thread
From: Greg Kroah-Hartman @ 2024-03-06 8:42 UTC (permalink / raw)
To: Michal Hocko; +Cc: cve, linux-kernel
On Wed, Mar 06, 2024 at 08:49:42AM +0100, Michal Hocko wrote:
> On Tue 05-03-24 22:25:11, Greg KH wrote:
> > On Tue, Mar 05, 2024 at 05:51:11PM +0100, Michal Hocko wrote:
> > > On Sat 02-03-24 22:59:54, Greg KH wrote:
> > > > Description
> > > > ===========
> > > >
> > > > In the Linux kernel, the following vulnerability has been resolved:
> > > >
> > > > mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
> > > >
> > > > When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y
> > > > and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.
> > >
> > > This is a kunit test case AFAICS. Is this really a CVE material?
> >
> > People run kunit tests on real systems (again, we do not dictate use
> > cases.) So yes, fixing a memory leak that can be triggered is resolving
> > a weakness and so should get a CVE I would think, right?
>
> This is stretching the meaning of CVE beyond my imagination. Up to you
> to decide but I yet have to see a real production system that casually
> runs unit test just for <looking for a reason .... but failed>.
I know of at least one place that uses kunit tests in "production", and
I know of more that will be enabling them in newer releases, so this is
a real thing. Again, we just mark "fixes for a weakness" as a CVE and
let others decide what to do with it.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: CVE-2023-52560: mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
2024-03-06 8:42 ` Greg Kroah-Hartman
@ 2024-03-06 8:56 ` Michal Hocko
0 siblings, 0 replies; 6+ messages in thread
From: Michal Hocko @ 2024-03-06 8:56 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: cve, linux-kernel
On Wed 06-03-24 08:42:07, Greg KH wrote:
> On Wed, Mar 06, 2024 at 08:49:42AM +0100, Michal Hocko wrote:
> > On Tue 05-03-24 22:25:11, Greg KH wrote:
> > > On Tue, Mar 05, 2024 at 05:51:11PM +0100, Michal Hocko wrote:
> > > > On Sat 02-03-24 22:59:54, Greg KH wrote:
> > > > > Description
> > > > > ===========
> > > > >
> > > > > In the Linux kernel, the following vulnerability has been resolved:
> > > > >
> > > > > mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
> > > > >
> > > > > When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y
> > > > > and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.
> > > >
> > > > This is a kunit test case AFAICS. Is this really a CVE material?
> > >
> > > People run kunit tests on real systems (again, we do not dictate use
> > > cases.) So yes, fixing a memory leak that can be triggered is resolving
> > > a weakness and so should get a CVE I would think, right?
> >
> > This is stretching the meaning of CVE beyond my imagination. Up to you
> > to decide but I yet have to see a real production system that casually
> > runs unit test just for <looking for a reason .... but failed>.
>
> I know of at least one place that uses kunit tests in "production", and
> I know of more that will be enabling them in newer releases, so this is
> a real thing.
I would be really curious to hear more details.
> Again, we just mark "fixes for a weakness" as a CVE and
> let others decide what to do with it.
OK, this is something we have discussed and concluded to disagree. Not
my call though but I would really like to hear _who_ outside of the stable
tree userbase is really appreciating this approach.
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-03-06 8:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-03-02 21:59 CVE-2023-52560: mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions() Greg Kroah-Hartman
2024-03-05 16:51 ` Michal Hocko
2024-03-05 22:25 ` Greg Kroah-Hartman
2024-03-06 7:49 ` Michal Hocko
2024-03-06 8:42 ` Greg Kroah-Hartman
2024-03-06 8:56 ` Michal Hocko
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.