lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250514151605.9a07943954737f52e2895b05@linux-foundation.org>
Date: Wed, 14 May 2025 15:16:05 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Jared Kangas <jkangas@...hat.com>
Cc: willy@...radead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] radix tree: fix kmemleak false positive in
 radix_tree_shrink()

On Wed, 14 May 2025 11:01:37 -0700 Jared Kangas <jkangas@...hat.com> wrote:

> Kmemleak periodically produces a false positive report that resembles
> the following:
> 
> unreferenced object 0xffff00000db613b8 (size 576):
>   comm "systemd", pid 1, jiffies 4294987015
>   hex dump (first 32 bytes):
>     00 22 01 00 00 00 00 00 28 1c d5 c5 00 00 ff ff  ."......(.......
>     10 e4 6c c0 00 00 ff ff d0 13 b6 0d 00 00 ff ff  ..l.............
>   backtrace (crc 520d6e1c):
>     kmemleak_alloc+0xb4/0xc4
>     kmem_cache_alloc+0x288/0x2b0
>     radix_tree_node_alloc.constprop.0+0x214/0x364
>     idr_get_free+0x3d0/0x690
>     idr_alloc_u32+0x120/0x280
>     idr_alloc_cyclic+0xe8/0x1b4
>     __kernfs_new_node+0x118/0x5a0
>     kernfs_create_dir_ns+0x8c/0x1fc
>     cgroup_create+0x1cc/0x8a0
>     cgroup_mkdir+0x13c/0x90c
>     kernfs_iop_mkdir+0x108/0x184
>     vfs_mkdir+0x3c8/0x5f0
>     do_mkdirat+0x218/0x290
>     __arm64_sys_mkdirat+0xe0/0x140
>     invoke_syscall.constprop.0+0x74/0x1e4
>     do_el0_svc+0xd0/0x1dc
> 
> This is a transient leak that can be traced to radix_tree_shrink(): when
> root->xa_head is set, kmemleak may have already started traversing the
> radix tree. If this has happened, but kmemleak fails to scan the new
> xa_head before it moves, kmemleak will see it as a leak until the radix
> tree is scanned again.
> 
> Mark the new xa_head as a transient leak to prevent this false positive
> report.
> 
> ...
>
> --- a/lib/radix-tree.c
> +++ b/lib/radix-tree.c
> @@ -509,6 +509,14 @@ static inline bool radix_tree_shrink(struct radix_tree_root *root)
>  		if (is_idr(root) && !tag_get(node, IDR_FREE, 0))
>  			root_tag_clear(root, IDR_FREE);
>  
> +		/*
> +		 * Kmemleak might report a false positive if it traverses the
> +		 * tree while we're shrinking it, since the reference moves
> +		 * from node->slots[0] to root->xa_head.
> +		 */
> +		if (radix_tree_is_internal_node(child))
> +			kmemleak_transient_leak(entry_to_node(child));
> +

There is only one other caller of kmemleak_transient_leak().  Makes me
think that perhaps a more fundamental fix is needed.

So I'll queue it for testing for now, but I won't proceed further until
some further examination has occured.  Thanks.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ