RE: [PATCH] usb: gadget: f_ncm: Fix Kernel Panic due to access of invalid gadget ptr

[LI Qingwu]

> -----Original Message-----
> From: Kuen-Han Tsai <khtsai@xxxxxxxxxx>
> Sent: Thursday, January 29, 2026 12:04 PM
> To: LI Qingwu <qing-wu.li@xxxxxxxxxxxxxxxxxxxxxxx>
> Cc: hgajjar@xxxxxxxxxxxxxx; eugeniu.rosca@xxxxxxxxx;
> gregkh@xxxxxxxxxxxxxxxxxxx; guofeng.li@xxxxxx; hardik.gajjar@xxxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx; maze@xxxxxxxxxx;
> quic_kriskura@xxxxxxxxxxx; quic_linyyuan@xxxxxxxxxxx
> Subject: Re: [PATCH] usb: gadget: f_ncm: Fix Kernel Panic due to access of invalid
> gadget ptr
> 
> [You don't often get email from khtsai@xxxxxxxxxx. Learn why this is important
> at https://aka.ms/LearnAboutSenderIdentification ]
> 
> This email is not from Hexagon’s Office 365 instance. Please be careful while
> clicking links, opening attachments, or replying to this email.
> 
> 
> On Wed, Jan 28, 2026 at 6:49 PM LI Qingwu
> <qing-wu.li@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > > On Mon, Mar 11, 2024 at 01:04:18PM +0100, Hardik Gajjar wrote:
> > > > On Fri, Mar 08, 2024 at 05:47:37PM +0530, Krishna Kurapati PSSNV wrote:
> > > > >
> > > > >
> > > > > On 3/8/2024 5:25 PM, Hardik Gajjar wrote:
> > > > > > On Thu, Mar 07, 2024 at 11:12:07PM +0530, Krishna Kurapati PSSNV
> wrote:
> > > > > > >
> > > > >
> > > > > [...]
> > > > >
> > > > > >
> > > > > > I believe using gether_cleanup altogether may not be an optimal
> solution.
> > > > > > The creation and deletion of network interfaces should align with the
> behavior of each specific network driver.
> > > > > >
> > > > > > For instance, in the case of NCM, the usb0 interface is
> > > > > > created upon the creation of a directory in
> > > > > > config/usb_gadget/gX/functions/ncm.usb0, and it is removed
> > > > > > when the corresponding directory is deleted. This follows a standard
> flow observed in many network drivers, where interfaces are created during
> driver loading/probing and deleted during removal.
> > > > > >
> > > > >
> > > > > Hi Hardik,
> > > > >
> > > > >  Yeah. I observed this behavior.
> > > > >
> > > > > > Typically, deleting the gadget on every disconnection is not
> > > > > > considered a good practice, as it can negatively impact the user
> experience when accessing the gadget.
> > > > > >
> > > > >
> > > > > Got it. I was suspecting issues might come up during fast
> > > > > Plug-In/ Plug-Out cases as setting and cleanup of network interface
> might take some time.
> > > > >
> > > > > > In our specific scenario, retaining the usb0 network interface
> > > > > > has proven to enhance performance and stabilize connections.
> > > > > > Previous attempts to remove it resulted in an observed increase in time
> of 300ms, particularly at the start of Apple CarPlay sessions.
> > > > > >
> > > > >
> > > > > Thanks for this info. Makes sense to keep it in free_inst only.
> > > > > But my initial doubt only stemmed from the fact that actions
> > > > > taken during bind must be reversed during unbind.
> > > > >
> > > > > > Furthermore, it's important to highlight that in Qualcomm
> > > > > > products and msm kernels, the inclusion of gether_cleanup in
> > > > > > the unbind process was eventually reverted. While the specific
> > > > > > reason for reverting the patch is unknown, it suggests that
> > > > > > the addition may not have yielded the intended or required
> > > > > > results
> > > > > >
> > > > > > Following is the revert patch details in msm-5.4 kernel, if you want
> check it.
> > > > > >
> > > > > > Revert "usb: gadget: f_ncm: allocate/free net device upon driver
> bind/unbind"
> > > > > >
> > > > > > This reverts commit 006d8adf555a8c6d34113f564ade312d68abd3b3.
> > > > > >
> > > > > > Move back the allocation of netdevice to alloc_inst(),
> > > > > > one-time registration to bind(), deregistration and free to
> > > > > > rm_inst(). The UI update issue will be taken up with proper
> stakeholders.
> > > > > >
> > > > > > Change-Id: I56448b08f6796a43ec5b0dfe0dd2d42cdc0eec14
> > > > > >
> > > > >
> > > > > Agree. This was merged first in 4.19 downstream (most probably
> > > > > for car play use case only) and then reverted in 5.4. But
> > > > > present 4.19 code in QC still keeps it in unbind path. The only
> > > > > reason I suspect it was reverted was to get back on to same page
> > > > > with upstream driver (atleast starting from 5.10, this was the
> > > > > reasoning to remove gether_cleanup in unbind path and put it back in
> free_inst).
> > > > >
> > > > > Thanks,
> > > > > Krishna,
> > > >
> > > > Thanks Krinshna for your comment
> > > > Come to the first comment from Greg.
> > > >
> > > > > What commit id does this fix?
> > > > >
> > > > > thanks,
> > > > >
> > > > > greg k-h
> > > >
> > > > >Hi Greg,
> > > >
> > > > >The network device parent is not being properly cleaned up during
> > > > >unbind since the \ initial commit of the driver. In that case,
> > > > >should I mention the First commit ID of \ the driver as broken
> > > > >commit or would you advice to say, For example "Clean up netdev \
> parent in unbind".
> > > >
> > > > >Thanks,
> > > > >Hardik
> > > >
> > > > @Greg,
> > > >
> > > > Can you please provide guidance on how to proceed? Should I update the
> commit message to exclude the term 'Fix' in the title?
> > > >
> > > > Thanks,
> > > > Hardik
> > >
> > > Hi Greg,
> > >
> > > Should we move forward if there are no further comments?
> > >
> > > Thanks,
> > > Hardik
> >
> >
> > Hi Hardik and all,
> >
> > Gentle ping on this patch. I wanted to follow up on the status and see
> > if there have been any updates or alternative fixes applied.
> >
> > I have recently tested this patch on NXP iMX8MP platforms and can
> > confirm it successfully resolves the use-after-free panic issue.
> >
> > Best Regards
> > Li Qingwu
> 
> Hi Qingwu,
> 
> I recently submitted a patchset to address the lifetime mismatch between the
> network device and its parent gadget device for the NCM driver [1].
> 
> Could you please verify if this series resolves the problem for you?
> 
> [1]
> https://lore.kernel.org/all/20251230-ncm-refactor-v1-0-793e347bc7a7@xxxxxxxxxx
> Regards,
> Kuen-Han

Hi Kuen-Han,

I tested this series on i.MX8MP and confirmed it resolves the use-after-free panic.
Thanks a lot!

Best Regards
Qingwu