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: <87ikg03ecf.wl-tiwai@suse.de>
Date: Mon, 27 Oct 2025 10:04:32 +0100
From: Takashi Iwai <tiwai@...e.de>
To: Maciej Strozek <mstrozek@...nsource.cirrus.com>
Cc: Jaroslav Kysela <perex@...ex.cz>,
	Takashi Iwai <tiwai@...e.com>,
	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 Thu, 23 Oct 2025 13:56:26 +0200,
Jaroslav Kysela wrote:
> 
> On 10/23/25 11:27, Maciej Strozek wrote:
> > The components field of snd_card can run out of space in new systems which
> > use many audio devices, hence increase its size to 256 bytes.
> 
> > @@ -1069,7 +1069,7 @@ struct snd_ctl_card_info {
> >   	unsigned char longname[80];	/* name + info text about soundcard */
> >   	unsigned char reserved_[16];	/* reserved for future (was ID of mixer) */
> >   	unsigned char mixername[80];	/* visual mixer identification */
> > -	unsigned char components[128];	/* card components / fine identification, delimited with one space (AC97 etc..) */
> > +	unsigned char components[256];	/* card components / fine identification, delimited with one space (AC97 etc..) */
> Unfortunately, this change will introduce kABI breakage (ioctl number
> change - structure size).
> 
> You can probably define another struct snd_ctl_card_info and
> SNDRV_CTL_IOCTL_CARD_INFO and update alsa-lib to use it depending the
> protocol version.
> 
> 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.


thanks,

Takashi