From patchwork Tue Jun 16 17:28:26 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 224305 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B438AC433DF for ; Tue, 16 Jun 2020 17:28:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 960EB21508 for ; Tue, 16 Jun 2020 17:28:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592328509; bh=5VVqOGMd8qDG8w1nvDuho39N0fSiV5sG0+LCTBGflMg=; h=Date:From:To:Subject:List-ID:From; b=QdeHbCvtPENmYn2rxJIjxCMLJvnnl28KL8PtfB8xSxvQLd2tntOm+76b4Tt32tB2V qWc++nJDy31wyFkt5eGYMiw/rcvumqMASyb2uHH8uYyhWOO9DzqF8fT273Px8bF/pg NjPpgghw6zr+3PafoufVCNJDh4B7olBA74z1lAfQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731064AbgFPR23 (ORCPT ); Tue, 16 Jun 2020 13:28:29 -0400 Received: from mail.kernel.org ([198.145.29.99]:45442 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730790AbgFPR21 (ORCPT ); Tue, 16 Jun 2020 13:28:27 -0400 Received: from localhost.localdomain (c-71-198-47-131.hsd1.ca.comcast.net [71.198.47.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 92A8920707; Tue, 16 Jun 2020 17:28:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1592328506; bh=5VVqOGMd8qDG8w1nvDuho39N0fSiV5sG0+LCTBGflMg=; h=Date:From:To:Subject:From; b=xkP24mv15Cgbj6aQvwVMlDGcS6velMcXUYCMttCP3L7iTm3WpqU0ePvyeKcvbD3zV WjRNVqHUjCzNpqXLcLHACtfaSvUOdWFdpqrxXXBdY/PwOfVAph+6BkV/J32iCNgOwJ QfTtVCyECYucgiDuQNjiq7bCFp56gMEeOjviVik8= Date: Tue, 16 Jun 2020 10:28:26 -0700 From: akpm@linux-foundation.org To: dave.rodgman@arm.com, mark.rutland@arm.com, markus@oberhumer.com, minchan@kernel.org, mm-commits@vger.kernel.org, ngupta@vflare.org, sergey.senozhatsky.work@gmail.com, stable@vger.kernel.org, w@1wt.eu, yuchao0@huawei.com Subject: [merged] lib-lzo-fix-ambiguous-encoding-bug-in-lzo-rle.patch removed from -mm tree Message-ID: <20200616172826.HY40zfret%akpm@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org The patch titled Subject: lib/lzo: fix ambiguous encoding bug in lzo-rle has been removed from the -mm tree. Its filename was lib-lzo-fix-ambiguous-encoding-bug-in-lzo-rle.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Dave Rodgman Subject: lib/lzo: fix ambiguous encoding bug in lzo-rle In some rare cases, for input data over 32 KB, lzo-rle could encode two different inputs to the same compressed representation, so that decompression is then ambiguous (i.e. data may be corrupted - although zram is not affected because it operates over 4 KB pages). This modifies the compressor without changing the decompressor or the bitstream format, such that: - there is no change to how data produced by the old compressor is decompressed - an old decompressor will correctly decode data from the updated compressor - performance and compression ratio are not affected - we avoid introducing a new bitstream format In testing over 12.8M real-world files totalling 903 GB, three files were affected by this bug. I also constructed 37M semi-random 64 KB files totalling 2.27 TB, and saw no affected files. Finally I tested over files constructed to contain each of the ~1024 possible bad input sequences; for all of these cases, updated lzo-rle worked correctly. There is no significant impact to performance or compression ratio. Link: http://lkml.kernel.org/r/20200507100203.29785-1-dave.rodgman@arm.com Signed-off-by: Dave Rodgman Cc: Mark Rutland Cc: Dave Rodgman Cc: Willy Tarreau Cc: Sergey Senozhatsky Cc: Markus F.X.J. Oberhumer Cc: Minchan Kim Cc: Nitin Gupta Cc: Chao Yu Cc: Signed-off-by: Andrew Morton --- Documentation/lzo.txt | 8 ++++++-- lib/lzo/lzo1x_compress.c | 13 +++++++++++++ 2 files changed, 19 insertions(+), 2 deletions(-) --- a/Documentation/lzo.txt~lib-lzo-fix-ambiguous-encoding-bug-in-lzo-rle +++ a/Documentation/lzo.txt @@ -159,11 +159,15 @@ Byte sequences distance = 16384 + (H << 14) + D state = S (copy S literals after this block) End of stream is reached if distance == 16384 + In version 1 only, to prevent ambiguity with the RLE case when + ((distance & 0x803f) == 0x803f) && (261 <= length <= 264), the + compressor must not emit block copies where distance and length + meet these conditions. In version 1 only, this instruction is also used to encode a run of - zeros if distance = 0xbfff, i.e. H = 1 and the D bits are all 1. + zeros if distance = 0xbfff, i.e. H = 1 and the D bits are all 1. In this case, it is followed by a fourth byte, X. - run length = ((X << 3) | (0 0 0 0 0 L L L)) + 4. + run length = ((X << 3) | (0 0 0 0 0 L L L)) + 4 0 0 1 L L L L L (32..63) Copy of small block within 16kB distance (preferably less than 34B) --- a/lib/lzo/lzo1x_compress.c~lib-lzo-fix-ambiguous-encoding-bug-in-lzo-rle +++ a/lib/lzo/lzo1x_compress.c @@ -268,6 +268,19 @@ m_len_done: *op++ = (M4_MARKER | ((m_off >> 11) & 8) | (m_len - 2)); else { + if (unlikely(((m_off & 0x403f) == 0x403f) + && (m_len >= 261) + && (m_len <= 264)) + && likely(bitstream_version)) { + // Under lzo-rle, block copies + // for 261 <= length <= 264 and + // (distance & 0x80f3) == 0x80f3 + // can result in ambiguous + // output. Adjust length + // to 260 to prevent ambiguity. + ip -= m_len - 260; + m_len = 260; + } m_len -= M4_MAX_LEN; *op++ = (M4_MARKER | ((m_off >> 11) & 8)); while (unlikely(m_len > 255)) {