From patchwork Fri Jun 12 00:34:54 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 224566 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 96142C433E0 for ; Fri, 12 Jun 2020 00:34:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 71B4820884 for ; Fri, 12 Jun 2020 00:34:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591922096; bh=zz+R1tCrrdbQFLgkAtoix3CaVcItIv3OOhLFlcxW5VE=; h=Date:From:To:Subject:In-Reply-To:List-ID:From; b=kHhZSzIy3+/dPrrquhjAUzHuve2DHe9aFCCqH0LgVGMM1pkGsD0QHMOOlBG4OpfN9 q8VuVOe345Ut95mxM/Tgqjuk5CJXmpnT0KLMzBYC/3Z5PQp7WUqXw9NpexTTBo9kjD /xIQwxS8p+fwwWzKSKAzJUe0P18+Agj5aEJpxWeE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726305AbgFLAe4 (ORCPT ); Thu, 11 Jun 2020 20:34:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:50102 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726357AbgFLAe4 (ORCPT ); Thu, 11 Jun 2020 20:34:56 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (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 1EA8A20882; Fri, 12 Jun 2020 00:34:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1591922095; bh=zz+R1tCrrdbQFLgkAtoix3CaVcItIv3OOhLFlcxW5VE=; h=Date:From:To:Subject:In-Reply-To:From; b=ku99JAQfZY65Zi4/pqb7KDYGjjxaht62ddB6kDR8Kr9d6tpFEwETB05ILV7qEZBUd kOCxppxZtWW2m7THDNlyumzyo7MPFnDV4SLHZVDwrHPYT4D9t4bx/IWQHOp6/Hx01T Gml3HtZoboK7T/RAdinAYRstmOC+Jv6Df9fhBV7I= Date: Thu, 11 Jun 2020 17:34:54 -0700 From: Andrew Morton To: akpm@linux-foundation.org, dave.rodgman@arm.com, linux-mm@kvack.org, 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, torvalds@linux-foundation.org, w@1wt.eu, yuchao0@huawei.com Subject: [patch 4/5] lib/lzo: fix ambiguous encoding bug in lzo-rle Message-ID: <20200612003454.cUjqmKdwv%akpm@linux-foundation.org> In-Reply-To: <20200611173002.24352ae77ca6d6d7e65e4b2a@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 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)) {