All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Sreeraj S Kurup <sreekuttan2156239@gmail.com>
Cc: tiwai@suse.de, linux-kernel@vger.kernel.org,
	linux-sound@vger.kernel.org, perex@perex.cz, tiwai@suse.com
Subject: Re: [PATCH v3] ALSA: control: Validate element info in compat ioctl
Date: Wed, 11 Nov 2026 09:56:53 +0100	[thread overview]
Message-ID: <87ld6zu4oa.wl-tiwai@suse.de> (raw)
In-Reply-To: <20261110160510.2697-1-sreekuttan2156239@gmail.com>

On Tue, 10 Nov 2026 17:05:10 +0100,
Sreeraj S Kurup wrote:
> 
> Hi Takashi,
> 
> The validation in snd_ctl_elem_write() happens too late. Before calling 
> snd_ctl_elem_write(), the compat handler calls copy_ctl_value_from_user(), which 
> uses the type and count returned by get_ctl_type() to determine how many values to copy.
> 
> If the control's info callback returns an invalid count, the integer and boolean paths 
> can access beyond the fixed-size integer value array. Other paths can also calculate a 
> copy size larger than the available kernel buffer.
> 
> The read path has a similar issue. It uses the same type and count when copying the values 
> back to userspace, which can result in an out-of-bounds read from the kernel buffer.
> 
> So, validation in snd_ctl_elem_write() cannot prevent these problems because the unsafe 
> accesses can happen before it is called.
> 
> Using __snd_ctl_elem_info() in get_ctl_type() ensures that the type and count are validated 
> before they are used by the compat handlers. It also reuses the existing element ID handling 
> and access checks.
> 
> Therefore, I think this validation is necessary.

OK, it makes sense.  Now applied to for-next branch.


thanks,

Takashi

  reply	other threads:[~2026-11-11  8:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-08 14:12 [PATCH] ALSA: control: Validate element info in compat ioctl Sreeraj S Kurup
2026-11-08 14:32 ` sashiko-bot
2026-11-08 16:09 ` [PATCH v2] " Sreeraj S Kurup
2026-11-08 16:25   ` sashiko-bot
2026-11-08 17:25 ` [PATCH v3] " Sreeraj S Kurup
2026-11-10 10:38   ` Takashi Iwai
2026-11-10 16:05     ` Sreeraj S Kurup
2026-11-11  8:56       ` Takashi Iwai [this message]
2026-11-11 10:58         ` Sreeraj S Kurup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ld6zu4oa.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=sreekuttan2156239@gmail.com \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.