From: Benjamin Tissoires <bentiss@kernel.org>
To: "Günther Noack" <gnoack@google.com>
Cc: Jiri Kosina <jikos@kernel.org>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] HID: apple: avoid memory leak in apple_report_fixup()
Date: Tue, 17 Feb 2026 19:22:20 +0100 [thread overview]
Message-ID: <aZSxeusondD26uN3@plouf> (raw)
In-Reply-To: <20260217160125.1097578-2-gnoack@google.com>
On Feb 17 2026, Günther Noack wrote:
> The apple_report_fixup() function was allocating a new buffer with
> kmemdup() but never freeing it. Since the caller of report_fixup() already
> provides a writable buffer and allows returning a pointer within that
> buffer, we can just modify the descriptor in-place and return the adjusted
> pointer.
>
> Assisted-by: Gemini-CLI:Google Gemini 3
> Signed-off-by: Günther Noack <gnoack@google.com>
> ---
> drivers/hid/hid-apple.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> index 233e367cce1d..894adc23367b 100644
> --- a/drivers/hid/hid-apple.c
> +++ b/drivers/hid/hid-apple.c
> @@ -686,9 +686,7 @@ static const __u8 *apple_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> hid_info(hdev,
> "fixing up Magic Keyboard battery report descriptor\n");
> *rsize = *rsize - 1;
> - rdesc = kmemdup(rdesc + 1, *rsize, GFP_KERNEL);
> - if (!rdesc)
> - return NULL;
> + rdesc = rdesc + 1;
I might be wrong, but later we call free(dev->rdesc) on device removal.
AFAICT, incrementing the pointer is undefined behavior.
What we should do instead is probably a krealloc instead of a kmemdup.
Same for all 3 patches.
Cheers,
Benjamin
>
> rdesc[0] = 0x05;
> rdesc[1] = 0x01;
> --
> 2.53.0.335.g19a08e0c02-goog
>
next prev parent reply other threads:[~2026-02-17 18:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-17 16:01 [PATCH 0/3] HID: Fix some memory leaks in drivers/hid Günther Noack
2026-02-17 16:01 ` [PATCH 1/3] HID: apple: avoid memory leak in apple_report_fixup() Günther Noack
2026-02-17 18:22 ` Benjamin Tissoires [this message]
2026-02-17 19:42 ` Günther Noack
2026-02-18 19:04 ` Benjamin Tissoires
2026-02-19 15:47 ` Günther Noack
2026-02-17 16:01 ` [PATCH 2/3] HID: magicmouse: avoid memory leak in magicmouse_report_fixup() Günther Noack
2026-02-17 16:01 ` [PATCH 3/3] HID: asus: avoid memory leak in asus_report_fixup() Günther Noack
2026-02-17 18:31 ` Benjamin Tissoires
2026-02-17 19:51 ` Günther Noack
2026-02-17 18:36 ` [PATCH 0/3] HID: Fix some memory leaks in drivers/hid Benjamin Tissoires
2026-02-17 20:08 ` Günther Noack
-- strict thread matches above, loose matches on Subject: below --
2026-02-18 4:04 [PATCH 1/3] HID: apple: avoid memory leak in apple_report_fixup() kernel test robot
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=aZSxeusondD26uN3@plouf \
--to=bentiss@kernel.org \
--cc=gnoack@google.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.