lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4816d981-3955-495c-8fc6-3b9b15ba1689@quicinc.com>
Date: Fri, 8 Mar 2024 17:47:37 +0530
From: Krishna Kurapati PSSNV <quic_kriskura@...cinc.com>
To: Hardik Gajjar <hgajjar@...adit-jv.com>
CC: <gregkh@...uxfoundation.org>, <maze@...gle.com>,
        <linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <guofeng.li@...com>, <hardik.gajjar@...ch.com>,
        <eugeniu.rosca@...ch.com>
Subject: Re: [PATCH] usb: gadget: f_ncm: Fix Kernel Panic due to access of
 invalid gadget ptr



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,

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ