All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Ammar Faizi <ammarfaizi2@gnuweeb.org>
Cc: Daniel Baluta <daniel.baluta@nxp.com>,
	Jaroslav Kysela <perex@perex.cz>,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	Keyon Jie <yang.jie@linux.intel.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Peter Ujfalusi <peter.ujfalusi@linux.intel.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Rander Wang <rander.wang@intel.com>,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Takashi Iwai <tiwai@suse.com>,
	stable@vger.kernel.org, sound-open-firmware@alsa-project.org,
	alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ASoC: SOF: Intel: Fix NULL ptr dereference when ENOMEM
Date: Thu, 24 Feb 2022 17:26:54 +0000	[thread overview]
Message-ID: <Yhe/3rELNfFOdU4L@sirena.org.uk> (raw)
In-Reply-To: <20220224145124.15985-1-ammarfaizi2@gnuweeb.org>

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

On Thu, Feb 24, 2022 at 09:51:24PM +0700, Ammar Faizi wrote:
> From: Ammar Faizi <ammarfaizi2@gnuweeb.org>
> 
> Do not call snd_dma_free_pages() when snd_dma_alloc_pages() returns
> -ENOMEM because it leads to a NULL pointer dereference bug.
> 
> The dmesg says:
> 
>   <6>[109482.497835][T138537] usb 1-2: Manufacturer: SIGMACHIP
>   <6>[109482.502506][T138537] input: SIGMACHIP USB Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:1C4F:0002.000D/input/input34
>   <6>[109482.558976][T138537] hid-generic 0003:1C4F:0002.000D: input,hidraw1: USB HID v1.10 Keyboard [SIGMACHIP USB Keyboard] on usb-0000:00:14.0-2/input0
>   <6>[109482.561653][T138537] input: SIGMACHIP USB Keyboard Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.1/0003:1C4F:0002.000E/input/input35

Please think hard before including complete backtraces in upstream
reports, they are very large and contain almost no useful information
relative to their size so often obscure the relevant content in your
message. If part of the backtrace is usefully illustrative (it often is
for search engines if nothing else) then it's usually better to pull out
the relevant sections.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Mark Brown <broonie@kernel.org>
To: Ammar Faizi <ammarfaizi2@gnuweeb.org>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	alsa-devel@alsa-project.org,
	Kai Vehmanen <kai.vehmanen@linux.intel.com>,
	Daniel Baluta <daniel.baluta@nxp.com>,
	Takashi Iwai <tiwai@suse.com>,
	Keyon Jie <yang.jie@linux.intel.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	stable@vger.kernel.org,
	Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
	Rander Wang <rander.wang@intel.com>,
	Peter Ujfalusi <peter.ujfalusi@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	sound-open-firmware@alsa-project.org
Subject: Re: [PATCH] ASoC: SOF: Intel: Fix NULL ptr dereference when ENOMEM
Date: Thu, 24 Feb 2022 17:26:54 +0000	[thread overview]
Message-ID: <Yhe/3rELNfFOdU4L@sirena.org.uk> (raw)
In-Reply-To: <20220224145124.15985-1-ammarfaizi2@gnuweeb.org>

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

On Thu, Feb 24, 2022 at 09:51:24PM +0700, Ammar Faizi wrote:
> From: Ammar Faizi <ammarfaizi2@gnuweeb.org>
> 
> Do not call snd_dma_free_pages() when snd_dma_alloc_pages() returns
> -ENOMEM because it leads to a NULL pointer dereference bug.
> 
> The dmesg says:
> 
>   <6>[109482.497835][T138537] usb 1-2: Manufacturer: SIGMACHIP
>   <6>[109482.502506][T138537] input: SIGMACHIP USB Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:1C4F:0002.000D/input/input34
>   <6>[109482.558976][T138537] hid-generic 0003:1C4F:0002.000D: input,hidraw1: USB HID v1.10 Keyboard [SIGMACHIP USB Keyboard] on usb-0000:00:14.0-2/input0
>   <6>[109482.561653][T138537] input: SIGMACHIP USB Keyboard Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.1/0003:1C4F:0002.000E/input/input35

Please think hard before including complete backtraces in upstream
reports, they are very large and contain almost no useful information
relative to their size so often obscure the relevant content in your
message. If part of the backtrace is usefully illustrative (it often is
for search engines if nothing else) then it's usually better to pull out
the relevant sections.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2022-02-24 17:27 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-24 14:51 [PATCH] ASoC: SOF: Intel: Fix NULL ptr dereference when ENOMEM Ammar Faizi
2022-02-24 14:51 ` Ammar Faizi
2022-02-24 16:53 ` Péter Ujfalusi
2022-02-24 16:53   ` Péter Ujfalusi
2022-02-24 17:55   ` Ammar Faizi
2022-02-24 17:55     ` Ammar Faizi
2022-02-24 18:05   ` Pierre-Louis Bossart
2022-02-24 18:05     ` Pierre-Louis Bossart
2022-02-24 18:08     ` [PATCH v2] " Ammar Faizi
2022-02-24 18:08       ` Ammar Faizi
2022-02-24 18:14       ` Mark Brown
2022-02-24 18:14         ` Mark Brown
2022-02-24 18:28         ` [PATCH v3] " Ammar Faizi
2022-02-24 18:28           ` Ammar Faizi
2022-02-24 18:58           ` [PATCH v4] " Ammar Faizi
2022-02-24 18:58             ` Ammar Faizi
2022-02-24 22:58             ` Mark Brown
2022-02-24 22:58               ` Mark Brown
2022-02-24 22:58           ` [PATCH v3] " Mark Brown
2022-02-24 22:58             ` Mark Brown
2022-02-24 22:58       ` [PATCH v2] " Mark Brown
2022-02-24 22:58         ` Mark Brown
2022-02-24 17:26 ` Mark Brown [this message]
2022-02-24 17:26   ` [PATCH] " Mark Brown
2022-02-24 17:56   ` Ammar Faizi
2022-02-24 17:56     ` Ammar Faizi

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=Yhe/3rELNfFOdU4L@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=ammarfaizi2@gnuweeb.org \
    --cc=daniel.baluta@nxp.com \
    --cc=kai.vehmanen@linux.intel.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=peter.ujfalusi@linux.intel.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=rander.wang@intel.com \
    --cc=ranjani.sridharan@linux.intel.com \
    --cc=sound-open-firmware@alsa-project.org \
    --cc=stable@vger.kernel.org \
    --cc=tiwai@suse.com \
    --cc=yang.jie@linux.intel.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.