linux-kernel - Re: [PATCH v5 00/17] ASoC: fsl_ssi: Clean up

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]

Date:   Wed, 17 Jan 2018 12:02:11 -0800
From:   Nicolin Chen <nicoleotsuka@...il.com>
To:     "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>
Cc:     timur@...i.org, broonie@...nel.org, linux-kernel@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org, alsa-devel@...a-project.org,
        lgirdwood@...il.com, fabio.estevam@....com, caleb@...me.org,
        arnaud.mouiche@...oxia.com, lukma@...x.de, kernel@...gutronix.de
Subject: Re: [PATCH v5 00/17] ASoC: fsl_ssi: Clean up - program flow level

On Wed, Jan 17, 2018 at 08:38:48PM +0100, Maciej S. Szmigiero wrote:

> However, I have a small nitpick regarding a comment newly added in
> this version of patch 16:
> +		/*
> +		 * Do not set SSI dev as the parent of AC97 CODEC device since
> +		 * it does not have a DT node. Otherwise ASoC core will assume
> +		 * CODEC has the same DT node as the SSI, so it may return a
> +		 * NULL pointer of CODEC when asked for SSI via the DT node
> 
> The second part of the last sentence isn't really true, the ASoC core
> will return a (valid, non-NULL) CODEC object pointer when asked for
> the SSI one if we set the SSI as the parent device of a AC'97 CODEC
> platform device.
> 
> The NULL pointer dereference when starting a playback that I wrote
> about in my previous message happens because in this situation the SSI
> DAI probe callback won't ever get called and so won't setup DMA data
> pointers (they will remain NULL).

Well, somehow the DMA data pointer of CODEC could be described
as "a NULL pointer of CODEC" reluctantly...it confuses people
though.

> And this in turn will cause the ASoC DMA code to dereference these
> NULL pointers when starting a playback (the same will probably happen
> also when starting a capture).
> 
> Sorry if I wasn't 100% clear about these details in my previous
> message describing this issue.

I would prefer to send an incremental patch later to update it,
if there are no new comments against this version; Otherwise, I
will update it in a next version once there is a need to send a
v6 anyway.

Thanks