linux-kernel - Re: [PATCH 3/3] ALSA: qc_audio_offload: try to reduce address space confusion

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <5d5ab559-4d01-4092-a872-2d0bb6ac5ebf@app.fastmail.com>
Date: Fri, 05 Sep 2025 16:50:53 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Luca Weiss" <luca.weiss@...rphone.com>, "Takashi Iwai" <tiwai@...e.de>
Cc: "Arnd Bergmann" <arnd@...nel.org>, "Mark Brown" <broonie@...nel.org>,
 "Wesley Cheng" <quic_wcheng@...cinc.com>, "Jaroslav Kysela" <perex@...ex.cz>,
 "Takashi Iwai" <tiwai@...e.com>,
 "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
 "Dan Carpenter" <dan.carpenter@...aro.org>, linux-sound@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] ALSA: qc_audio_offload: try to reduce address space confusion

On Fri, Sep 5, 2025, at 15:17, Luca Weiss wrote:
> On Fri Sep 5, 2025 at 2:08 PM CEST, Arnd Bergmann wrote:
>> On Fri, Sep 5, 2025, at 13:47, Luca Weiss wrote:
>>
>> This does mean that the address returned from xfer_buf is not
>> a kernel address in the virtual map though, and converting it
>> through virt_to_phys() makes the pa undefined for
>> uaudio_iommu_map(). Can you print what that pa value
>> is that you get here, and where that sits in the address space?
>
> Adding a debug print gives me the following below.
>
>   dev_err(uaudio_qdev->data->dev, "xfer_buf_pa=%llx\n", xfer_buf_pa);
>
> Not sure what exactly you mean with "where that sits in the address
> space" and how I can figure that out.
>
> [  130.124938] q6usb-dai 
> 3000000.remoteproc:glink-edge:apr:service@4:usbd: 
> xfer_buf_pa=ffffba0486ea6000

Splitting the address in 16-bit chunks, this is

0x00ff.ffba0.486ea.6000

which is well outside of the 40-bit physical address space of
the CPU, which confirms that the virtual address was not in
the linear map at all, and probably it should not get passed
into dma_get_sgtable() either.

>From what I can tell, this seems to correspond to a virtual
address in the vmalloc space instead, which is what happens
e.g. on arm64 when you ask for an allocation on a noncoherent
device.

It seems that dma_get_sgtable() does have a special case for
this and ends up walking the page table for it, which I
assume is what the driver is relying on, so Takashi's patch
seems fine but could use a few more comments.

It's still unclear to me why the driver has custom iommu
handling rather than just using dma_map_single() on buffers
allocated with dma_alloc_noncoherent or DMA_ATTR_NO_KERNEL_MAPPING
here, since it doesn't even use the virtual address.

      Arnd