| 2009-02-14 18:32:33 |
Domas Mituzas |
bug |
|
|
added bug |
| 2009-02-14 18:32:33 |
Domas Mituzas |
bug |
|
|
added attachment 'graph.php.gif' (graph of leaked memory) |
| 2009-02-14 20:13:56 |
Kees Cook |
apparmor: status |
New |
Incomplete |
|
| 2009-02-14 20:13:56 |
Kees Cook |
apparmor: assignee |
|
kees |
|
| 2009-02-14 20:13:56 |
Kees Cook |
apparmor: statusexplanation |
|
Thanks for the report! If AppArmor is disabled, does the leak go away? What is the specific configuration items in apache, and the common workload on the machine? I.e. what is the best way to reproduce this problem starting from a stock install of Hardy? |
|
| 2009-02-14 21:16:37 |
Kees Cook |
apparmor: status |
Incomplete |
Confirmed |
|
| 2009-02-14 21:16:37 |
Kees Cook |
apparmor: importance |
Undecided |
Medium |
|
| 2009-02-14 21:16:37 |
Kees Cook |
apparmor: statusexplanation |
Thanks for the report! If AppArmor is disabled, does the leak go away? What is the specific configuration items in apache, and the common workload on the machine? I.e. what is the best way to reproduce this problem starting from a stock install of Hardy? |
Yup, your testcase killed my hardy vm, but only when AppArmor was confining the testcase. |
|
| 2009-02-14 21:25:54 |
Kees Cook |
apparmor: status |
New |
Confirmed |
|
| 2009-02-14 21:25:54 |
Kees Cook |
apparmor: statusexplanation |
|
This affects intrepid and jaunty as well. |
|
| 2009-02-14 21:26:47 |
Kees Cook |
apparmor: status |
New |
Confirmed |
|
| 2009-02-14 21:26:47 |
Kees Cook |
apparmor: assignee |
|
kees |
|
| 2009-02-14 21:26:47 |
Kees Cook |
apparmor: importance |
Undecided |
Medium |
|
| 2009-02-14 21:26:47 |
Kees Cook |
apparmor: statusexplanation |
|
|
|
| 2009-02-14 21:27:01 |
Kees Cook |
apparmor: importance |
Undecided |
Medium |
|
| 2009-02-14 21:27:01 |
Kees Cook |
apparmor: assignee |
|
kees |
|
| 2009-02-14 21:27:01 |
Kees Cook |
apparmor: statusexplanation |
This affects intrepid and jaunty as well. |
|
|
| 2009-02-14 23:17:05 |
Domas Mituzas |
title |
frequent fcntl()s leak memory in apparmor |
fcntl() locks on unlinked files leak memory in apparmor |
|
| 2009-02-14 23:23:00 |
Domas Mituzas |
title |
fcntl() locks on unlinked files leak memory in apparmor |
operations on unlinked files leak memory in apparmor |
|
| 2009-02-15 00:12:15 |
Domas Mituzas |
title |
operations on unlinked files leak memory in apparmor |
locks on unlinked files leak memory in apparmor |
|
| 2009-02-27 21:32:24 |
Steve Beattie |
bug |
|
|
added attachment '0001-UBUNTU-fix-apparmor-memory-leak-on-deleted-file-ops.patch' (0001-UBUNTU-fix-apparmor-memory-leak-on-deleted-file-ops.patch) |
| 2009-03-04 16:30:24 |
Steve Beattie |
description |
after switching locking in apache/PHP/APC from shared-memory based to fcntl() we observed that apparmor (running in audit mode) leaks memory inside kernel like crazy:
MemTotal: 2062736 kB
MemFree: 16160 kB
Buffers: 496 kB
Cached: 7120 kB
SwapCached: 3256 kB
Active: 6064 kB
Inactive: 4824 kB
SwapTotal: 979924 kB
SwapFree: 967772 kB
Dirty: 104 kB
Writeback: 0 kB
AnonPages: 2592 kB
Mapped: 2036 kB
Slab: 2011664 kB
SReclaimable: 2092 kB
SUnreclaim: 2009572 kB
PageTables: 1228 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 2011292 kB
Committed_AS: 62204 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 16440 kB
VmallocChunk: 34359721743 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB |
Apparmor is leaks memory when unlinked files are locked by confined processes.
TEST CASE
Confining the following program:
#include <stdio.h>
#include <unistd.h>
int main(void)
{
int i;
int fd = open("/tmp/.lockfile", O_RDWR|O_CREAT);
unlink("/tmp/.lockfile");
fork();
fork();
fork();
fork();
for (i = 0; i < 5000; i++) {
struct flock lock;
lock.l_type = F_WRLCK;
lock.l_start = 0;
lock.l_whence = SEEK_END;
lock.l_len = 0;
fcntl(fd,F_SETLKW, &lock);
lock.l_type = F_UNLCK;
fcntl(fd, F_SETLKW, &lock);
}
return 0;
}
with an apparmor policy similar to the following (place the policy in /etc/apparmor.d and then do 'sudo /etc/init.d/apparmor restart' to reload policy):
#include <tunables/global>
/PATH/TO/YOUR/COMPILED/BINARY flags=(audit) {
#include <abstractions/base>
#include <abstractions/mysql>
#include <abstractions/nameservice>
capability kill,
capability net_bind_service,
capability setgid,
capability setuid,
# Major libs
/lib/ld-*.so mr,
/lib/libc-*.so mr,
/lib/libpthread-*.so mr,
/lib/librt-*.so mr,
/tmp/* rwk,
}
(You'll need to change /PATH/TO/YOUR/COMPILED/BINARY in the above profile to point the location of the compiled program.)
While running slabtop in another terminal, run the program.
Without the fix, slabtop should see an increase use of kernel memory, typically the kamlloc-256 slab.
With the fix in place, there shouldn't be much change in slabtop's reported output.
/var/log/messages should get a number of audit events (this confirms that confinement is applied to the binary in question). |
|
| 2009-03-04 16:56:24 |
Leann Ogasawara |
bug |
|
|
assigned to linux (Ubuntu) |
| 2009-03-04 16:57:10 |
Leann Ogasawara |
linux: status |
New |
Triaged |
|
| 2009-03-04 16:57:10 |
Leann Ogasawara |
linux: importance |
Undecided |
Medium |
|
| 2009-03-04 16:57:10 |
Leann Ogasawara |
linux: statusexplanation |
|
|
|
| 2009-03-04 16:57:50 |
Leann Ogasawara |
linux: status |
New |
Triaged |
|
| 2009-03-04 16:57:50 |
Leann Ogasawara |
linux: importance |
Undecided |
Medium |
|
| 2009-03-04 16:57:50 |
Leann Ogasawara |
linux: statusexplanation |
|
|
|
| 2009-03-04 16:58:05 |
Leann Ogasawara |
linux: status |
New |
Triaged |
|
| 2009-03-04 16:58:05 |
Leann Ogasawara |
linux: importance |
Undecided |
Medium |
|
| 2009-03-04 16:58:05 |
Leann Ogasawara |
linux: statusexplanation |
|
|
|
| 2009-03-04 17:14:22 |
Tim Gardner |
linux: status |
Triaged |
Fix Committed |
|
| 2009-03-04 17:14:22 |
Tim Gardner |
linux: assignee |
|
timg-tpi |
|
| 2009-03-04 17:14:22 |
Tim Gardner |
linux: statusexplanation |
|
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=537f85127f05d91f3a464cc3c1808fd8ea75c606 |
|
| 2009-03-04 17:14:22 |
Tim Gardner |
linux: milestone |
|
jaunty-alpha-6 |
|
| 2009-03-04 17:18:50 |
Andy Whitcroft |
linux: status |
Triaged |
In Progress |
|
| 2009-03-04 17:18:50 |
Andy Whitcroft |
linux: assignee |
|
apw |
|
| 2009-03-04 17:18:50 |
Andy Whitcroft |
linux: importance |
Medium |
Undecided |
|
| 2009-03-04 17:19:09 |
Andy Whitcroft |
linux: status |
Triaged |
In Progress |
|
| 2009-03-04 17:19:09 |
Andy Whitcroft |
linux: assignee |
|
apw |
|
| 2009-03-04 18:10:31 |
Andy Whitcroft |
description |
Apparmor is leaks memory when unlinked files are locked by confined processes.
TEST CASE
Confining the following program:
#include <stdio.h>
#include <unistd.h>
int main(void)
{
int i;
int fd = open("/tmp/.lockfile", O_RDWR|O_CREAT);
unlink("/tmp/.lockfile");
fork();
fork();
fork();
fork();
for (i = 0; i < 5000; i++) {
struct flock lock;
lock.l_type = F_WRLCK;
lock.l_start = 0;
lock.l_whence = SEEK_END;
lock.l_len = 0;
fcntl(fd,F_SETLKW, &lock);
lock.l_type = F_UNLCK;
fcntl(fd, F_SETLKW, &lock);
}
return 0;
}
with an apparmor policy similar to the following (place the policy in /etc/apparmor.d and then do 'sudo /etc/init.d/apparmor restart' to reload policy):
#include <tunables/global>
/PATH/TO/YOUR/COMPILED/BINARY flags=(audit) {
#include <abstractions/base>
#include <abstractions/mysql>
#include <abstractions/nameservice>
capability kill,
capability net_bind_service,
capability setgid,
capability setuid,
# Major libs
/lib/ld-*.so mr,
/lib/libc-*.so mr,
/lib/libpthread-*.so mr,
/lib/librt-*.so mr,
/tmp/* rwk,
}
(You'll need to change /PATH/TO/YOUR/COMPILED/BINARY in the above profile to point the location of the compiled program.)
While running slabtop in another terminal, run the program.
Without the fix, slabtop should see an increase use of kernel memory, typically the kamlloc-256 slab.
With the fix in place, there shouldn't be much change in slabtop's reported output.
/var/log/messages should get a number of audit events (this confirms that confinement is applied to the binary in question). |
Apparmor is leaks memory when unlinked files are locked by confined processes.
TEST CASE
Confining the following program:
#include <stdio.h>
#include <unistd.h>
int main(void)
{
int i;
int fd = open("/tmp/.lockfile", O_RDWR|O_CREAT);
unlink("/tmp/.lockfile");
fork();
fork();
fork();
fork();
for (i = 0; i < 5000; i++) {
struct flock lock;
lock.l_type = F_WRLCK;
lock.l_start = 0;
lock.l_whence = SEEK_END;
lock.l_len = 0;
fcntl(fd,F_SETLKW, &lock);
lock.l_type = F_UNLCK;
fcntl(fd, F_SETLKW, &lock);
}
return 0;
}
with an apparmor policy similar to the following (place the policy in /etc/apparmor.d and then do 'sudo /etc/init.d/apparmor restart' to reload policy):
#include <tunables/global>
/PATH/TO/YOUR/COMPILED/BINARY flags=(audit) {
#include <abstractions/base>
#include <abstractions/mysql>
#include <abstractions/nameservice>
capability kill,
capability net_bind_service,
capability setgid,
capability setuid,
# Major libs
/lib/ld-*.so mr,
/lib/libc-*.so mr,
/lib/libpthread-*.so mr,
/lib/librt-*.so mr,
/tmp/* rwk,
}
(You'll need to change /PATH/TO/YOUR/COMPILED/BINARY in the above profile to point the location of the compiled program.)
While running slabtop in another terminal, run the program.
Without the fix, slabtop should see an increase use of kernel memory, typically the kamlloc-256 slab.
With the fix in place, there shouldn't be much change in slabtop's reported output.
/var/log/messages should get a number of audit events (this confirms that confinement is applied to the binary in question).
===
SRU Justification
Justification: apparmour will leak memory leading to OOM, hangs, or crashes
Impact: certain workloads will cause memory to be leaked for each operation, specifically any name check on removed files
Fix Description: free the memory earlier in the error path
Patch: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=537f85127f05d91f3a464cc3c1808fd8ea75c606
Risks: very well contained and obvious change so this should be low risk. patch is upstream (apparmour)
TEST CASE: see above |
|
| 2009-03-04 18:11:04 |
Andy Whitcroft |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2009-03-04 18:16:01 |
Andy Whitcroft |
linux: status |
In Progress |
Fix Committed |
|
| 2009-03-04 18:16:20 |
Andy Whitcroft |
linux: status |
In Progress |
Fix Committed |
|
| 2009-03-04 21:35:16 |
Launchpad Janitor |
linux: status |
Fix Committed |
Fix Released |
|
| 2009-03-04 22:14:12 |
Steve Beattie |
apparmor: status |
Confirmed |
Invalid |
|
| 2009-03-04 22:14:12 |
Steve Beattie |
apparmor: statusexplanation |
|
This bug is in the kernel portion of apparmor, closing the userspace apparmor component tasks. Sorry for the noise. |
|
| 2009-03-04 22:14:37 |
Steve Beattie |
apparmor: status |
Confirmed |
Invalid |
|
| 2009-03-04 22:14:58 |
Steve Beattie |
apparmor: status |
Confirmed |
Invalid |
|
| 2009-03-04 22:14:58 |
Steve Beattie |
apparmor: statusexplanation |
|
|
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
linux (Ubuntu Intrepid): status |
Fix Committed |
Fix Released |
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
cve linked |
|
2009-0028 |
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
cve linked |
|
2009-0031 |
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
cve linked |
|
2009-0065 |
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
cve linked |
|
2009-0269 |
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
cve linked |
|
2009-0322 |
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
cve linked |
|
2009-0605 |
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
cve linked |
|
2009-0675 |
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
cve linked |
|
2009-0676 |
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
cve linked |
|
2009-0745 |
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
cve linked |
|
2009-0746 |
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
cve linked |
|
2009-0747 |
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
cve linked |
|
2009-0748 |
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
cve linked |
|
2009-0834 |
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
cve linked |
|
2009-0835 |
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
cve linked |
|
2009-0859 |
|
| 2009-04-06 22:27:58 |
Launchpad Janitor |
cve linked |
|
2009-1046 |
|
| 2009-04-06 22:29:07 |
Launchpad Janitor |
linux (Ubuntu Hardy): status |
Fix Committed |
Fix Released |
|
| 2009-04-06 22:29:07 |
Launchpad Janitor |
cve linked |
|
2008-4307 |
|
| 2009-04-06 22:29:07 |
Launchpad Janitor |
cve linked |
|
2008-6107 |
|
| 2009-07-03 09:20:20 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/karmic/linux-ports |
|
