Verification done on "Disco" (linux-hwe-5.0)
---
# uname -rv
5.0.0-58-generic #62~18.04.1-Ubuntu SMP Tue Jul 14 03:37:30 UTC 2020
For some other reason the kprobes module is not picking up on accept,
only on release. This is unrelated to this patchset.
I used kprobe events instead, which is working, and reveals the ref
counter does not leak (stable increase/decrease on accept/release.)
On the example below, it varies between 0x64b and 0x64c, correctly.
# ./aa-refcnt-af_alg &
# echo 'p af_alg_accept sk=%di count=+0x0(+0x0(+0x278(%di))):x32' >
/sys/kernel/debug/tracing/kprobe_events
# echo 'p af_alg_release_parent sk=%di count=+0x0(+0x0(+0x278(%di))):x32' >>
/sys/kernel/debug/tracing/kprobe_events
# echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
# cat /sys/kernel/debug/tracing/trace_pipe
...
aa-refcnt-af_al-21362 [002] .... 77023.869615: p_af_alg_accept_0:
(af_alg_accept+0x0/0x1c0 [af_alg]) sk=0xffff9138b54c2400 count=0x64b
aa-refcnt-af_al-21362 [002] .... 77023.869619: p_af_alg_release_parent_0:
(af_alg_release_parent+0x0/0xc0 [af_alg]) sk=0xffff9138b5e27800 count=0x64c
aa-refcnt-af_al-21362 [002] .... 77023.869623: p_af_alg_accept_0:
(af_alg_accept+0x0/0x1c0 [af_alg]) sk=0xffff9138b54c2400 count=0x64b
aa-refcnt-af_al-21362 [002] .... 77023.869626: p_af_alg_release_parent_0:
(af_alg_release_parent+0x0/0xc0 [af_alg]) sk=0xffff9138b5e27800 count=0x64c
aa-refcnt-af_al-21362 [002] .... 77023.869630: p_af_alg_accept_0:
(af_alg_accept+0x0/0x1c0 [af_alg]) sk=0xffff9138b54c2400 count=0x64b
aa-refcnt-af_al-21362 [002] .... 77023.869633: p_af_alg_release_parent_0:
(af_alg_release_parent+0x0/0xc0 [af_alg]) sk=0xffff9138b5e27800 count=0x64c
...
ctrl-c
# echo 0 > /sys/kernel/debug/tracing/events/kprobes/enable
# echo > /sys/kernel/debug/tracing/kprobe_events
# killall aa-refcnt-af_alg
Details:
-------
We want this value from 'struct sock *sk':
kref_read(&SK_CTX(sk)->label->count)
With:
#define SK_CTX(X) apparmor_sock(X)
static inline struct aa_sk_ctx *apparmor_sock(const struct sock *sk)
...
return sk->sk_security + apparmor_blob_sizes->lbs_sock;
...
Checking the value for lbs_sock w/ a kernel module:
[76604.268403] apparmor_blob_sizes->lbs_sock: 0
And struct member offsets:
$ pahole --hex -C sock usr/lib/debug/boot/vmlinux-5.0.0-58-generic |
grep sk_security
void * sk_security; /* 0x278 0x8
*/
$ pahole --hex -C aa_sk_ctx usr/lib/debug/boot/vmlinux-5.0.0-58-generic
| grep -w label
struct aa_label * label; /* 0 0x8
*/
$ pahole --hex -C aa_label usr/lib/debug/boot/vmlinux-5.0.0-58-generic
| grep -w count
struct kref count; /* 0 0x4
*/
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1883962
Title:
apparmor reference leak causes refcount_t overflow with
af_alg_accept()
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Bionic:
Fix Committed
Status in linux source package in Eoan:
Fix Committed
Status in linux source package in Focal:
Fix Committed
Status in linux source package in Groovy:
Invalid
Bug description:
[Impact]
* Users of the Crypto (user-space) API (i.e., AF_ALG)
can trigger refcount errors in AppArmor under high
load (might lead to memory leak or use after free.)
* There is a reference leak in AppArmor when af_alg_accept()
calls security_sock_graft() and then security_sk_clone().
* Both acquire a reference to a label, to assign it to the
same pointer, but the latter does not release the former's
acquired reference (before overwriting the pointer value.)
* This reference leak builds up over time, and under high
load can eventually overflow/underflow/saturate refcount,
depending on which value it has when a program hits that.
* The fix just checks if the pointer has an assigned label,
then releases its acquired reference.
[Test Case]
* See comment #1 for the test-case 'aa-refcnt-af_alg.c'.
* Exercise that code path indefinitely until it hits
the refcount_t overflow/underflow/saturate message
(or not, with the patch.) (see comment #4)
* It's possible to monitor refcount values with kprobes,
to confirm whether or not the problem is happening.
(see comments #2 and #3)
[Other Info]
* Patch applied upstream on v5.8-rc1 [1]
* Applied on Unstable (tag Ubuntu-5.8-5.8.0-0.1)
* Not required on Groovy (still 5.4; should sync from Unstable)
* Not required on Eoan (EOL date before SRU cycle release date)
* Required on Bionic and Focal.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=3b646abc5bc6c0df649daea4c2c976bd4d47e4c8
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1883962/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
