| Message ID | 20230517161227.141529-1-cengiz.can@canonical.com |
|---|---|
| Headers | show |
| Series | CVE-2022-1184 | expand |
On 23/05/17 07:12PM, Cengiz Can wrote: > [Impact] > A use-after-free flaw was found in fs/ext4/namei.c:dx_insert_block() in the > Linux kernel’s filesystem sub-component. This flaw allows a local attacker with > a user privilege to cause a denial of service. > > [Fix] > This was tricky. I had to dive deep into other vendors' bugzillas and irc > channels to verify if the patches were enough. > > The fix consists of: > ext4: verify dir block before splitting it > ext4: avoid cycles in directory h-tree > ext4: check if directory block is within i_size > > The following fixes one of the fixing commits: > ext4: fix check for block being out of directory size > > The following was suggested to be included but I don't know the actual impact: > ext4: make sure ext4_append() always allocates new block > > Out of these five commits, 3 were already in Bionic and Focal. I backported or > cherry-picked the missing 2 to Bionic and Focal. > > [Test case] > I ran xfstests that specifically target ext4, with the exception of ext4/054 > because it always crashes on both unpatched and patched Bionic and Focal kernels. > Other than that, the test results are the same. > > [Potential regression] > High. This needs to be reviewed very carefully. > > Jan Kara (1): > ext4: fix check for block being out of directory size > > Lukas Czerner (1): > ext4: check if directory block is within i_size > > fs/ext4/namei.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > -- > 2.39.2 Acked-by: Andrei Gherzan <andrei.gherzan@canonical.com>
On 5/17/23 10:12 AM, Cengiz Can wrote: > [Impact] > A use-after-free flaw was found in fs/ext4/namei.c:dx_insert_block() in the > Linux kernel’s filesystem sub-component. This flaw allows a local attacker with > a user privilege to cause a denial of service. > > [Fix] > This was tricky. I had to dive deep into other vendors' bugzillas and irc > channels to verify if the patches were enough. > > The fix consists of: > ext4: verify dir block before splitting it > ext4: avoid cycles in directory h-tree > ext4: check if directory block is within i_size > > The following fixes one of the fixing commits: > ext4: fix check for block being out of directory size > > The following was suggested to be included but I don't know the actual impact: > ext4: make sure ext4_append() always allocates new block > > Out of these five commits, 3 were already in Bionic and Focal. I backported or > cherry-picked the missing 2 to Bionic and Focal. > > [Test case] > I ran xfstests that specifically target ext4, with the exception of ext4/054 > because it always crashes on both unpatched and patched Bionic and Focal kernels. > Other than that, the test results are the same. > > [Potential regression] > High. This needs to be reviewed very carefully. > > Jan Kara (1): > ext4: fix check for block being out of directory size > > Lukas Czerner (1): > ext4: check if directory block is within i_size > > fs/ext4/namei.c | 7 +++++++ > 1 file changed, 7 insertions(+) > Acked-by: Tim Gardner <tim.gardner@canonical.com>
The #2 patch no longer applies for focal and should be revisited to backport. I have not looked at the Bionic patch and leave Cascardo to apply that one as that has now gone esm. - Luke On Wed, May 17, 2023 at 9:13 AM Cengiz Can <cengiz.can@canonical.com> wrote: > [Impact] > A use-after-free flaw was found in fs/ext4/namei.c:dx_insert_block() in the > Linux kernel’s filesystem sub-component. This flaw allows a local attacker > with > a user privilege to cause a denial of service. > > [Fix] > This was tricky. I had to dive deep into other vendors' bugzillas and irc > channels to verify if the patches were enough. > > The fix consists of: > ext4: verify dir block before splitting it > ext4: avoid cycles in directory h-tree > ext4: check if directory block is within i_size > > The following fixes one of the fixing commits: > ext4: fix check for block being out of directory size > > The following was suggested to be included but I don't know the actual > impact: > ext4: make sure ext4_append() always allocates new block > > Out of these five commits, 3 were already in Bionic and Focal. I > backported or > cherry-picked the missing 2 to Bionic and Focal. > > [Test case] > I ran xfstests that specifically target ext4, with the exception of > ext4/054 > because it always crashes on both unpatched and patched Bionic and Focal > kernels. > Other than that, the test results are the same. > > [Potential regression] > High. This needs to be reviewed very carefully. > > Jan Kara (1): > ext4: fix check for block being out of directory size > > Lukas Czerner (1): > ext4: check if directory block is within i_size > > fs/ext4/namei.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > -- > 2.39.2 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team >
On 23-06-12 13:04:25, Luke Nowakowski-Krijger wrote: > The #2 patch no longer applies for focal and should be revisited to > backport. Thanks. Will look into that later. > > I have not looked at the Bionic patch and leave Cascardo to apply that one > as that has now gone esm. > > - Luke > > On Wed, May 17, 2023 at 9:13 AM Cengiz Can <cengiz.can@canonical.com> wrote: >
It did apply correctly, however the emails were being generated it was applying them in the opposite order which was leading to the apply conflicts. Sorry for the confusion. Applied to focal:linux master-next. Thanks Cengiz :) - Luke On Wed, May 17, 2023 at 9:13 AM Cengiz Can <cengiz.can@canonical.com> wrote: > [Impact] > A use-after-free flaw was found in fs/ext4/namei.c:dx_insert_block() in the > Linux kernel’s filesystem sub-component. This flaw allows a local attacker > with > a user privilege to cause a denial of service. > > [Fix] > This was tricky. I had to dive deep into other vendors' bugzillas and irc > channels to verify if the patches were enough. > > The fix consists of: > ext4: verify dir block before splitting it > ext4: avoid cycles in directory h-tree > ext4: check if directory block is within i_size > > The following fixes one of the fixing commits: > ext4: fix check for block being out of directory size > > The following was suggested to be included but I don't know the actual > impact: > ext4: make sure ext4_append() always allocates new block > > Out of these five commits, 3 were already in Bionic and Focal. I > backported or > cherry-picked the missing 2 to Bionic and Focal. > > [Test case] > I ran xfstests that specifically target ext4, with the exception of > ext4/054 > because it always crashes on both unpatched and patched Bionic and Focal > kernels. > Other than that, the test results are the same. > > [Potential regression] > High. This needs to be reviewed very carefully. > > Jan Kara (1): > ext4: fix check for block being out of directory size > > Lukas Czerner (1): > ext4: check if directory block is within i_size > > fs/ext4/namei.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > -- > 2.39.2 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team >
On Wed, 17 May 2023 19:12:26 +0300, Cengiz Can wrote: > [Impact] > A use-after-free flaw was found in fs/ext4/namei.c:dx_insert_block() in the > Linux kernel’s filesystem sub-component. This flaw allows a local attacker with > a user privilege to cause a denial of service. > > [Fix] > This was tricky. I had to dive deep into other vendors' bugzillas and irc > channels to verify if the patches were enough. > > [...] Applied, thanks! [1/2] ext4: check if directory block is within i_size commit: 7318510c9d9b81fcefd6d2336b00a9575b367edc [2/2] ext4: fix check for block being out of directory size commit: 312e1fc9abf64dac0c2b9aa90885715df7acabea Best regards,