[Group.of.nepali.translators] [Bug 1884766] Re: use-after-free in af_alg_accept() due to bh_lock_sock()
** Changed in: linux (Ubuntu Xenial)
Status: New => In Progress
** Changed in: linux (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Xenial)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: linux (Ubuntu Bionic)
Status: New => In Progress
** Changed in: linux (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Bionic)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: linux (Ubuntu Eoan)
Status: New => In Progress
** Changed in: linux (Ubuntu Eoan)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Eoan)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: linux (Ubuntu Focal)
Status: New => In Progress
** Changed in: linux (Ubuntu Focal)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Focal)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: linux (Ubuntu Groovy)
Status: Confirmed => Won't Fix
** Changed in: linux (Ubuntu Groovy)
Importance: Medium => Undecided
** Changed in: linux (Ubuntu Groovy)
Assignee: Mauricio Faria de Oliveira (mfo) => (unassigned)
** Changed in: linux (Ubuntu)
Status: Confirmed => In Progress
** Description changed:
[Impact]
* Users of the Linux kernel's crypto userspace API
reported BUG() / kernel NULL pointer dereference
errors after kernel upgrades.
* The stack trace signature is an accept() syscall
going through af_alg_accept() and hitting errors
usually in one of:
- apparmor_sk_clone_security()
- apparmor_sock_graft()
- release_sock()
[Fix]
* This is a regression introduced by upstream commit
37f96694cf73 ("crypto: af_alg - Use bh_lock_sock
in sk_destruct") which made its way through stable.
* The offending patch allows the critical regions
of af_alg_accept() and af_alg_release_parent() to
run concurrently; now with the "right" events on 2
CPUs it might drop the non-atomic reference counter
of the alg_sock then the sock, thus release a sock
that is still in use.
* The fix is upstream commit 34c86f4c4a7b ("crypto:
af_alg - fix use-after-free in af_alg_accept() due
to bh_lock_sock()") [1]. It changes alg_sock's ref
counter to atomic, which addresses the root cause.
[Test Case]
* There is a synthetic test case available, which
uses a kprobes kernel module to synchronize the
concurrent CPUs on the instructions responsible
for the problem; and a userspace part to run it.
* The organic reproducer is the Varnish Cache Plus
software with the Crypto vmod (which uses kernel
crypto userspace API) under long, very high load.
* The patch has been verified on both reproducers
with the 4.15 and 5.7 kernels.
- * More tests performed with 'stress-ng --af-alg'
-with 11 CPUs on Xenial/Bionic/Disco/Eoan/Focal
-(all on same version of stress-ng, V0.11.14)
+ * More tests performed with 'stress-ng --af-alg'
+ with 11 CPUs on Xenial/Bionic/Disco/Eoan/Focal
+ (all on same version of stress-ng, V0.11.14)
-No regressions observed from original kernel.
-(the af-alg stressor can exercise almost all
-kernel crypto modules shipped with the kernel;
-so it checks more paths/crypto alg interfaces.)
+ No regressions observed from original kernel.
+ (the af-alg stressor can exercise almost all
+ kernel crypto modules shipped with the kernel;
+ so it checks more paths/crypto alg interfaces.)
[Regression Potential]
* The fix patch does a fundamental change in how
alg_sock reference counters work, plus another
change to the 'nokey' counting. This of course
*has* a risk of regression.
* Regressions theoretically could manifest as use
after free errors (in case of undercounting) in
the af_alg functions or silent memory leaks (in
case of overcounting), but also other behaviors
since reference counting is key to many things.
* FWIW, this patch has been written by the crypto
subsystem maintainer, who certainly knows a lot
of the normal and corner cases, thus giving the
patch more credit.
* Testing with the organic reproducer ran as long
as 5 days, without issues, so it does look good.
[Other Info]
+
+ * Not sending for Groovy (should get via Unstable).
* [1] Patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34c86f4c4a7be3b3e35aa48bd18299d4c756064d
[Stack Trace Examples]
Examples:
BUG: unable to handle kernel NULL pointer dereference at
...
RIP: 0010:apparmor_sk_clone_security+0x26/0x70
...
Call Trace:
security_sk_clone+0x33/0x50
af_alg_accept+0x81/0x1c0 [af_alg]
alg_accept+0x15/0x20 [af_alg]
SYSC_accept4+0xff/0x210
[Group.of.nepali.translators] [Bug 1885055] Re: xenial/linux-azure: 4.15.0-1091.101~16.04.1 -proposed tracker
Flipping the ADT test manually based on previous version and no outstanding issues on the current run. ** Changed in: kernel-sru-workflow/automated-testing Status: In Progress => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1885055 Title: xenial/linux-azure: 4.15.0-1091.101~16.04.1 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Fix Released Status in Kernel SRU Workflow certification-testing series: Invalid Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow prepare-package-signed series: Fix Released Status in Kernel SRU Workflow promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-security series: New Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: Fix Released Status in Kernel SRU Workflow security-signoff series: Fix Released Status in Kernel SRU Workflow stakeholder-signoff series: Fix Released Status in Kernel SRU Workflow verification-testing series: Fix Released Status in linux-azure source package in Xenial: Confirmed Bug description: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- boot-testing-requested: true kernel-stable-master-bug: 1885057 packages: main: linux-azure meta: linux-meta-azure signed: linux-signed-azure phase: Testing phase-changed: Saturday, 27. June 2020 15:15 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: automated-testing: Ongoing -- testing in progress trackers: xenial/linux-azure/azure-kernel: bug 1885054 variant: debs versions: main: 4.15.0-1091.101~16.04.1 meta: 4.15.0.1091.86 signed: 4.15.0-1091.101~16.04.1 To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1885055/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1882764] Re: xenial/linux-raspi2: 4.4.0-1135.144 -proposed tracker
Flipping the ADT test manually based on previous version and no outstanding issues on the current run. ** Changed in: kernel-sru-workflow/automated-testing Status: In Progress => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1882764 Title: xenial/linux-raspi2: 4.4.0-1135.144 -proposed tracker Status in Kernel SRU Workflow: In Progress Status in Kernel SRU Workflow automated-testing series: Fix Released Status in Kernel SRU Workflow certification-testing series: In Progress Status in Kernel SRU Workflow prepare-package series: Fix Released Status in Kernel SRU Workflow prepare-package-meta series: Fix Released Status in Kernel SRU Workflow promote-to-proposed series: Fix Released Status in Kernel SRU Workflow promote-to-security series: New Status in Kernel SRU Workflow promote-to-updates series: New Status in Kernel SRU Workflow regression-testing series: Invalid Status in Kernel SRU Workflow security-signoff series: Fix Released Status in Kernel SRU Workflow verification-testing series: Fix Released Status in linux-raspi2 source package in Xenial: New Bug description: This bug will contain status and test results related to a kernel source (or snap) as stated in the title. For an explanation of the tasks and the associated workflow see: https://wiki.ubuntu.com/Kernel/kernel-sru-workflow -- swm properties -- boot-testing-requested: true kernel-stable-master-bug: 1882770 packages: main: linux-raspi2 meta: linux-meta-raspi2 phase: Testing phase-changed: Sunday, 28. June 2020 13:56 UTC proposed-announcement-sent: true proposed-testing-requested: true reason: automated-testing: Ongoing -- testing in progress certification-testing: Ongoing -- testing in progress trackers: xenial/linux-raspi2/pi2-kernel: bug 1882763 variant: debs versions: main: 4.4.0-1135.144 meta: 4.4.0.1135.135 To manage notifications about this bug go to: https://bugs.launchpad.net/kernel-sru-workflow/+bug/1882764/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1580731] Re: augeas-lenses filter for PHP files doesn't match php7.0-* files
Following a discussion with Bryce earlier, on behalf of the SRU team I'm declining this SRU and mark it Won't Fix. It might have been relevant to fix in Xenial at the time, but the bug has now been fixed in newer releases including in two newer LTS releases. The benefit to Xenial users seems minimal now, especially as not a single user has stepped up to test Jon's proposed fix in four years. As the impact on users on Xenial therefore appears to be zero, I don't think it's appropriate to SRU this now, when balanced against the regression risk of toolchain changes mutating a rebuild. If the situation changes and users do appear who are affected, then we can reconsider. Note that I've not considered any other factors. If users are affected, an appropriate answer may still be to upgrade rather than SRUing this fix. ** Changed in: augeas (Ubuntu Xenial) Status: Triaged => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1580731 Title: augeas-lenses filter for PHP files doesn't match php7.0-* files Status in augeas package in Ubuntu: Fix Released Status in augeas source package in Xenial: Won't Fix Bug description: [Impact] Automation of configuration editing cannot be done for PHP installations on Xenial using augeas. The location of php configuration files moved in php7, to a directory augeas doesn't look in. [Test Case] - Create lxc container $ sudo apt-get install php7.0-cli $ sudo apt-get install augeas-lenses augeas-tools $ augtool ls /files/etc/php ## (no output) - Add the PPA $ augtool ls /files/etc/php 7.0/ = (none) [Regression Potential] Since this makes the PHP configuration accessible to augeas where it wasn't before, behaviors to watch for would relate to php configuration issues when augeas (or puppet) are in use. It is expected that by now most administrators will have worked around the problem by using some other method to configure php, so it is unlikely users would experience behavior regression. [Fix] This adds the "/etc/php/*/*/*.ini" path to the php lense for augeas, following what upstream has done, and that we carry in newer versions of Ubuntu. [Discussion] While it is true that Xenial is old at this point, enterprises that use configuration automation software like augeas sometimes still need older versions of Ubuntu (e.g. via ESM). PHP has been a popular choice for many enterprises in the past, so it is expected that PHP 5 -> 7.0 upgrades are still relevant. So, given that, plus the simplicity of this fix it seems still worthy of SRU. [Original Report] The filter list in /usr/share/augeas/lenses/dist/php.aug includes: /etc/php*/*/*.ini /etc/php*/fpm/pool.d/*.conf This will match the php5-fpm package files: /etc/php5/fpm/php.ini /etc/php5/fpm/pool.d/*.conf But not the php7.0-fpm package files: /etc/php/7.0/fpm/php.ini /etc/php/7.0/fpm/pool.d/*.conf Puppet handles this badly because augeas won't report that anything has changed trying to set options in /etc/php/7.0/fpm/php.ini, so it does nothing instead of reporting an error: Debug: Augeas[php_sessions](provider=augeas): Will attempt to save and only run if files changed Debug: Augeas[php_sessions](provider=augeas): sending command 'set' with params ["/files/etc/php/7.0/fpm/php.ini/Session/session.gc_maxlifetime", "604800"] Debug: Augeas[php_sessions](provider=augeas): Skipping because no files were changed Debug: Augeas[php_sessions](provider=augeas): Closed the augeas connection augeas-lenses: Installed: 1.4.0-0ubuntu1 Candidate: 1.4.0-0ubuntu1 Version table: *** 1.4.0-0ubuntu1 500 500 http://gb.archive.ubuntu.com/ubuntu xenial/main amd64 Packages 500 http://gb.archive.ubuntu.com/ubuntu xenial/main i386 Packages 100 /var/lib/dpkg/status php7.0-fpm: Installed: 7.0.4-7ubuntu2ppa1 Candidate: 7.0.4-7ubuntu2ppa1 Version table: *** 7.0.4-7ubuntu2ppa1 1000 1000 http://ppa.launchpad.net/sa.me.uk/um/ubuntu xenial/main amd64 Packages 100 /var/lib/dpkg/status 7.0.4-7ubuntu2 500 500 http://gb.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/augeas/+bug/1580731/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
