mbox series

[SRU,F,0/1] CVE-2023-52497

Message ID 20241010195208.1956936-1-jacob.martin@canonical.com
Headers show
Series CVE-2023-52497 | expand

Message

Jacob Martin Oct. 10, 2024, 7:52 p.m. UTC
[Impact]

The kernel's LZ4 decompression algorithm expects that data being in-place
decompressed is located at the end of the end of the output buffer. The EROFS
implementation will map in and out buffers without a guarantee on their
ordering. While this is incorrect behavior on all CPUs, x86 CPUs declaring the
FSRM capability have a memmove implementation that is particularly affected by
this misordering, resulting in frequent data corruption. Resolve the issue by
always using the output buffer for in-place decompression, with the compressed
data placed at the end of it.

[Fix]

Noble: Fix released
Jammy: Fix released
Focal: Clean cherry-pick from linux-5.10.y stable branch
Bionic: Not affected
Xenial: Not affected
Trusty: Not affected

[Test Case]

Compile tested. Verified that an EROFS filesystem could be created, mounted,
and read from with its data intact while this patch was applied.

# mkdir erofs_test_data erofs_test_mnt
# for i in {0..9}; do dd if=/dev/urandom of="erofs_test_data/test$i" bs=1M count=1; done
# mkfs.erofs -z lz4 erofs_test.img erofs_test_data
# modprobe erofs
# mount -o loop erofs_test.img erofs_test_mnt
# diff -qr erofs_test_data erofs_test_mnt

[Where problems could occur]

This fix modifies the LZO decompression behavior of the EROFS filesystem
specifically.  Issues with this fix are likely to only affect use of the EROFS
filesystem.

Gao Xiang (1):
  erofs: fix lz4 inplace decompression

 fs/erofs/decompressor.c | 24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)

Comments

Guoqing Jiang Oct. 11, 2024, 1:33 a.m. UTC | #1
Acked-by: Guoqing Jiang <guoqing.jiang@canonical.com>

> [Impact]
>
> The kernel's LZ4 decompression algorithm expects that data being in-place
> decompressed is located at the end of the end of the output buffer. The EROFS
> implementation will map in and out buffers without a guarantee on their
> ordering. While this is incorrect behavior on all CPUs, x86 CPUs declaring the
> FSRM capability have a memmove implementation that is particularly affected by
> this misordering, resulting in frequent data corruption. Resolve the issue by
> always using the output buffer for in-place decompression, with the compressed
> data placed at the end of it.
>
> [Fix]
>
> Noble: Fix released
> Jammy: Fix released
> Focal: Clean cherry-pick from linux-5.10.y stable branch
> Bionic: Not affected
> Xenial: Not affected
> Trusty: Not affected
>
> [Test Case]
>
> Compile tested. Verified that an EROFS filesystem could be created, mounted,
> and read from with its data intact while this patch was applied.
>
> # mkdir erofs_test_data erofs_test_mnt
> # for i in {0..9}; do dd if=/dev/urandom of="erofs_test_data/test$i" bs=1M count=1; done
> # mkfs.erofs -z lz4 erofs_test.img erofs_test_data
> # modprobe erofs
> # mount -o loop erofs_test.img erofs_test_mnt
> # diff -qr erofs_test_data erofs_test_mnt
>
> [Where problems could occur]
>
> This fix modifies the LZO decompression behavior of the EROFS filesystem
> specifically.  Issues with this fix are likely to only affect use of the EROFS
> filesystem.
>
> Gao Xiang (1):
>    erofs: fix lz4 inplace decompression
>
>   fs/erofs/decompressor.c | 24 ++++++++++++++----------
>   1 file changed, 14 insertions(+), 10 deletions(-)
>
ivanhu Oct. 11, 2024, 2:36 a.m. UTC | #2
Acked-by: Ivan Hu <ivan.hu@canonical.com>


On 10/11/24 03:52, Jacob Martin wrote:
> [Impact]
> 
> The kernel's LZ4 decompression algorithm expects that data being in-place
> decompressed is located at the end of the end of the output buffer. The EROFS
> implementation will map in and out buffers without a guarantee on their
> ordering. While this is incorrect behavior on all CPUs, x86 CPUs declaring the
> FSRM capability have a memmove implementation that is particularly affected by
> this misordering, resulting in frequent data corruption. Resolve the issue by
> always using the output buffer for in-place decompression, with the compressed
> data placed at the end of it.
> 
> [Fix]
> 
> Noble: Fix released
> Jammy: Fix released
> Focal: Clean cherry-pick from linux-5.10.y stable branch
> Bionic: Not affected
> Xenial: Not affected
> Trusty: Not affected
> 
> [Test Case]
> 
> Compile tested. Verified that an EROFS filesystem could be created, mounted,
> and read from with its data intact while this patch was applied.
> 
> # mkdir erofs_test_data erofs_test_mnt
> # for i in {0..9}; do dd if=/dev/urandom of="erofs_test_data/test$i" bs=1M count=1; done
> # mkfs.erofs -z lz4 erofs_test.img erofs_test_data
> # modprobe erofs
> # mount -o loop erofs_test.img erofs_test_mnt
> # diff -qr erofs_test_data erofs_test_mnt
> 
> [Where problems could occur]
> 
> This fix modifies the LZO decompression behavior of the EROFS filesystem
> specifically.  Issues with this fix are likely to only affect use of the EROFS
> filesystem.
> 
> Gao Xiang (1):
>    erofs: fix lz4 inplace decompression
> 
>   fs/erofs/decompressor.c | 24 ++++++++++++++----------
>   1 file changed, 14 insertions(+), 10 deletions(-)
>
Stefan Bader Oct. 11, 2024, 9:50 a.m. UTC | #3
On 10.10.24 21:52, Jacob Martin wrote:
> [Impact]
> 
> The kernel's LZ4 decompression algorithm expects that data being in-place
> decompressed is located at the end of the end of the output buffer. The EROFS
> implementation will map in and out buffers without a guarantee on their
> ordering. While this is incorrect behavior on all CPUs, x86 CPUs declaring the
> FSRM capability have a memmove implementation that is particularly affected by
> this misordering, resulting in frequent data corruption. Resolve the issue by
> always using the output buffer for in-place decompression, with the compressed
> data placed at the end of it.
> 
> [Fix]
> 
> Noble: Fix released
> Jammy: Fix released
> Focal: Clean cherry-pick from linux-5.10.y stable branch
> Bionic: Not affected
> Xenial: Not affected
> Trusty: Not affected
> 
> [Test Case]
> 
> Compile tested. Verified that an EROFS filesystem could be created, mounted,
> and read from with its data intact while this patch was applied.
> 
> # mkdir erofs_test_data erofs_test_mnt
> # for i in {0..9}; do dd if=/dev/urandom of="erofs_test_data/test$i" bs=1M count=1; done
> # mkfs.erofs -z lz4 erofs_test.img erofs_test_data
> # modprobe erofs
> # mount -o loop erofs_test.img erofs_test_mnt
> # diff -qr erofs_test_data erofs_test_mnt
> 
> [Where problems could occur]
> 
> This fix modifies the LZO decompression behavior of the EROFS filesystem
> specifically.  Issues with this fix are likely to only affect use of the EROFS
> filesystem.
> 
> Gao Xiang (1):
>    erofs: fix lz4 inplace decompression
> 
>   fs/erofs/decompressor.c | 24 ++++++++++++++----------
>   1 file changed, 14 insertions(+), 10 deletions(-)
> 

Applied to focal:linux/master-next. Thanks.

-Stefan