linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] selinux: avc: mark avc node as not a leak
@ 2019-01-09  8:39 Prateek Patel
  2019-01-09 11:31 ` Catalin Marinas
  0 siblings, 1 reply; 3+ messages in thread
From: Prateek Patel @ 2019-01-09  8:39 UTC (permalink / raw)
  To: paul, sds, eparis, linux-kernel, catalin.marinas, selinux
  Cc: linux-tegra, talho, swarren, prpatel, linux-mm, snikam, vdumpa,
	Sri Krishna chowdary

From: Sri Krishna chowdary <schowdary@nvidia.com>

kmemleak detects allocated objects as leaks if not accessed for
default scan time. The memory allocated using avc_alloc_node
is freed using rcu mechanism when nodes are reclaimed or on
avc_flush. So, there is no real leak here and kmemleak_scan
detects it as a leak which is false positive. Hence, mark it as
kmemleak_not_leak.

Following is the log for avc_alloc_node detected as leak:
unreferenced object 0xffffffc0dd1a0e60 (size 64):
  comm "InputDispatcher", pid 648, jiffies 4294944629 (age 698.180s)
  hex dump (first 32 bytes):
    ed 00 00 00 ed 00 00 00 17 00 00 00 3f fe 41 00  ............?.A.
    00 00 00 00 ff ff ff ff 01 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffc000192390>] __save_stack_trace+0x24/0x34
    [<ffffffc000192dcc>] create_object+0x13c/0x290
    [<ffffffc000b926f0>] kmemleak_alloc+0x80/0xbc
    [<ffffffc00018e018>] kmem_cache_alloc+0x128/0x1f8
    [<ffffffc000313d40>] avc_alloc_node+0x2c/0x1e8
    [<ffffffc000313f34>] avc_insert+0x38/0x13c
    [<ffffffc000314084>] avc_compute_av+0x4c/0x60
    [<ffffffc00031461c>] avc_has_perm_flags+0x90/0x188
    [<ffffffc000319430>] sock_has_perm+0x84/0x98
    [<ffffffc0003194e4>] selinux_socket_sendmsg+0x1c/0x28
    [<ffffffc000312f58>] security_socket_sendmsg+0x14/0x20
    [<ffffffc0009c60c4>] sock_sendmsg+0x70/0xc8
    [<ffffffc0009c8884>] SyS_sendto+0x140/0x1ec
    [<ffffffc0000853c0>] el0_svc_naked+0x34/0x38
    [<ffffffffffffffff>] 0xffffffffffffffff

Signed-off-by: Sri Krishna chowdary <schowdary@nvidia.com>
Signed-off-by: Prateek <prpatel@nvidia.com>
---
 security/selinux/avc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/security/selinux/avc.c b/security/selinux/avc.c
index 635e5c1..ecfd0cd 100644
--- a/security/selinux/avc.c
+++ b/security/selinux/avc.c
@@ -30,6 +30,7 @@
 #include <linux/audit.h>
 #include <linux/ipv6.h>
 #include <net/ipv6.h>
+#include <linux/kmemleak.h>
 #include "avc.h"
 #include "avc_ss.h"
 #include "classmap.h"
@@ -573,6 +574,7 @@ static struct avc_node *avc_alloc_node(struct selinux_avc *avc)
 	if (!node)
 		goto out;
 
+	kmemleak_not_leak(node);
 	INIT_HLIST_NODE(&node->list);
 	avc_cache_stats_incr(allocations);
 
-- 
2.7.4


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] selinux: avc: mark avc node as not a leak
  2019-01-09  8:39 [PATCH] selinux: avc: mark avc node as not a leak Prateek Patel
@ 2019-01-09 11:31 ` Catalin Marinas
  2019-01-24 21:56   ` Prateek Patel
  0 siblings, 1 reply; 3+ messages in thread
From: Catalin Marinas @ 2019-01-09 11:31 UTC (permalink / raw)
  To: Prateek Patel
  Cc: paul, sds, eparis, linux-kernel, selinux, linux-tegra, talho,
	swarren, linux-mm, snikam, vdumpa, Sri Krishna chowdary

Hi Prateek,

On Wed, Jan 09, 2019 at 02:09:22PM +0530, Prateek Patel wrote:
> From: Sri Krishna chowdary <schowdary@nvidia.com>
> 
> kmemleak detects allocated objects as leaks if not accessed for
> default scan time. The memory allocated using avc_alloc_node
> is freed using rcu mechanism when nodes are reclaimed or on
> avc_flush. So, there is no real leak here and kmemleak_scan
> detects it as a leak which is false positive. Hence, mark it as
> kmemleak_not_leak.

In theory, kmemleak should detect the node->rhead in the lists used by
call_rcu() and not report it as a leak. Which RCU options do you have
enabled (just to check whether kmemleak tracks the RCU internal lists)?

Also, does this leak eventually disappear without your patch? Does

  echo dump=0xffffffc0dd1a0e60 > /sys/kernel/debug/kmemleak

still display this object?

Thanks.

-- 
Catalin

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] selinux: avc: mark avc node as not a leak
  2019-01-09 11:31 ` Catalin Marinas
@ 2019-01-24 21:56   ` Prateek Patel
  0 siblings, 0 replies; 3+ messages in thread
From: Prateek Patel @ 2019-01-24 21:56 UTC (permalink / raw)
  To: Catalin Marinas
  Cc: paul, sds, eparis, linux-kernel, selinux, linux-tegra, talho,
	swarren, linux-mm, snikam, vdumpa


On 1/9/2019 5:01 PM, Catalin Marinas wrote:
> Hi Prateek,
>
> On Wed, Jan 09, 2019 at 02:09:22PM +0530, Prateek Patel wrote:
>> From: Sri Krishna chowdary <schowdary@nvidia.com>
>>
>> kmemleak detects allocated objects as leaks if not accessed for
>> default scan time. The memory allocated using avc_alloc_node
>> is freed using rcu mechanism when nodes are reclaimed or on
>> avc_flush. So, there is no real leak here and kmemleak_scan
>> detects it as a leak which is false positive. Hence, mark it as
>> kmemleak_not_leak.
> In theory, kmemleak should detect the node->rhead in the lists used by
> call_rcu() and not report it as a leak. Which RCU options do you have
> enabled (just to check whether kmemleak tracks the RCU internal lists)?
>
> Also, does this leak eventually disappear without your patch? Does
>
>    echo dump=0xffffffc0dd1a0e60 > /sys/kernel/debug/kmemleak
>
> still display this object?
>
> Thanks.
Hi Catalin,
It was intermittently showing leak and didn't repro on multiple runs. To 
repo, I decreased the
minimum object age for reporting, I found triggering the second scan 
just after first is not showing
any leak. Also, without my patch, on echo dump, obj is not displaying.
Is increasing minimum object age for reporting a good idea to handle 
such type of issues to
avoid false-positives?

Following is the log:

t186_int:/ # echo scan > /sys/kernel/debug/kmemleak
t186_int:/ # cat /sys/kernel/debug/kmemleak

unreferenced object 0xffffffc1e06424c8 (size 72):
   comm "netd", pid 4891, jiffies 4294906431 (age 23.120s)
   hex dump (first 32 bytes):
     97 01 00 00 1b 00 00 00 0b 00 00 00 57 06 04 00 ............W...
     00 00 00 00 ff ff ff ff 01 00 00 00 00 00 00 00 ................
   backtrace:
     [<ffffff8008275214>] kmem_cache_alloc+0x1ac/0x2c0
     [<ffffff80084dcf90>] avc_alloc_node+0x28/0x240
     [<ffffff80084dd404>] avc_compute_av+0xa4/0x1d0
     [<ffffff80084de1b8>] avc_has_perm+0xf8/0x1b8
     [<ffffff80084e37f8>] file_has_perm+0xb8/0xe8
     [<ffffff80084e3d64>] match_file+0x44/0x98
     [<ffffff80082cc9d4>] iterate_fd+0x84/0xd0
     [<ffffff80084e2b3c>] selinux_bprm_committing_creds+0xec/0x230
     [<ffffff80084d842c>] security_bprm_committing_creds+0x44/0x60
     [<ffffff80082ad020>] install_exec_creds+0x20/0x70
     [<ffffff800831b9a4>] load_elf_binary+0x31c/0xd10
     [<ffffff80082ae530>] search_binary_handler+0x98/0x288
     [<ffffff80082af078>] do_execveat_common.isra.14+0x550/0x6d0
     [<ffffff80082af4ac>] SyS_execve+0x4c/0x60
     [<ffffff80080839c0>] el0_svc_naked+0x34/0x38
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffffffc1ab3c61b0 (size 72):
   comm "crash_dump64", pid 5058, jiffies 4294907834 (age 17.508s)
   hex dump (first 32 bytes):
     2f 02 00 00 6b 00 00 00 07 00 00 00 53 04 04 00 /...k.......S...
     00 00 00 00 ff ff fd ff 01 00 00 00 00 00 00 00 ................
   backtrace:
     [<ffffff8008275214>] kmem_cache_alloc+0x1ac/0x2c0
     [<ffffff80084dcf90>] avc_alloc_node+0x28/0x240
     [<ffffff80084dd404>] avc_compute_av+0xa4/0x1d0
     [<ffffff80084de084>] avc_has_perm_noaudit+0xe4/0x120
     [<ffffff80084e1264>] selinux_inode_permission+0xc4/0x1c8
     [<ffffff80084d8fe8>] security_inode_permission+0x60/0x88
     [<ffffff80082b2cf4>] __inode_permission2+0x54/0x120
     [<ffffff80082b2e30>] inode_permission2+0x38/0x80
     [<ffffff80082b4b58>] may_open+0x70/0x128
     [<ffffff80082b6fd4>] do_last+0x234/0xee8
     [<ffffff80082b7d30>] path_openat+0xa8/0x310
     [<ffffff80082b9390>] do_filp_open+0x88/0x108
     [<ffffff80082a1fec>] do_sys_open+0x1a4/0x290
     [<ffffff80082a215c>] SyS_openat+0x3c/0x50
     [<ffffff80080839c0>] el0_svc_naked+0x34/0x38
     [<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffffffc1d3bcf678 (size 72):
   comm "mediaserver", pid 5156, jiffies 4294909577 (age 10.536s)
   hex dump (first 32 bytes):
     0b 02 00 00 e2 01 00 00 07 00 00 00 53 04 04 00 ............S...
     00 00 00 00 f7 ff ff ff 01 00 00 00 00 00 00 00 ................
   backtrace:
     [<ffffff8008275214>] kmem_cache_alloc+0x1ac/0x2c0
     [<ffffff80084dcf90>] avc_alloc_node+0x28/0x240
     [<ffffff80084dd404>] avc_compute_av+0xa4/0x1d0
     [<ffffff80084de084>] avc_has_perm_noaudit+0xe4/0x120
     [<ffffff80084e1264>] selinux_inode_permission+0xc4/0x1c8
     [<ffffff80084d8fe8>] security_inode_permission+0x60/0x88
     [<ffffff80082b2cf4>] __inode_permission2+0x54/0x120
     [<ffffff80082b2e30>] inode_permission2+0x38/0x80
     [<ffffff80082b4b58>] may_open+0x70/0x128
     [<ffffff80082b6fd4>] do_last+0x234/0xee8
     [<ffffff80082b7d30>] path_openat+0xa8/0x310
     [<ffffff80082b9390>] do_filp_open+0x88/0x108
     [<ffffff80082a1fec>] do_sys_open+0x1a4/0x290
     [<ffffff80082a21f4>] compat_SyS_openat+0x3c/0x50
     [<ffffff80080839c0>] el0_svc_naked+0x34/0x38
     [<ffffffffffffffff>] 0xffffffffffffffff
t186_int:/ # echo dump=0xffffffc1d3bcf678 > /sys/kernel/debug/kmemleak
kmemleak: Unknown object at 0xffffffc1d3bcf678

Thanks,


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-01-24 21:57 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-09  8:39 [PATCH] selinux: avc: mark avc node as not a leak Prateek Patel
2019-01-09 11:31 ` Catalin Marinas
2019-01-24 21:56   ` Prateek Patel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).