Linux USB
 help / color / mirror / Atom feed
From: Neill Kapron <nkapron@google.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Neill Kapron <nkapron@google.com>
Cc: kernel-team@android.com, kernel test robot <lkp@intel.com>,
	linux-usb@vger.kernel.org,  linux-kernel@vger.kernel.org
Subject: [PATCH] usb: gadget: f_fs: Fix -Wformat-truncation in proxy endpoint names
Date: Fri, 24 Jul 2026 21:56:14 +0000	[thread overview]
Message-ID: <20260724215615.4160303-1-nkapron@google.com> (raw)

When using the functionfs rw_proxy feature, proxy endpoint names are
generated by appending "_rw" to the base endpoint name. The base
endpoint name is copied via `snprintf` into an 8-byte buffer
(`comp->name`). On some architectures (e.g., s390), the compiler flags
a `-Wformat-truncation` warning because `%s_rw` could potentially
overflow if the source string is unexpectedly long.

Fix this by specifying a maximum field width of 4 characters
when formatting the endpoint name string. This guarantees that at most
4 characters plus the 3 characters "_rw" (and null terminator) will be
written, fitting within the 8-byte limit.

Note that this is purely to address the compiler static analysis. In
practice, `FFS_MAX_EPS_COUNT` is limited to 31, meaning the longest
possible base endpoint name is "ep30", and therefore the resulting
proxy name, "ep30_rw", is exactly 7 characters.

Fixes: 0f0ea552cd21 ("usb: gadget: f_fs: Introduce rw_proxy file descriptors")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202607111052.PRRGX3Jq-lkp@intel.com/
Assisted-by: Antigravity:gemini-3.1-pro
Signed-off-by: Neill Kapron <nkapron@google.com>
---
 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 073c4cbd90fb..3f0b445aba19 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2441,7 +2441,7 @@ static int ffs_epfiles_create(struct ffs_data *ffs)
 			mutex_init(&comp->mutex);
 			mutex_init(&comp->dmabufs_mutex);
 			INIT_LIST_HEAD(&comp->dmabufs);
-			snprintf(comp->name, sizeof(comp->name), "%s_rw",
+			snprintf(comp->name, sizeof(comp->name), "%.4s_rw",
 				 epfiles[i].name);
 			err = ffs_sb_create_file(ffs->sb, comp->name,
 						 comp, &ffs_epfile_operations);
-- 
2.55.0.229.g6434b31f56-goog


                 reply	other threads:[~2026-07-24 21:56 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=20260724215615.4160303-1-nkapron@google.com \
    --to=nkapron@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=lkp@intel.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