netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: linux-crypto@vger.kernel.org
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Eric Biggers <ebiggers@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Haren Myneni <haren@us.ibm.com>, Nick Terrell <terrelln@fb.com>,
	Minchan Kim <minchan@kernel.org>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Jens Axboe <axboe@kernel.dk>,
	Giovanni Cabiddu <giovanni.cabiddu@intel.com>,
	Richard Weinberger <richard@nod.at>,
	David Ahern <dsahern@kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Steffen Klassert <steffen.klassert@secunet.com>,
	linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
	qat-linux@intel.com, linuxppc-dev@lists.ozlabs.org,
	linux-mtd@lists.infradead.org, netdev@vger.kernel.org
Subject: [RFC PATCH 05/21] ubifs: Pass worst-case buffer size to compression routines
Date: Tue, 18 Jul 2023 14:58:31 +0200	[thread overview]
Message-ID: <20230718125847.3869700-6-ardb@kernel.org> (raw)
In-Reply-To: <20230718125847.3869700-1-ardb@kernel.org>

Currently, the ubifs code allocates a worst case buffer size to
recompress a data node, but does not pass the size of that buffer to the
compression code. This means that the compression code will never use
the additional space, and might fail spuriously due to lack of space.

So let's multiply out_len by WORST_COMPR_FACTOR after allocating the
buffer. Doing so is guaranteed not to overflow, given that the preceding
kmalloc_array() call would have failed otherwise.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 fs/ubifs/journal.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/ubifs/journal.c b/fs/ubifs/journal.c
index dc52ac0f4a345f30..4e5961878f336033 100644
--- a/fs/ubifs/journal.c
+++ b/fs/ubifs/journal.c
@@ -1493,6 +1493,8 @@ static int truncate_data_node(const struct ubifs_info *c, const struct inode *in
 	if (!buf)
 		return -ENOMEM;
 
+	out_len *= WORST_COMPR_FACTOR;
+
 	dlen = le32_to_cpu(dn->ch.len) - UBIFS_DATA_NODE_SZ;
 	data_size = dn_size - UBIFS_DATA_NODE_SZ;
 	compr_type = le16_to_cpu(dn->compr_type);
-- 
2.39.2


  parent reply	other threads:[~2023-07-18 12:59 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-18 12:58 [RFC PATCH 00/21] crypto: consolidate and clean up compression APIs Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 01/21] crypto: scomp - Revert "add support for deflate rfc1950 (zlib)" Ard Biesheuvel
2023-07-18 22:32   ` Eric Biggers
2023-07-18 22:54     ` Eric Biggers
2023-07-18 23:06       ` Ard Biesheuvel
2023-07-21  9:10   ` Simon Horman
2023-08-03  9:51   ` Giovanni Cabiddu
2023-08-03  9:59     ` Ard Biesheuvel
2023-08-03 10:29       ` Giovanni Cabiddu
2023-07-18 12:58 ` [RFC PATCH 02/21] crypto: qat - Drop support for allocating destination buffers Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 03/21] crypto: acompress - Drop destination scatterlist allocation feature Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 04/21] net: ipcomp: Migrate to acomp API from deprecated comp API Ard Biesheuvel
2023-07-21  9:11   ` Simon Horman
2023-07-18 12:58 ` Ard Biesheuvel [this message]
2023-07-18 22:38   ` [RFC PATCH 05/21] ubifs: Pass worst-case buffer size to compression routines Eric Biggers
2023-07-19  8:33     ` Ard Biesheuvel
2023-07-19 14:23       ` Zhihao Cheng
2023-07-19 14:38         ` Ard Biesheuvel
2023-07-20  1:23           ` Zhihao Cheng
2023-07-18 12:58 ` [RFC PATCH 06/21] ubifs: Avoid allocating buffer space unnecessarily Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 07/21] ubifs: Migrate to acomp compression API Ard Biesheuvel
2023-07-21  9:19   ` Simon Horman
2023-07-18 12:58 ` [RFC PATCH 08/21] zram: " Ard Biesheuvel
2023-07-21  9:22   ` Simon Horman
2023-07-18 12:58 ` [RFC PATCH 09/21] crypto: nx - Migrate to scomp API Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 10/21] crypto: 842 - drop obsolete 'comp' implementation Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 11/21] crypto: deflate " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 12/21] crypto: lz4 " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 13/21] crypto: lz4hc " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 14/21] crypto: lzo-rle " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 15/21] crypto: lzo " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 16/21] crypto: zstd " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 17/21] crypto: cavium/zip " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 18/21] crypto: compress_null " Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 19/21] crypto: remove obsolete 'comp' compression API Ard Biesheuvel
2023-07-21 11:07   ` Simon Horman
2023-07-18 12:58 ` [RFC PATCH 20/21] crypto: deflate - implement acomp API directly Ard Biesheuvel
2023-07-21 11:12   ` Simon Horman
2023-07-21 11:17     ` Ard Biesheuvel
2023-07-18 12:58 ` [RFC PATCH 21/21] crypto: scompress - Drop the use of per-cpu scratch buffers Ard Biesheuvel
2023-07-28  9:55 ` [RFC PATCH 00/21] crypto: consolidate and clean up compression APIs Herbert Xu
2023-07-28  9:57   ` Ard Biesheuvel
2023-07-28  9:59     ` Herbert Xu
2023-07-28 10:03       ` Ard Biesheuvel
2023-07-28 10:05         ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230718125847.3869700-6-ardb@kernel.org \
    --to=ardb@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=dsahern@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=edumazet@google.com \
    --cc=giovanni.cabiddu@intel.com \
    --cc=haren@us.ibm.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=keescook@chromium.org \
    --cc=kuba@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=minchan@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=qat-linux@intel.com \
    --cc=richard@nod.at \
    --cc=senozhatsky@chromium.org \
    --cc=steffen.klassert@secunet.com \
    --cc=terrelln@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).