linux-kernel - Re: [PATCH] ALSA: sound: Increase max size of components field

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: <642d872a-fdb0-45b0-a8a4-84df6422d1d0@opensource.cirrus.com>
Date: Mon, 27 Oct 2025 12:32:04 +0000
From: Richard Fitzgerald <rf@...nsource.cirrus.com>
To: Maciej Strozek <mstrozek@...nsource.cirrus.com>,
        Takashi Iwai <tiwai@...e.de>, Jaroslav Kysela <perex@...ex.cz>
Cc: alsa-devel@...a-project.org, patches@...nsource.cirrus.com,
        linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ALSA: sound: Increase max size of components field

On 27/10/2025 11:50 am, Maciej Strozek wrote:
> W dniu pon, 27.10.2025 o godzinie 10∶04 +0100, użytkownik Takashi Iwai
> napisał:
>> On Thu, 23 Oct 2025 13:56:26 +0200,
>> Jaroslav Kysela wrote:
>>>
>>> Or, we may introduce a separate ioctl for the components string.
>>> The
>>> stripped components string in struct snd_ctl_card_info may have a
>>> special ASCII mark like '>' at the end of string specifying the
>>> availability of the complete string through another ioctl. I would
>>> prefer this solution.
>>>
>>> Also, the components string may be dynamic in the kernel structure
>>> (pointer) to save some space. 256 bytes is not small number.
>>
>> As Jaroslav suggested, we need a different solution to keep the
>> compatibility.
>>
>> My gut feeling is for the option to provide a new ioctl as it can be
>> most straightforward, but we can discuss further which is the good
>> choice.
>>
> 
> Thank you for the advice! Not sure if I understand Jaroslav's new ioctl
> approach properly, can you have a look at the quick draft below and say
> if this is (more or less) what you would expect? If it is OK then I
> will prepare a proper V2 patch here with a corresponding change for
> alsa-lib repo too.
> 
> 
> diff --git a/include/sound/core.h b/include/sound/core.h
> index 0eb2e3ee0dd5..c4e52fb1704b 100644
> --- a/include/sound/core.h
> +++ b/include/sound/core.h
> @@ -88,7 +88,9 @@ struct snd_card {
>          char irq_descr[32];             /* Interrupt description */
>          char mixername[80];             /* mixer name */
>          char components[256];           /* card components delimited
> with
> -                                                               space
> */
> +                                                       space */
> +       char *components_pointer;       /* full components string */
> +       size_t components_pointer_len;  /* length of full components
> string */

You don't need components_pointer_len because you can mandate that
components_pointer must point to a NUL-terminated string.

I expect the new ioctl should require the caller to provide a pointer to
a buffer into which the string will be copied, and the length of that
buffer. It would return an error if the provided buffer is not long
enough to copy the content of components_pointer. Usual protocol is
that it can pass a NULL buffer pointer to retrieve the length of the
string so it knows how big a buffer to allocate.

I assume the ideal API would be that the new ioctl will return the
contents of the old components[] string if there isn't a new
components_pointer string. So if the kernel and user code both support
the new ioctl the user code only needs to call that new ioctl.