mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michael Bommarito <michael.bommarito@gmail.com>
To: Takashi Iwai <tiwai@suse.com>, Jaroslav Kysela <perex@perex.cz>
Cc: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>,
	linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 0/2] ALSA: usb-audio: qcom: fix QMI stream-request handling
Date: Wed, 17 Jun 2026 22:51:24 -0400	[thread overview]
Message-ID: <20260618025126.1862954-1-michael.bommarito@gmail.com> (raw)

Two fixes in handle_uaudio_stream_req(), the QMI handler for the Qualcomm
USB audio offload stream enable/disable requests (reachable from
unprivileged local userspace over AF_QIPCRTR):

Patch 1: the disable path dereferences uadev[card].info[info_idx] without
the info_idx >= 0 guard the enable path and the cleanup label have.
info_idx is -EINVAL on a non-match and .info is allocated only on enable,
so this is not only a NULL deref: when .info is allocated (card enabled
once) and the disable names a non-matching interface, &info[-EINVAL]
points before the allocation and the pipe fields are an out-of-bounds slab
read plus a conditional out-of-bounds 4-byte zero-write. A never-enabled
card instead faults on a wild pointer (oops).

Patch 2: on enable, subs->opened is set before the service_interval is
validated; an invalid interval jumps out without clearing it, wedging the
substream at -EBUSY until disable/disconnect.

Impact: on an affected Qualcomm platform, a local unprivileged process that
can drive the QMI disable path for a card with no active interface would
oops the kernel (patch 1); patch 2 leaves a substream wedged at -EBUSY.
See the
confidence note below: this is a static finding, not yet reproduced.

Confidence and testing: this series is from static analysis of current
mainline; I have NOT reproduced it. CONFIG_SND_USB_AUDIO_QMI builds only on
Qualcomm SoCs with an audio DSP (no x86 build and no Qualcomm hardware
here), so there is no splat to show. What I did verify by reading current
torvalds/master (the offload driver was mainlined in 6.16):

 * Patch 1: in handle_uaudio_stream_req() the enable branch checks
   "info_idx < 0" before use and the response: cleanup label checks
   "info_idx >= 0", but the disable branch between them dereferences
   uadev[pcm_card_num].info[info_idx] with no such check. info_idx is the
   negative return of info_idx_from_ifnum() when no interface matches, and
   .info is a pointer allocated only on enable, so for a
   connected-but-never-enabled card the disable branch forms and then
   dereferences a wild pointer.

 * Patch 2: subs->opened is set in the enable branch before the
   service_interval validation; that validation can "goto response" without
   clearing it, and the response label only clears opened on the disable
   side, so the substream stays wedged.

What I am NOT certain of, and would ask you to confirm on a Qualcomm build:
whether the QMI flow actually lets a disable request reach the disable
branch with info_idx < 0 (a disable for a card with no matching interface).
If the userspace client cannot produce that ordering, patch 1 is hardening
rather than a live oops; patch 2 stands either way. Both patches only add
guards that already exist elsewhere in the same function, so they are low
risk to apply. Please also confirm the Fixes: tag against your tree.

Michael Bommarito (2):
  ALSA: usb-audio: qcom: reject stream disable with no active interface
  ALSA: usb-audio: qcom: clear opened when stream enable fails

 sound/usb/qcom/qc_audio_offload.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

-- 
2.53.0


             reply	other threads:[~2026-06-18  2:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-18  2:51 Michael Bommarito [this message]
2026-06-18  2:51 ` [PATCH 1/2] ALSA: usb-audio: qcom: reject stream disable with no active interface Michael Bommarito
2026-06-18  2:51 ` [PATCH 2/2] ALSA: usb-audio: qcom: clear opened when stream enable fails Michael Bommarito
2026-06-18 10:45 ` [PATCH 0/2] ALSA: usb-audio: qcom: fix QMI stream-request handling Takashi Iwai

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=20260618025126.1862954-1-michael.bommarito@gmail.com \
    --to=michael.bommarito@gmail.com \
    --cc=daniel.lezcano@oss.qualcomm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®