From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE81B2F6596 for ; Tue, 4 Aug 2026 05:30:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785821404; cv=none; b=NCkj4v7OWODhVad6eYtRzsHTpUg/c2yu4HnSo43SBq6gBse21/N+HofEEYO/bPFm7w9SNk4XCywWiKdlbhAFy9hwWT8WbUIeGi2OABLVGXpmfUp0ntqgWnqXFXFJq6LBLUZfikGPceO9/7cseZG4b+Xl+87FPUs/QRgmp9Nfv5U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785821404; c=relaxed/simple; bh=YkxXa7L95NopuQRDvJdFPY0Pb0SGtzjE4U693oKo17w=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=foVHlQl9YJs6nYHZQDh54k1KHVc2X/d6birPJaTvLmKVjx2PkK5S7xjHLwrJvPEHjNyat6MOdbAtRilgyw1i59RvjxPx2fg/448DY2lN4JyvhZOycnMdQwUCEejSsmjQsn4kVK8JPUFhGYmvEWjPtvE+m2uk1TtCPBblFW4Jl/Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=MLXbkmZS; arc=none smtp.client-ip=209.85.221.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MLXbkmZS" Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-47fd4ee0b01so2679373f8f.2 for ; Mon, 03 Aug 2026 22:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785821401; x=1786426201; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=O9H0G8wGK/G7J/VsG3O96wn6Q+Lkqndi1cJmBYpye34=; b=MLXbkmZSjWanITYuEELoW3nxuFPQ4DJ+kBR5BYynCsKM17F+5HGiOH1nFTUxbRLUZj MYuT7QNzaiKGbcJ261CZu9iKhND/S8+crFdYHRBth09URE8/dMxOhlXCif+exrtydkjx gT8x7l7MsXXs0KTYI5iNQSF41nALc1wDDo72dQCOdyAbODas3+nFPDDKoH9mcsZ6C6iq eujg5UqWsMgT6LvhSWbxujzzakHHXalTpx2BrnGCefq3r6ZdxZ3UN3S5EJbtwvkwKQyt fqV1z9A1wRG9MiQIlbDe2gww+LpewasjoEMEKj6VOPBROrbLQCWwA5p0n4Uarq9XXD+w sK/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785821401; x=1786426201; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=O9H0G8wGK/G7J/VsG3O96wn6Q+Lkqndi1cJmBYpye34=; b=W8WYLwNNPNrM97QAgY410qbjIO/TixnAWobKGHw3mKpjgRZ/CZRx+bzcl0aj+bD/I9 21O0/zOJc8McsufHUgkyk9YuhjPx6OvQch+p4OPG7u5TY/qV36BgAaNOICMe6oCyrQ0+ ubInApX/TULhF4nmzq8/oGJsSPzELFT8Armn/R3rMJ67kYQnKbGpeAWMfj1WuQ4dVBV+ Mv7ZMkFJFVLpdtiP2l2qfCzTTnjb1qE8CuicGDBUvcCm+VU2VNe7is4KPGdFlZPYYfGg EHKcEMSOv7iBwDenYbwDcubIsJ3nqgXbs9i2XvuHa5BWH5VZS+5F2OXVRr/SNG603KZD pjmg== X-Forwarded-Encrypted: i=1; AHgh+RpcunshxaLx/sYhE/rdhXMeo2oGeb2fT0ifdZLTHCNcUjP33wUxfgcD/D+zw9ImT81mjVTPChZtf5mjm8M=@vger.kernel.org X-Gm-Message-State: AOJu0YyKubESu5RASbeeWiNRqTls2mWBuaMj/Gl8Q414yblFLnzOzG2s Mjp6IH45EGB9df4mMI/QixsMVvquIx9Uwr/BH2FGr7DR/c2KXeo/DdLJ X-Gm-Gg: AR+sD12VDrlT52Q3Lv7rAtBa1vV5QN3w8M+CipXU/iA7mwPFU4TmeL/RwPAY7zDNCFI w24XNGp9+LSbDNumoPzP8s1cOkKwKGvom6jcKq89I/JN8eVtvcXpUn2a2SuKPzCqKJ0y6znayLh nnsXX4hGdt6sHUtZfOPmJ6VLbvEEhuex+M55VJDSipPb/hY6bhCDUFIKlYys3NLvMHc41e1OTtA 7v81/N0jJH8sPo9/pCAEgifFsn9Y1+9q8qg+JEERdJd8vI/IsMoVWDsdufN9E8+wnfoljHBeb7a efZUfSe8BplnENVl9/KwIKH4CqrBXb2Y/6regPfa4lt5n3Ww8n3hwwv+sZk/CMJgx/3IeNd3AL4 IboFzjLG9ygPJni3gXiUDyFfFyl4YvHBl6VBnNFxjRJik66Zo3GDh0eTmLQWj1xGxiUhsC8NCCe oeLhPdLGNmc21fopjH+8oaNNVal+H2k8yUHNwCmhUHgDq0c6ruPfe5LRyVBat+S7S94x7wI31F/ vFvX8rUZWiChrDkuw5NpDaJIsLIGng9tJucHA4G/wn2Xo7ghVe5YzWDevkOr0mQ2zwy4c5TMdmh 8L1fJbRsxBlvTPOAl7RgX3Eog7x/Szx5V662qriQL3Tn X-Received: by 2002:a05:600c:c3c1:10b0:495:63e4:7f78 with SMTP id 5b1f17b1804b1-4980c672b1cmr228057155e9.10.1785821400825; Mon, 03 Aug 2026 22:30:00 -0700 (PDT) Received: from riacini.speedport.ip (p200300fcd73d5bf61133fc1760631ad5.dip0.t-ipconnect.de. [2003:fc:d73d:5bf6:1133:fc17:6063:1ad5]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49949fdf392sm91693335e9.11.2026.08.03.22.29.59 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 03 Aug 2026 22:30:00 -0700 (PDT) From: Rituparna Warwatkar To: Greg Kroah-Hartman Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Rituparna Warwatkar , syzbot+54927260acba030187a6@syzkaller.appspotmail.com Subject: [PATCH v2] usb: gadget: uvc: align XU descriptor pointers to fix kmemleak reports Date: Tue, 4 Aug 2026 07:29:47 +0200 Message-ID: <20260804052947.15277-1-rwarwatkar@gmail.com> X-Mailer: git-send-email 2.50.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit kmemleak reports the baSourceID and bmControls arrays allocated by the UVC extension-unit configfs attributes as leaked, e.g.: BUG: memory leak unreferenced object 0xffff888114fee2c0 (size 8): __kmalloc_noprof uvcg_extension_ba_source_id_store configfs_write_iter vfs_write ksys_write The arrays are not actually leaked: they are reachable through xu->desc.baSourceID / xu->desc.bmControls and are freed when the extension unit is removed. The problem is that struct uvcg_extension_unit_descriptor is marked __packed, so these two heap pointers are stored at unaligned offsets. kmemleak only scans memory on pointer-aligned boundaries, so it never sees the pointers and reports the arrays as unreferenced. Unlike the UAPI struct uvc_extension_unit_descriptor, this is an in-memory staging structure: baSourceID and bmControls are pointers, not inline arrays, and the wire descriptor is assembled field by field in UVC_COPY_XU_DESCRIPTOR(). So __packed is not needed for layout correctness and only serves to misalign the pointers. Drop __packed and move the two remaining scalar members (bControlSize and iExtension) ahead of the pointers so that baSourceID lands on a natural 8-byte boundary. This keeps the pointers aligned and visible to kmemleak while leaving the structure hole-free and the same size as before (40 bytes on 64-bit). The bLength..bNrInPins prefix is unchanged, so the "memcpy(dst, desc, 22)" in UVC_COPY_XU_DESCRIPTOR() and the wire descriptor layout are unaffected. Reported-by: syzbot+54927260acba030187a6@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=54927260acba030187a6 Fixes: 0525210c9840 ("usb: gadget: uvc: Allow definition of XUs in configfs") Suggested-by: Greg Kroah-Hartman Signed-off-by: Rituparna Warwatkar --- Changes in v2: - Rather than only dropping __packed (which left padding holes and grew the struct), reorder the members so bControlSize and iExtension precede the two pointers, grouping baSourceID and bmControls at a natural 8-byte boundary. The struct stays 40 bytes with no padding, and the bLength..bNrInPins prefix (and thus UVC_COPY_XU_DESCRIPTOR() and the wire layout) is unchanged. drivers/usb/gadget/function/uvc_configfs.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/function/uvc_configfs.h b/drivers/usb/gadget/function/uvc_configfs.h index 9391614135e..049fb9e14e4 100644 --- a/drivers/usb/gadget/function/uvc_configfs.h +++ b/drivers/usb/gadget/function/uvc_configfs.h @@ -172,11 +172,11 @@ struct uvcg_extension_unit_descriptor { u8 guidExtensionCode[16]; u8 bNumControls; u8 bNrInPins; - u8 *baSourceID; u8 bControlSize; - u8 *bmControls; u8 iExtension; -} __packed; + u8 *baSourceID; + u8 *bmControls; +}; struct uvcg_extension { struct config_item item; -- 2.47.3