Activity log for bug #1883962

Date Who What changed Old value New value Message
2020-06-17 19:08:42 Mauricio Faria de Oliveira bug added bug
2020-06-17 19:09:00 Mauricio Faria de Oliveira linux (Ubuntu): importance Undecided Medium
2020-06-17 19:09:04 Mauricio Faria de Oliveira linux (Ubuntu): assignee Mauricio Faria de Oliveira (mfo)
2020-06-17 19:09:23 Mauricio Faria de Oliveira nominated for series Ubuntu Groovy
2020-06-17 19:09:23 Mauricio Faria de Oliveira bug task added linux (Ubuntu Groovy)
2020-06-17 19:09:23 Mauricio Faria de Oliveira nominated for series Ubuntu Bionic
2020-06-17 19:09:23 Mauricio Faria de Oliveira bug task added linux (Ubuntu Bionic)
2020-06-17 19:09:23 Mauricio Faria de Oliveira nominated for series Ubuntu Eoan
2020-06-17 19:09:23 Mauricio Faria de Oliveira bug task added linux (Ubuntu Eoan)
2020-06-17 19:09:23 Mauricio Faria de Oliveira nominated for series Ubuntu Focal
2020-06-17 19:09:23 Mauricio Faria de Oliveira bug task added linux (Ubuntu Focal)
2020-06-17 19:09:31 Mauricio Faria de Oliveira linux (Ubuntu Groovy): status New Won't Fix
2020-06-17 19:09:35 Mauricio Faria de Oliveira linux (Ubuntu Eoan): status New Won't Fix
2020-06-17 19:09:39 Mauricio Faria de Oliveira linux (Ubuntu Bionic): status New In Progress
2020-06-17 19:09:44 Mauricio Faria de Oliveira linux (Ubuntu Focal): status New In Progress
2020-06-17 19:09:51 Mauricio Faria de Oliveira linux (Ubuntu Groovy): importance Medium Undecided
2020-06-17 19:09:55 Mauricio Faria de Oliveira linux (Ubuntu Groovy): assignee Mauricio Faria de Oliveira (mfo)
2020-06-17 19:10:05 Mauricio Faria de Oliveira linux (Ubuntu Focal): importance Undecided Medium
2020-06-17 19:10:07 Mauricio Faria de Oliveira linux (Ubuntu Focal): assignee Mauricio Faria de Oliveira (mfo)
2020-06-17 19:10:10 Mauricio Faria de Oliveira linux (Ubuntu Bionic): importance Undecided Medium
2020-06-17 19:10:13 Mauricio Faria de Oliveira linux (Ubuntu Bionic): assignee Mauricio Faria de Oliveira (mfo)
2020-06-17 19:11:22 Mauricio Faria de Oliveira linux (Ubuntu): status New Fix Committed
2020-06-17 19:42:53 Mauricio Faria de Oliveira 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 # for the test-case 'aa-refcnt-af_alg.c'. * Exercise that code path indefinitely until it hits the refcount_t overflow/underflow/saturate message. (in a few hours.) * It's possible to monitor refcount values with kprobes. [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 [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] * Exercise that code path indefinitely until it hits the refcount_t overflow/underflow/saturate message (or not, with the patch.)  * See comment #1 for the test-case 'aa-refcnt-af_alg.c'. If the problem happens, in a few hours there is an error message in the kernel logs (see comment #1.)  * It's possible to monitor refcount values with kprobes, to confirm whether or not the problem is happening. [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
2020-06-18 14:42:17 Mauricio Faria de Oliveira attachment added kmod.c https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1883962/+attachment/5385006/+files/kmod.c
2020-06-18 14:50:54 Mauricio Faria de Oliveira 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] * Exercise that code path indefinitely until it hits the refcount_t overflow/underflow/saturate message (or not, with the patch.)  * See comment #1 for the test-case 'aa-refcnt-af_alg.c'. If the problem happens, in a few hours there is an error message in the kernel logs (see comment #1.)  * It's possible to monitor refcount values with kprobes, to confirm whether or not the problem is happening. [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 [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)    If the problem happens, in a few hours there is an    error message in the kernel logs (see comment #1.)  * 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
2020-06-18 14:51:40 Mauricio Faria de Oliveira 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)    If the problem happens, in a few hours there is an    error message in the kernel logs (see comment #1.)  * 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 [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
2020-06-18 15:35:00 Mauricio Faria de Oliveira tags sts
2020-06-18 15:35:32 Mauricio Faria de Oliveira linux (Ubuntu Groovy): status Won't Fix Invalid
2020-06-29 19:42:46 Mauricio Faria de Oliveira linux (Ubuntu Eoan): status Won't Fix In Progress
2020-06-29 19:42:51 Mauricio Faria de Oliveira linux (Ubuntu Eoan): importance Undecided Medium
2020-06-29 19:42:54 Mauricio Faria de Oliveira linux (Ubuntu Eoan): assignee Mauricio Faria de Oliveira (mfo)
2020-06-29 20:03:51 Brian Moyles bug added subscriber Netflix Engineering
2020-06-30 02:30:58 Khaled El Mously linux (Ubuntu Eoan): status In Progress Fix Committed
2020-07-01 03:14:46 Khaled El Mously linux (Ubuntu Bionic): status In Progress Fix Committed
2020-07-01 03:16:11 Khaled El Mously linux (Ubuntu Focal): status In Progress Fix Committed
2020-07-03 11:32:14 Ubuntu Kernel Bot tags sts sts verification-needed-eoan
2020-07-06 18:18:04 Mauricio Faria de Oliveira tags sts verification-needed-eoan sts verification-done-eoan
2020-07-27 15:04:04 Launchpad Janitor linux (Ubuntu Eoan): status Fix Committed Fix Released
2020-07-27 15:04:04 Launchpad Janitor cve linked 2019-16089
2020-07-27 15:04:04 Launchpad Janitor cve linked 2019-19642
2020-07-27 15:04:04 Launchpad Janitor cve linked 2020-10757
2020-07-27 15:04:04 Launchpad Janitor cve linked 2020-11935
2020-08-10 14:17:27 Ubuntu Kernel Bot tags sts verification-done-eoan sts verification-done-eoan verification-needed-focal
2020-08-10 18:52:30 Ubuntu Kernel Bot tags sts verification-done-eoan verification-needed-focal sts verification-done-eoan verification-needed-bionic verification-needed-focal
2020-08-12 08:11:49 Mauricio Faria de Oliveira tags sts verification-done-eoan verification-needed-bionic verification-needed-focal sts verification-done-bionic verification-done-eoan verification-needed-focal
2020-08-12 08:18:43 Mauricio Faria de Oliveira tags sts verification-done-bionic verification-done-eoan verification-needed-focal sts verification-done-bionic verification-done-eoan verification-done-focal
2020-08-31 13:57:07 Launchpad Janitor linux (Ubuntu Focal): status Fix Committed Fix Released
2020-09-01 10:15:06 Launchpad Janitor linux (Ubuntu Bionic): status Fix Committed Fix Released
2022-09-14 13:44:38 Mauricio Faria de Oliveira linux (Ubuntu): status Fix Committed Fix Released