All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vasiliy Kovalev <kovalev@altlinux.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Michal Nazarewicz <m.nazarewicz@samsung.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	lvc-project@linuxtesting.org, kovalev@altlinux.org
Subject: [PATCH] usb: gadget: f_fs: use __GFP_NOWARN for user-controlled buffer allocation
Date: Thu,  9 Jul 2026 12:18:35 +0300	[thread overview]
Message-ID: <20260709091835.259708-1-kovalev@altlinux.org> (raw)

ffs_alloc_buffer() passes iov_iter_count() of a userspace read(2) or
write(2) buffer directly to kmalloc() when the UDC does not support
scatter-gather (gadget->sg_supported == false). There is no upper
bound imposed on data_len before it reaches kmalloc().

If a userspace program issues a read/write large enough that the
resulting order exceeds the page allocator's MAX_PAGE_ORDER, kmalloc()
routes to the page allocator which triggers a WARN_ON_ONCE before
returning NULL. The allocation failure is already handled correctly
via -ENOMEM in ffs_epfile_io(), so the WARN carries no additional
diagnostic value. On systems booted with panic_on_warn=1 this WARN
becomes fatal.

Use __GFP_NOWARN so oversized allocations quietly fall back to
-ENOMEM, matching the existing error path.

Found by Linux Verification Center (linuxtesting.org) with Svace static
analysis tool.

Fixes: ddf8abd25994 ("USB: f_fs: the FunctionFS driver")
Cc: stable@vger.kernel.org
Signed-off-by: Vasiliy Kovalev <kovalev@altlinux.org>
---
 drivers/usb/gadget/function/f_fs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index 44218be1e676..e44b441b844b 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -843,7 +843,7 @@ static inline void *ffs_alloc_buffer(struct ffs_io_data *io_data,
 	if (io_data->use_sg)
 		return ffs_build_sg_list(&io_data->sgt, data_len);
 
-	return kmalloc(data_len, GFP_KERNEL);
+	return kmalloc(data_len, GFP_KERNEL | __GFP_NOWARN);
 }
 
 static inline void ffs_free_buffer(struct ffs_io_data *io_data)
-- 
2.50.1


                 reply	other threads:[~2026-07-09  9:18 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20260709091835.259708-1-kovalev@altlinux.org \
    --to=kovalev@altlinux.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lvc-project@linuxtesting.org \
    --cc=m.nazarewicz@samsung.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.