Bug 848928 - BUG: memory leak in SELinux
BUG: memory leak in SELinux
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Paul Moore
Fedora Extras Quality Assurance
: FutureFeature, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-16 16:37 EDT by Mike Snitzer
Modified: 2017-06-15 14:10 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-23 13:24:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mike Snitzer 2012-08-16 16:37:58 EDT
Description of problem:

I keep kmemleak enabled while developing/testing code.  I've been seeing
kmemleak report this leak for at least v3.4 and v3.5 (haven't tested
v3.6 yet):

unreferenced object 0xffff880324f6cd60 (size 32):
  comm "kthreadd", pid 2, jiffies 4294704184 (age 83615.009s)
  hex dump (first 32 bytes):
    01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff814b740e>] kmemleak_alloc+0x5e/0xc0
    [<ffffffff8114c777>] __kmalloc_track_caller+0x137/0x260
    [<ffffffff8111cd6d>] kmemdup+0x2d/0x60
    [<ffffffff811f50ef>] selinux_cred_prepare+0x1f/0x40
    [<ffffffff811f1ab6>] security_prepare_creds+0x16/0x20
    [<ffffffff81068c72>] prepare_creds+0x92/0xb0
    [<ffffffff81069259>] copy_creds+0x79/0x1c0
    [<ffffffff8103c40b>] copy_process+0x1ab/0xed0
    [<ffffffff8103d464>] do_fork+0x54/0x260
    [<ffffffff8100aea6>] kernel_thread+0x76/0x80
    [<ffffffff81061b8a>] kthreadd+0x25a/0x290
    [<ffffffff814d81e4>] kernel_thread_helper+0x4/0x10
    [<ffffffffffffffff>] 0xffffffffffffffff

After the first boot (of a RHEL6.2 distro) with these upstream kernels I
see nearly 500 instances of this leak.  And while the system is up I'll
periodically get more coming in.  Could be false-positives but kmemleak
has found 3 nasty leaks in DM code for me so I'm inclined to trust it.

It should be noted that I have SELINUX=disabled.

I haven't put my finger on what is triggering the leaks but it happens
so frequently that simply booting/running the kernel will expose these
leaks.
Comment 1 Mike Snitzer 2012-08-17 18:17:12 EDT
(In reply to comment #0)
> Description of problem:
> 
> I keep kmemleak enabled while developing/testing code.  I've been seeing
> kmemleak report this leak for at least v3.4 and v3.5 (haven't tested
> v3.6 yet):

FYI, I'm seeing a wider variety of memory leaks with v3.6-rc2:

kmemleak: 417 new suspected memory leaks (see /sys/kernel/debug/kmemleak)

(all 417 are related to selinux, and again I have SELINUX=disabled)

unreferenced object 0xffff88033f001540 (size 32):
  comm "swapper/0", pid 0, jiffies 4294667400 (age 900.820s)
  hex dump (first 32 bytes):
    01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff814bc9be>] kmemleak_alloc+0x5e/0xc0
    [<ffffffff81151a3b>] __kmalloc_track_caller+0x14b/0x2d0
    [<ffffffff8112197d>] kmemdup+0x2d/0x60
    [<ffffffff811f3fbf>] selinux_cred_prepare+0x1f/0x40
    [<ffffffff811f0986>] security_prepare_creds+0x16/0x20
    [<ffffffff8106c562>] prepare_creds+0x92/0xb0
    [<ffffffff8106cb49>] copy_creds+0x79/0x1c0
    [<ffffffff8103f6db>] copy_process+0x1ab/0xec0
    [<ffffffff81040794>] do_fork+0x54/0x260
    [<ffffffff8100ae96>] kernel_thread+0x76/0x80
    [<ffffffff814ba9d1>] rest_init+0x21/0x80
    [<ffffffff81af9eed>] start_kernel+0x3d1/0x3de
    [<ffffffff81af9335>] x86_64_start_reservations+0x131/0x136
    [<ffffffff81af943d>] x86_64_start_kernel+0x103/0x112
    [<ffffffffffffffff>] 0xffffffffffffffff

unreferenced object 0xffff880328a757c0 (size 128):
  comm "swapper/0", pid 1, jiffies 4294670653 (age 897.573s)
  hex dump (first 32 bytes):
    00 80 ab 28 03 88 ff ff 03 00 00 00 05 00 00 00  ...(............
    03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff814bc9be>] kmemleak_alloc+0x5e/0xc0
    [<ffffffff811514cb>] kmem_cache_alloc_trace+0xdb/0x270
    [<ffffffff811fa8a5>] selinux_sb_alloc_security+0x25/0x90
    [<ffffffff811f05a6>] security_sb_alloc+0x16/0x20
    [<ffffffff81161b9d>] alloc_super+0x3d/0x330
    [<ffffffff811629b8>] sget+0x88/0x2b0
    [<ffffffff81162c1d>] mount_single+0x3d/0xd0
    [<ffffffff811fb738>] sel_mount+0x18/0x20
    [<ffffffff811627d3>] mount_fs+0x43/0x1a0
    [<ffffffff8117db92>] vfs_kern_mount+0x72/0x100
    [<ffffffff8117dc39>] kern_mount_data+0x19/0x30
    [<ffffffff81b1f358>] init_sel_fs+0x6a/0xa5
    [<ffffffff810001c2>] do_one_initcall+0x42/0x180
    [<ffffffff81af9646>] do_basic_setup+0x9d/0xbb
    [<ffffffff81af98b8>] kernel_init+0x1f9/0x27b
    [<ffffffff814dd9c4>] kernel_thread_helper+0x4/0x10

unreferenced object 0xffff88032891e348 (size 72):
  comm "swapper/0", pid 1, jiffies 4294670653 (age 897.573s)
  hex dump (first 32 bytes):
    30 99 85 2e 03 88 ff ff 00 58 a7 28 03 88 ff ff  0........X.(....
    08 e3 91 28 03 88 ff ff 01 00 00 00 03 00 00 00  ...(............
  backtrace:
    [<ffffffff814bc9be>] kmemleak_alloc+0x5e/0xc0
    [<ffffffff81151783>] kmem_cache_alloc+0x123/0x290
    [<ffffffff811f43c5>] selinux_inode_alloc_security+0x45/0xa0
    [<ffffffff811f074e>] security_inode_alloc+0x1e/0x20
    [<ffffffff8117a38a>] inode_init_always+0xca/0x1c0
    [<ffffffff8117a4ba>] alloc_inode+0x3a/0xa0
    [<ffffffff8117a533>] new_inode_pseudo+0x13/0x60
    [<ffffffff8117a59d>] new_inode+0x1d/0x40
    [<ffffffff8118371e>] simple_fill_super+0x4e/0x1f0
    [<ffffffff811fdaaa>] sel_fill_super+0x2a/0x2e0
    [<ffffffff81162c81>] mount_single+0xa1/0xd0
    [<ffffffff811fb738>] sel_mount+0x18/0x20
    [<ffffffff811627d3>] mount_fs+0x43/0x1a0
    [<ffffffff8117db92>] vfs_kern_mount+0x72/0x100
    [<ffffffff8117dc39>] kern_mount_data+0x19/0x30
    [<ffffffff81b1f358>] init_sel_fs+0x6a/0xa5

unreferenced object 0xffff8803280d92e0 (size 32):
  comm "udevd", pid 135, jiffies 4294672167 (age 1018.607s)
  hex dump (first 32 bytes):
    01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff814bc9be>] kmemleak_alloc+0x5e/0xc0
    [<ffffffff811514cb>] kmem_cache_alloc_trace+0xdb/0x270
    [<ffffffff811faa06>] selinux_file_alloc_security+0x46/0x70
    [<ffffffff811f07c6>] security_file_alloc+0x16/0x20
    [<ffffffff81160ea4>] get_empty_filp+0xa4/0x190
    [<ffffffff81160fbe>] alloc_file+0x2e/0xf0
    [<ffffffff8140ad6f>] sock_alloc_file+0xaf/0x130
    [<ffffffff8140ae09>] sock_map_fd+0x19/0x40
    [<ffffffff8140bc31>] sys_socket+0x51/0x80
    [<ffffffff814dc929>] system_call_fastpath+0x16/0x1b
    [<ffffffffffffffff>] 0xffffffffffffffff

unreferenced object 0xffff880326d674a0 (size 32):
  comm "load_policy", pid 459, jiffies 4294676623 (age 1129.198s)
  hex dump (first 32 bytes):
    01 00 00 00 01 00 00 00 03 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff814bc9be>] kmemleak_alloc+0x5e/0xc0
    [<ffffffff811514cb>] kmem_cache_alloc_trace+0xdb/0x270
    [<ffffffff811faa06>] selinux_file_alloc_security+0x46/0x70
    [<ffffffff811f07c6>] security_file_alloc+0x16/0x20
    [<ffffffff81160ea4>] get_empty_filp+0xa4/0x190
    [<ffffffff8116fec8>] path_openat+0x48/0x480
    [<ffffffff81170419>] do_filp_open+0x49/0xa0
    [<ffffffff8115ee48>] do_sys_open+0x108/0x1e0
    [<ffffffff8115ef61>] sys_open+0x21/0x30
    [<ffffffff814dc929>] system_call_fastpath+0x16/0x1b
    [<ffffffffffffffff>] 0xffffffffffffffff
Comment 2 Andrew Travneff 2012-10-20 04:37:25 EDT
I'm not sure it is related, but I had several kernel panics while booting with message like "unable to handle kernel paging request at 6d0000006d" and IP here:
kmem_cache_alloc_trace() 0x63/0x160
Called from: selinux_file_alloc_security()

Can't provide the entire log, sorry.

Kernel 3.6.2-4.fc17.x86_64
Comment 3 Fedora End Of Life 2013-04-03 10:49:52 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 4 Justin M. Forbes 2013-04-05 15:54:15 EDT
Is this still an issue with the 3.9 kernels in F19?
Comment 5 Mike Snitzer 2013-04-06 09:38:01 EDT
(In reply to comment #4)
> Is this still an issue with the 3.9 kernels in F19?

AFAIK it is.  But I've just been running stock 3.9-rc5 and seeing it like crazy so cannot see why F19 wouldn't also be affected.  But I'll defer to others who are actually running the F19 3.9 kernels...
Comment 6 Justin M. Forbes 2013-04-23 13:24:50 EDT
This bug is being closed with INSUFFICIENT_DATA as there has not been a
response in 2 weeks.  If you are still experiencing this issue,
please reopen and attach the relevant data from the latest kernel you are
running and any data that might have been requested previously.
Comment 7 Mike Snitzer 2013-04-23 15:34:41 EDT
(In reply to comment #6)
> This bug is being closed with INSUFFICIENT_DATA as there has not been a
> response in 2 weeks.  If you are still experiencing this issue,
> please reopen and attach the relevant data from the latest kernel you are
> running and any data that might have been requested previously.

I'm sorry but what you did there was really gross.  And yes, it is still happening even with 3.9-rc8 (with kmemleak enabled):

unreferenced object 0xffff88032d3d6520 (size 32):
  comm "load_policy", pid 467, jiffies 4294674360 (age 56995.147s)
  hex dump (first 32 bytes):
    01 00 00 00 01 00 00 00 03 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff814f515e>] kmemleak_alloc+0x5e/0xc0
    [<ffffffff8115ce75>] kmem_cache_alloc_trace+0xe5/0x230
    [<ffffffff8120d176>] selinux_file_alloc_security+0x46/0x70
    [<ffffffff81202e76>] security_file_alloc+0x16/0x20
    [<ffffffff8116e240>] get_empty_filp+0x90/0x1a0
    [<ffffffff8117ca68>] path_openat+0x48/0x460
    [<ffffffff8117cfb9>] do_filp_open+0x49/0xa0
    [<ffffffff8116ab98>] do_sys_open+0x108/0x1f0
    [<ffffffff8116acc1>] sys_open+0x21/0x30
    [<ffffffff81511719>] system_call_fastpath+0x16/0x1b
    [<ffffffffffffffff>] 0xffffffffffffffff

Closing this bug doesn't make it go away.

And the person you should be getting information from is Eric Paris or some other SE linux developer.  I've not gotten any indication that a relevant developer has even looked into this.
Comment 8 Justin M. Forbes 2013-04-23 15:40:55 EDT
Sorry, you got caught in the mass update of bugs that were moved from rawhide.  This was a mass update that closed 60 bugs or so, and I wasn't looking at them individually, you had responded before but needinfo was set for some reason still.
Comment 9 Stephen Smalley 2013-04-23 15:48:51 EDT
You said you have SELINUX=disabled?
Then it shouldn't even be calling those selinux_* functions anymore.
grep selinux /proc/filesystems
ls /sys/fs/selinux
echo 1 > /sys/fs/selinux/disable
Comment 10 Mike Snitzer 2013-04-23 15:56:04 EDT
(In reply to comment #9)
> You said you have SELINUX=disabled?

Yes.

> Then it shouldn't even be calling those selinux_* functions anymore.
> grep selinux /proc/filesystems
> ls /sys/fs/selinux
> echo 1 > /sys/fs/selinux/disable

Right, doesn't make any sense to me why selinux is even being called:

# grep selinux /proc/filesystems
# ls /sys/fs/selinux
ls: cannot access /sys/fs/selinux: No such file or directory
Comment 11 Stephen Smalley 2013-04-23 16:08:05 EDT
Hmmm..and with selinux=0 on the grub command line?
Comment 12 Mike Snitzer 2013-04-23 16:38:06 EDT
(In reply to comment #11)
> Hmmm..and with selinux=0 on the grub command line?

No, selinux=0 isn't on the grub command line.  I can try that to see if these kmemleaks go away.
Comment 13 Stephen Smalley 2013-04-23 16:51:57 EDT
So, with SELINUX=disabled, I would expect some leaks from allocation of security blobs for early tasks, inodes, etc, prior to systemd disabling SELinux.  It doesn't try to track down everything allocated up to that point and free it.
But it should continue to occur at runtime, as the SELinux hooks should no longer be called anymore.  And if you have no selinuxfs in /proc/filesystems, then that suggests that it was truly disabled and not just permissive with no policy loaded.

With selinux=0 on the grub command line, the kernel can disable at boot prior to allocating any security blobs and thus you shouldn't leak anything at all.

Neither case should lead to ongoing leaks at runtime.
Comment 14 Stephen Smalley 2013-04-23 16:52:31 EDT
Sorry, s/should continue/should not continue/
Comment 15 Ben Greear 2013-06-10 14:01:25 EDT
I saw similar leaks using 3.9.5, and putting selinux=0 on the kernel command line
'fixed' the problem according to kmemleak.
Comment 16 Josh Boyer 2013-09-18 16:55:01 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 17 Josh Boyer 2013-10-08 13:43:09 EDT
I'll avoid closing this again, but getting confirmation on 3.11 would still be good.

Eric, are you going to look at this?
Comment 18 Eric Paris 2013-10-08 16:36:57 EDT
We know we leak some memory when selinux is disabled in the config file but not on the command line.  it should be a very small amount.  The book keeping required to ensure that the memory we leak is finally not being referenced is not reasonable.  We do not intend to fix this bug at this time unless it poses an actual problem...

I mean, maybe one day we'll have nothing to do and we'll get to it, but I highly doubt it...
Comment 19 Mike Snitzer 2013-10-08 17:17:52 EDT
(In reply to Eric Paris from comment #18)
> We know we leak some memory when selinux is disabled in the config file but
> not on the command line.  it should be a very small amount.

It isn't a one-time leak.  it keeps occurring the entire time the system is up.

> The book
> keeping required to ensure that the memory we leak is finally not being
> referenced is not reasonable.  We do not intend to fix this bug at this time
> unless it poses an actual problem...
> 
> I mean, maybe one day we'll have nothing to do and we'll get to it, but I
> highly doubt it...

Pretty strange stance but OK...

Note You need to log in before you can comment on or make changes to this bug.