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