Message ID | 20200629183110.1533365-1-mfo@canonical.com |
---|---|
Headers | show |
Series | aufs: fixes for CVE-2020-11935 | expand |
These should rather be applied as "UBUNTU: SAUCE:", despite the cherry picked
line from aufs repo, as this is not upstream.
Besides that:
Acked-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
As mentioned by Cascardo, these need to be "UBUNTU: SAUCE:". Otherwise, Acked-by: Kamal Mostafa <kamal@canonical.com> -Kamal On Mon, Jun 29, 2020 at 03:31:08PM -0300, Mauricio Faria de Oliveira wrote: > [Impact] > > * This patchset contains fixes for aufs's CVE-2020-11935. > > * The aufs filesystem might hit a kernel BUG() message > under high load. > > * This may trigger a kernel panic/crash if panic_on_oops > is enabled. Otherwise, no harmful behavior is noticed. > > * One workaround is to clean the inode cache periodically: > $ echo 2 | sudo tee /proc/sys/vm/drop-caches > > [Fix] > > * The issue is fixed with 2 patches in aufs4-linux.git: > - 515a586eeef3 aufs: do not call i_readcount_inc() > - f10aea57d39d aufs: bugfix, IMA i_readcount > > * The first addresses the issue, and the second addresses a > regression in the aufs feature to change RW branches to RO. > > * The aufs patches for v5.3+ have an equivalent fix to the > second patch; it is present in Focal and later (not Eoan) > (and on ubuntu-unstable/master & /master-5.8 as of Jun 29) > - 1d26f910c53f aufs: for v5.3-rc1, maintain i_readcount > (in aufs5-linux.git) > > * So, X/B/D/E need patches 1 and 2. > * And F/G/Unstable need patch 1 only. > > [Test Case] > > * Test cases are available internally, if needed. > > [Regression Potential] > > * This changes the core path that aufs opens files, so there > is a risk of regression; however, the fix changes aufs for > how other filesystems work, so this generally is OK to do. > In any case, regressions would likely happen in open() or > close(). > > * The aufs maintainer has access to an internal test-suite > used to validate aufs changes, used to identify the first > regression (in the branch RW/RO mode change), and then to > validate/publish the patches upstream; should be good now. > > * This has also been tested with 'stress-ng --class filesystem' > and with 'xfstests -overlay' (patch to use aufs vs overlayfs) > on Xenial/Bionic/Focal (-proposed vs. -proposed + patches). > No regressions observed in stress-ng/xfstests log or dmesg. > (Also build-tested on Disco/Eoan.) > > [Other Info] > > * Applied on Unstable (branches master and master-5.8) > * Not required on Groovy (still 5.4; should sync from Unstable) > * Required on LTS releases: Bionic and Focal and Xenial. > * Required on other releases: Disco and Eoan (for custom kernels) > > * Sorry for the submission after scheduled last day for patches. > Really wanted to have this upstream first specially given the > maintainer's internal test-suite (that catched one regression > not hit in my tests, because it's on corner case/feature path.) > > J. R. Okajima (1): > aufs: bugfix, IMA i_readcount > > Mauricio Faria de Oliveira (1): > aufs: do not call i_readcount_inc() > > fs/aufs/branch.c | 6 +++++- > fs/aufs/vfsub.c | 9 +-------- > 2 files changed, 6 insertions(+), 9 deletions(-) > > -- > 2.25.1 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team
On 2020-06-29 15:31:08 , Mauricio Faria de Oliveira wrote: > [Impact] > > * This patchset contains fixes for aufs's CVE-2020-11935. > > * The aufs filesystem might hit a kernel BUG() message > under high load. > > * This may trigger a kernel panic/crash if panic_on_oops > is enabled. Otherwise, no harmful behavior is noticed. > > * One workaround is to clean the inode cache periodically: > $ echo 2 | sudo tee /proc/sys/vm/drop-caches > > [Fix] > > * The issue is fixed with 2 patches in aufs4-linux.git: > - 515a586eeef3 aufs: do not call i_readcount_inc() > - f10aea57d39d aufs: bugfix, IMA i_readcount > > * The first addresses the issue, and the second addresses a > regression in the aufs feature to change RW branches to RO. > > * The aufs patches for v5.3+ have an equivalent fix to the > second patch; it is present in Focal and later (not Eoan) > (and on ubuntu-unstable/master & /master-5.8 as of Jun 29) > - 1d26f910c53f aufs: for v5.3-rc1, maintain i_readcount > (in aufs5-linux.git) > > * So, X/B/D/E need patches 1 and 2. > * And F/G/Unstable need patch 1 only. > > [Test Case] > > * Test cases are available internally, if needed. > > [Regression Potential] > > * This changes the core path that aufs opens files, so there > is a risk of regression; however, the fix changes aufs for > how other filesystems work, so this generally is OK to do. > In any case, regressions would likely happen in open() or > close(). > > * The aufs maintainer has access to an internal test-suite > used to validate aufs changes, used to identify the first > regression (in the branch RW/RO mode change), and then to > validate/publish the patches upstream; should be good now. > > * This has also been tested with 'stress-ng --class filesystem' > and with 'xfstests -overlay' (patch to use aufs vs overlayfs) > on Xenial/Bionic/Focal (-proposed vs. -proposed + patches). > No regressions observed in stress-ng/xfstests log or dmesg. > (Also build-tested on Disco/Eoan.) > > [Other Info] > > * Applied on Unstable (branches master and master-5.8) > * Not required on Groovy (still 5.4; should sync from Unstable) > * Required on LTS releases: Bionic and Focal and Xenial. > * Required on other releases: Disco and Eoan (for custom kernels) > > * Sorry for the submission after scheduled last day for patches. > Really wanted to have this upstream first specially given the > maintainer's internal test-suite (that catched one regression > not hit in my tests, because it's on corner case/feature path.) > > J. R. Okajima (1): > aufs: bugfix, IMA i_readcount > > Mauricio Faria de Oliveira (1): > aufs: do not call i_readcount_inc() > > fs/aufs/branch.c | 6 +++++- > fs/aufs/vfsub.c | 9 +-------- > 2 files changed, 6 insertions(+), 9 deletions(-) > > -- > 2.25.1 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team