srcname from mount rule corrupted under load
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
AppArmor |
Invalid
|
Critical
|
John Johansen | ||
linux (Ubuntu) |
Fix Released
|
Critical
|
Unassigned | ||
Precise |
Invalid
|
Undecided
|
Unassigned | ||
Trusty |
Fix Released
|
High
|
Unassigned | ||
Xenial |
Fix Released
|
Critical
|
Unassigned | ||
Yakkety |
Invalid
|
Critical
|
Unassigned |
Bug Description
This came up in snapd spread tests but can be reproduced with:
In an i386 up to date 16.04 VM:
1. in one terminal, run this:
$ cat reproducer.sh
#!/bin/sh
set -e
sudo sysctl -w kernel.
sudo snap install hello-world || true
count=0
while /bin/true ; do
count=
if [ `echo "$count % 100" | bc` -eq 0 ]; then
echo "$count runs"
fi
hello-world > /dev/null || {
tail -100 /var/log/syslog | grep DEN && exit
}
sudo cat /run/snapd/
done
2. in another terminal run:
$ while /bin/true ;do sudo apparmor_parser -r /etc/apparmor.d/* >/dev/null 2>&1 ; done
3. In another terminal:
$ tail -f /var/log/
This is not limited to i386.
Changed in linux (Ubuntu): | |
status: | New → Triaged |
Changed in linux (Ubuntu Xenial): | |
status: | New → Triaged |
Changed in linux (Ubuntu Yakkety): | |
status: | New → Triaged |
Changed in linux (Ubuntu): | |
importance: | Undecided → Critical |
Changed in linux (Ubuntu Xenial): | |
importance: | Undecided → Critical |
Changed in linux (Ubuntu Yakkety): | |
importance: | Undecided → Critical |
Changed in linux (Ubuntu Yakkety): | |
status: | Triaged → Invalid |
Changed in linux (Ubuntu Trusty): | |
status: | New → Triaged |
Changed in linux (Ubuntu Precise): | |
status: | New → Invalid |
Changed in linux (Ubuntu Trusty): | |
importance: | Undecided → High |
tags: | added: kernel-da-key |
description: | updated |
Changed in linux (Ubuntu Trusty): | |
status: | Triaged → Fix Committed |
Changed in apparmor: | |
status: | In Progress → Invalid |
Changed in linux (Ubuntu): | |
status: | Triaged → Fix Released |
tags: | added: cscc |
Is _only_ srcname being corrupted?
Back In The Day it was common for the kernel ring buffer for messages to overflow and overwrite messages, but of course it did not care what was being overwritten.
The kernel ring buffer is larger now, so it should be less common, but not impossible if the logging device is too slow to keep up with the rate of message generation.
If log messages must be kept intact, perhaps auditd makes more sense.
Or is something else going on?
Thanks