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: <aPf5DZVYrc2YAXXT@mozart.vkv.me>
Date: Tue, 21 Oct 2025 14:20:13 -0700
From: Calvin Owens <calvin@...nvd.org>
To: Francesco Valla <francesco@...la.it>
Cc: Marcel Holtmann <marcel@...tmann.org>,
	Luiz Augusto von Dentz <luiz.dentz@...il.com>,
	Paul Menzel <pmenzel@...gen.mpg.de>,
	linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [BUG] Erratic behavior in btnxpuart on v6.18-rc2 - and a
 possible solution

On Tuesday 10/21 at 22:53 +0200, Francesco Valla wrote:
> Hello,
> 
> while testing Bluetooth on my NXP i.MX93 FRDM, which is equipped with an IW612
> Bluetooth chipset from NXP, I encountered an erratic bug during initialization.
> 
> While the firmware download always completed without errors, subsequent HCI
> communication would fail most of the time with:
> 
>     Frame reassembly failed (-84)
> 
> After some debug, I found the culprit to be this patch that was integrated as
> part of the current (v6.18) cycle:
> 
>     93f06f8f0daf Bluetooth: remove duplicate h4_recv_buf() in header [1]
> 
> The reason is simple: the h4_recv_buf() function from hci_h4.c, which is now
> used instead the "duplicated" one in the (now removed) h4_recv_buf.h, assumes
> that the private drvdata for the input struct hci_dev is a pointer to a
> struct hci_uart, but that's not the case for the btnxpuart driver. In this
> case, the information about padding and alignment are pretty random and
> depend on the content of the data that was incorrectly casted as a
> struct hci_uart.
> 
> The bug should impact also the other platforms that were touched by the
> same patch. 

Hi Francesco,

Thanks for investigating, this makes sense to me.

Funny enough, I specifically tested this on btnxpuart and saw no
problems. I suppose some kconfig difference or some other innocuous
patch moved structure fields around such that it triggered for you?
Not that it really matters...

> For the time being, I'd then propose to revert the commit.

Adding back all the duplicate code is not the right way forward, IMHO.
There must be some way to "mask" the problematic behavior for the
drivers which stash the different structure in drvdata, right?

Any thoughts from anybody else? I should have time to spin something up
tomorrow, if nobody beats me to it.

Thanks,
Calvin

> Thank you
> 
> Regards,
> Francesco Valla
> 
> [1] https://lore.kernel.org/linux-bluetooth/be8edf7f8ba8dea6c61272b02fb20a4ac7e1c5a5.1756179634.git.calvin@wbinvd.org/
> 
> 
> 
>  
> 
> 
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ