30 Dec, 2020
1 commit
-
commit 11cb881bf075cea41092a20236ba708b18e1dbb2 upstream.
There are a few places that call round{up|down}_pow_of_two() with the
value zero, and this causes undefined behavior warnings. Avoid
calling those macros if such a nonsense value is passed; it's a minor
optimization as well, as we handle it as either an error or a value to
be skipped, instead.Reported-by: syzbot+33ef0b6639a8d2d42b4c@syzkaller.appspotmail.com
Cc:
Link: https://lore.kernel.org/r/20201218161730.26596-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
21 Dec, 2020
1 commit
-
commit 175b8d89fe292796811fdee87fa39799a5b6b87a upstream.
syzbot spotted a potential out-of-bounds shift in the PCM OSS layer
where it calculates the buffer size with the arbitrary shift value
given via an ioctl.Add a range check for avoiding the undefined behavior.
As the value can be treated by a signed integer, the max shift should
be 30.Reported-by: syzbot+df7dc146ebdd6435eea3@syzkaller.appspotmail.com
Cc:
Link: https://lore.kernel.org/r/20201209084552.17109-2-tiwai@suse.de
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
01 Sep, 2020
1 commit
-
The PCM OSS mulaw plugin has a check of the format of the counter part
whether it's a linear format. The check is with snd_BUG_ON() that
emits WARN_ON() when the debug config is set, and it confuses
syzkaller as if it were a serious issue. Let's drop snd_BUG_ON() for
avoiding that.While we're at it, correct the error code to a more suitable, EINVAL.
Reported-by: syzbot+23b22dc2e0b81cbfcc95@syzkaller.appspotmail.com
Cc:
Link: https://lore.kernel.org/r/20200901131802.18157-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
09 Jul, 2020
1 commit
-
Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.[1] https://www.kernel.org/doc/html/latest/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through
Signed-off-by: Gustavo A. R. Silva
Link: https://lore.kernel.org/r/20200708203236.GA5112@embeddedor
Signed-off-by: Takashi Iwai
10 Jun, 2020
1 commit
-
Convert comments that reference mmap_sem to reference mmap_lock instead.
[akpm@linux-foundation.org: fix up linux-next leftovers]
[akpm@linux-foundation.org: s/lockaphore/lock/, per Vlastimil]
[akpm@linux-foundation.org: more linux-next fixups, per Michel]Signed-off-by: Michel Lespinasse
Signed-off-by: Andrew Morton
Reviewed-by: Vlastimil Babka
Reviewed-by: Daniel Jordan
Cc: Davidlohr Bueso
Cc: David Rientjes
Cc: Hugh Dickins
Cc: Jason Gunthorpe
Cc: Jerome Glisse
Cc: John Hubbard
Cc: Laurent Dufour
Cc: Liam Howlett
Cc: Matthew Wilcox
Cc: Peter Zijlstra
Cc: Ying Han
Link: http://lkml.kernel.org/r/20200520052908.204642-13-walken@google.com
Signed-off-by: Linus Torvalds
28 May, 2020
1 commit
-
Back-merge 5.7-devel branch for further development.
Signed-off-by: Takashi Iwai
08 May, 2020
1 commit
-
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:struct foo {
int stuff;
struct boo array[];
};By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.Also, notice that, dynamic memory allocations won't be affected by
this change:"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")Signed-off-by: Gustavo A. R. Silva
Link: https://lore.kernel.org/r/20200507192223.GA16335@embeddedor
Signed-off-by: Takashi Iwai
25 Apr, 2020
1 commit
-
[ This is again a forward-port of the fix applied for 5.6-base code
(commit 4285de0725b1) to 5.7-base, hence neither Fixes nor
Cc-to-stable tags are included here -- tiwai ]The checks of the plugin buffer overflow in the previous fix by commit
f2ecf903ef06 ("ALSA: pcm: oss: Avoid plugin buffer overflow")
are put in the wrong places mistakenly, which leads to the expected
(repeated) sound when the rate plugin is involved. Fix in the right
places.Also, at those right places, the zero check is needed for the
termination node, so added there as well, and let's get it done,
finally.Link: https://lore.kernel.org/r/20200424193843.20397-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
03 Apr, 2020
1 commit
-
[ This is essentially the same fix as commit ae769d355664, but it's
adapted to the latest code for 5.7; hence it contains no Fixes or
other tags for avoid backport confusion -- tiwai ]The recent fix for the OOB access in PCM OSS plugins (commit
f2ecf903ef06: "ALSA: pcm: oss: Avoid plugin buffer overflow") caused a
regression on OSS applications. The patch introduced the size check
in client and slave size calculations to limit to each plugin's buffer
size, but I overlooked that some code paths call those without
allocating the buffer but just for estimation.This patch fixes the bug by skipping the size check for those code
paths while keeping checking in the actual transfer calls.Link: https://lore.kernel.org/r/20200403073818.27943-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
30 Mar, 2020
1 commit
12 Mar, 2020
1 commit
-
The return value checks in snd_pcm_plug_alloc() are covered with
snd_BUG_ON() macro that may trigger a kernel WARNING depending on the
kconfig. But since the error condition can be triggered by a weird
user space parameter passed to OSS layer, we shouldn't give the kernel
stack trace just for that. As it's a normal error condition, let's
remove snd_BUG_ON() macro usage there.Reported-by: syzbot+2a59ee7a9831b264f45e@syzkaller.appspotmail.com
Cc:
Link: https://lore.kernel.org/r/20200312155730.7520-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
10 Mar, 2020
2 commits
-
Both snd_pcm_plug_client_size() and snd_pcm_plug_slave_size() do the
almost same calculations of calling src_frames() and dst_frames() in
the chain, but just to the different directions with each other.This patch simplifies those functions. Now they return -EINVAL for
the invalid direction, but practically seen, there is no functional
changes at all.Link: https://lore.kernel.org/r/20200309185855.15693-1-tiwai@suse.de
Signed-off-by: Takashi Iwai -
Back-merge of 5.6 devel branch for further changes in 5.7 cycle
Signed-off-by: Takashi Iwai
09 Mar, 2020
1 commit
-
Each OSS PCM plugins allocate its internal buffer per pre-calculation
of the max buffer size through the chain of plugins (calling
src_frames and dst_frames callbacks). This works for most plugins,
but the rate plugin might behave incorrectly. The calculation in the
rate plugin involves with the fractional position, i.e. it may vary
depending on the input position. Since the buffer size
pre-calculation is always done with the offset zero, it may return a
shorter size than it might be; this may result in the out-of-bound
access as spotted by fuzzer.This patch addresses those possible buffer overflow accesses by simply
setting the upper limit per the given buffer size for each plugin
before src_frames() and after dst_frames() calls.Reported-by: syzbot+e1fe9f44fb8ecf4fb5dd@syzkaller.appspotmail.com
Cc:
Link: https://lore.kernel.org/r/000000000000b25ea005a02bcf21@google.com
Link: https://lore.kernel.org/r/20200309082148.19855-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
15 Feb, 2020
1 commit
-
ALSA PCM OSS layer calls the generic __snd_pcm_lib_xfer() helper for
the actual transfer of the audio data. The xfer helper may sleep long
for waiting for the enough space becoming empty for read/write, and
it does unlock/relock for the substream lock. This works fine, so
far, but a slight problem specific to OSS layer is that OSS layer
wraps yet more mutex (runtime->oss.params_lock) over
__snd_pcm_lib_xfer() call; so this mutex is still locked during a
possible long sleep, and it prevents the whole ioctl and other actions
applied to the given stream.This patch adds the temporarily unlock and relock of the mutex around
__snd_pcm_lib_xfer() call in the OSS layer to be more friendly to the
concurrent accesses. The long mutex protection itself shouldn't be a
real issue for the normal systems, and its influence appears only on
strange things like fuzzers.Link: https://lore.kernel.org/r/20200214171643.26212-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
12 Feb, 2020
1 commit
-
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:struct foo {
int stuff;
struct boo array[];
};By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertenly introduced[3] to the codebase from now on.This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")Signed-off-by: Gustavo A. R. Silva
Link: https://lore.kernel.org/r/20200211193910.GA4596@embeddedor
Signed-off-by: Takashi Iwai
10 Feb, 2020
1 commit
-
Simplify the code with the new macros for PCM format type iterations.
This fixes the sparse warnings nicely:
sound/core/pcm_native.c:2302:26: warning: restricted snd_pcm_format_t degrades to integer
sound/core/pcm_native.c:2306:54: warning: incorrect type in argument 1 (different base types)
sound/core/pcm_native.c:2306:54: expected restricted snd_pcm_format_t [usertype] format
sound/core/pcm_native.c:2306:54: got unsigned int [assigned] k
....No functional changes, just sparse warning fixes.
Link: https://lore.kernel.org/r/20200206163945.6797-6-tiwai@suse.de
Signed-off-by: Takashi Iwai
05 Jan, 2020
1 commit
-
Apply const prefix to the static tables for strings and formats.
Just for minor optimization and no functional changes.
Link: https://lore.kernel.org/r/20200105144823.29547-41-tiwai@suse.de
Signed-off-by: Takashi Iwai
03 Jan, 2020
1 commit
-
The snd_mixer_oss_assign_table is read-only, and can it be declared as
const.There should be no functional changes by this patch.
Link: https://lore.kernel.org/r/20200103081714.9560-32-tiwai@suse.de
Signed-off-by: Takashi Iwai
07 Dec, 2019
1 commit
-
Pull more sound updates from Takashi Iwai:
"A few last-minute updates, most of them are the regression fixes:- AMD HD-audio HDMI runtime PM improvements
- Fixes for HD-audio HDMI regressions wrt DP-MST
- A regression fix for the previous aloop enhancement
- A fix for a long-time problem in PCM OSS layer that was spotted by
fuzzer now- A few HD-audio quirks"
* tag 'sound-fix-5.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: pcm: oss: Avoid potential buffer overflows
ALSA: hda: hdmi - Keep old slot assignment behavior for Intel platforms
ALSA: hda: Modify stream stripe mask only when needed
ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th gen
ALSA: hda: hdmi - preserve non-MST PCM routing for Intel platforms
ALSA: hda: hdmi - fix kernel oops caused by invalid PCM idx
ALSA: hda/realtek - Fix inverted bass GPIO pin on Acer 8951G
ALSA: hda/realtek - Dell headphone has noise on unmute for ALC236
ALSA: hda: hdmi - fix regression in connect list handling
ALSA: aloop: Avoid pointer dereference before null-check
ALSA: hda/hdmi - enable automatic runtime pm for AMD HDMI codecs by default
ALSA: hda/hdmi - enable runtime pm for newer AMD display audio
ALSA: hda/hdmi - Add new pci ids for AMD GPU display audio
ALSA: hda/hdmi - fix vgaswitcheroo detection for AMD
04 Dec, 2019
1 commit
-
syzkaller reported an invalid access in PCM OSS read, and this seems
to be an overflow of the internal buffer allocated for a plugin.
Since the rate plugin adjusts its transfer size dynamically, the
calculation for the chained plugin might be bigger than the given
buffer size in some extreme cases, which lead to such an buffer
overflow as caught by KASAN.Fix it by limiting the max transfer size properly by checking against
the destination size in each plugin transfer callback.Reported-by: syzbot+f153bde47a62e0b05f83@syzkaller.appspotmail.com
Cc:
Link: https://lore.kernel.org/r/20191204144824.17801-1-tiwai@suse.de
Signed-off-by: Takashi Iwai
23 Oct, 2019
1 commit
-
The SNDCTL_* and SOUND_* commands are the old OSS user interface.
I checked all the sound ioctl commands listed in fs/compat_ioctl.c
to see if we still need the translation handlers. Here is what I
found:- sound/oss/ is (almost) gone from the kernel, this is what actually
needed all the translations
- The ALSA emulation for OSS correctly handles all compat_ioctl
commands already.
- sound/oss/dmasound/ is the last holdout of the original OSS code,
this is only used on arch/m68k, which has no 64-bit mode and
hence needs no compat handlers
- arch/um/drivers/hostaudio_kern.c may run in 64-bit mode with
32-bit x86 user space underneath it. This rare corner case is
the only one that still needs the compat handlers.By adding a simple redirect of .compat_ioctl to .unlocked_ioctl in the
UML driver, we can remove all the COMPATIBLE_IOCTL() annotations without
a change in functionality. For completeness, I'm adding the same thing
to the dmasound file, knowing that it makes no difference.The compat_ioctl list contains one comment about SNDCTL_DSP_MAPINBUF and
SNDCTL_DSP_MAPOUTBUF, which actually would need a translation handler
if implemented. However, the native implementation just returns -EINVAL,
so we don't care.Reviewed-by: Takashi Iwai
Signed-off-by: Arnd Bergmann
08 Jul, 2019
1 commit
-
…/sound into for-linus
ASoC: Updates for v5.3
This is a very big update, mainly thanks to Morimoto-san's refactoring
work and some fairly large new drivers.- Lots more work on moving towards a component based framework from
Morimoto-san.
- Support for force disconnecting muxes from Jerome Brunet.
- New drivers for Cirrus Logic CS47L35, CS47L85 and CS47L90, Conexant
CX2072X, Realtek RT1011 and RT1308.Signed-off-by: Takashi Iwai <tiwai@suse.de>
31 May, 2019
1 commit
-
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version this program is distributed in the
hope that it will be useful but without any warranty without even
the implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details you
should have received a copy of the gnu general public license along
with this program if not write to the free software foundation inc
59 temple place suite 330 boston ma 02111 1307 usaextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 1334 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Allison Randal
Reviewed-by: Richard Fontana
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de
Signed-off-by: Greg Kroah-Hartman
24 May, 2019
1 commit
-
Make use of the struct_size() helper instead of an open-coded version
in order to avoid any potential type mistakes, in particular in the
context in which this code is being used.So, replace the following form:
sizeof(struct rate_priv) + src_format->channels * sizeof(struct rate_channel)
with:
struct_size(data, channels, src_format->channels)
This code was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
Signed-off-by: Takashi Iwai
17 Apr, 2019
1 commit
-
The snd_cards[] array holds the card pointers that have been currently
registered, and it's exported for the external modules that may need
to refer a card object. But accessing to this array can be racy
against the driver probe or removal, as the card registration or free
may happen concurrently.This patch gets rid of the direct access to snd_cards[] array and
provides a helper function to give the card object from the index
number with a refcount management. Then the caller can access to the
given card object safely, and releases it via snd_card_unref().While we're at it, add a proper comment to snd_card_unref() and make
it an inlined function for type-safety, too.Signed-off-by: Takashi Iwai
22 Mar, 2019
1 commit
-
The PCM OSS emulation converts and transfers the data on the fly via
"plugins". The data is converted over the dynamically allocated
buffer for each plugin, and recently syzkaller caught OOB in this
flow.Although the bisection by syzbot pointed out to the commit
65766ee0bf7f ("ALSA: oss: Use kvzalloc() for local buffer
allocations"), this is merely a commit to replace vmalloc() with
kvmalloc(), hence it can't be the cause. The further debug action
revealed that this happens in the case where a slave PCM doesn't
support only the stereo channels while the OSS stream is set up for a
mono channel. Below is a brief explanation:At each OSS parameter change, the driver sets up the PCM hw_params
again in snd_pcm_oss_change_params_lock(). This is also the place
where plugins are created and local buffers are allocated. The
problem is that the plugins are created before the final hw_params is
determined. Namely, two snd_pcm_hw_param_near() calls for setting the
period size and periods may influence on the final result of channels,
rates, etc, too, while the current code has already created plugins
beforehand with the premature values. So, the plugin believes that
channels=1, while the actual I/O is with channels=2, which makes the
driver reading/writing over the allocated buffer size.The fix is simply to move the plugin allocation code after the final
hw_params call.Reported-by: syzbot+d4503ae45b65c5bc1194@syzkaller.appspotmail.com
Cc:
Signed-off-by: Takashi Iwai
24 Jan, 2019
1 commit
-
It's assigned but nowhere used. Let's remove it.
Signed-off-by: Takashi Iwai
09 Nov, 2018
1 commit
-
PCM OSS layer may allocate a few temporary buffers, one for the core
read/write and another for the conversions via plugins. Currently
both are allocated via vmalloc(). But as the allocation size is
equivalent with the PCM period size, the required size might be quite
small, depending on the application.This patch replaces these vmalloc() calls with kvzalloc() for covering
small period sizes better. Also, we use "z"-alloc variant here for
addressing the possible uninitialized access reported by syzkaller.Reported-by: syzbot+1cb36954e127c98dd037@syzkaller.appspotmail.com
Cc:
Signed-off-by: Takashi Iwai
27 Aug, 2018
1 commit
-
The "frames" variable is unsigned so the error handling doesn't work
properly.Signed-off-by: Dan Carpenter
Signed-off-by: Takashi Iwai
02 Aug, 2018
1 commit
-
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.Addresses-Coverity-ID: 1357375 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva
Signed-off-by: Takashi Iwai
27 Jul, 2018
1 commit
-
The PCM format type is with __bitwise, hence it needs the explicit
cast with __force. It's ugly, but there is a reason for that cost...This fixes the sparse warning:
sound/core/oss/pcm_oss.c:1854:55: warning: incorrect type in argument 1 (different base types)Signed-off-by: Takashi Iwai
26 Jul, 2018
1 commit
-
Instead of open codes, use the standard macros for obtaining the lower
and upper 32bit values.Signed-off-by: Takashi Iwai
28 May, 2018
1 commit
-
Convert the S_ symbolic permissions to their octal equivalents as
using octal and not symbolic permissions is preferred by many as more
readable.see: https://lkml.org/lkml/2016/8/2/1945
Done with automated conversion via:
$ ./scripts/checkpatch.pl -f --types=SYMBOLIC_PERMS --fix-inplaceMiscellanea:
o Wrapped one multi-line call to a single line
Signed-off-by: Joe Perches
Acked-by: Vinod Koul
Signed-off-by: Takashi Iwai
07 Apr, 2018
1 commit
-
The commit 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS
ioctls and read/write") split the PCM preparation code to a locked
version, and it added a sanity check of runtime->oss.prepare flag
along with the change. This leaded to an endless loop when the stream
gets XRUN: namely, snd_pcm_oss_write3() and co call
snd_pcm_oss_prepare() without setting runtime->oss.prepare flag and
the loop continues until the PCM state reaches to another one.As the function is supposed to execute the preparation
unconditionally, drop the invalid state check there.The bug was triggered by syzkaller.
Fixes: 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write")
Reported-by: syzbot+150189c103427d31a053@syzkaller.appspotmail.com
Reported-by: syzbot+7e3f31a52646f939c052@syzkaller.appspotmail.com
Reported-by: syzbot+4f2016cf5185da7759dc@syzkaller.appspotmail.com
Cc:
Signed-off-by: Takashi Iwai
03 Apr, 2018
1 commit
-
Preparation for 4.17 merge.
Signed-off-by: Takashi Iwai
27 Mar, 2018
2 commits
-
The previous fix 40cab6e88cb0 ("ALSA: pcm: Return -EBUSY for OSS
ioctls changing busy streams") introduced some mutex unbalance; the
check of runtime->oss.rw_ref was inserted in a wrong place after the
mutex lock.This patch fixes the inconsistency by rewriting with the helper
functions to lock/unlock parameters with the stream check.Fixes: 40cab6e88cb0 ("ALSA: pcm: Return -EBUSY for OSS ioctls changing busy streams")
Reported-by: Dan Carpenter
Cc:
Signed-off-by: Takashi Iwai -
Smatch complains that "tmp" can be uninitialized if we do a zero size
write.Fixes: 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write")
Signed-off-by: Dan Carpenter
Cc:
Signed-off-by: Takashi Iwai
24 Mar, 2018
2 commits
-
OSS PCM stream management isn't modal but it allows ioctls issued at
any time for changing the parameters. In the previous hardening
patch ("ALSA: pcm: Avoid potential races between OSS ioctls and
read/write"), we covered these races and prevent the corruption by
protecting the concurrent accesses via params_lock mutex. However,
this means that some ioctls that try to change the stream parameter
(e.g. channels or format) would be blocked until the read/write
finishes, and it may take really long.Basically changing the parameter while reading/writing is an invalid
operation, hence it's even more user-friendly from the API POV if it
returns -EBUSY in such a situation.This patch adds such checks in the relevant ioctls with the addition
of read/write access refcount.Cc:
Signed-off-by: Takashi Iwai -
Although we apply the params_lock mutex to the whole read and write
operations as well as snd_pcm_oss_change_params(), we may still face
some races.First off, the params_lock is taken inside the read and write loop.
This is intentional for avoiding the too long locking, but it allows
the in-between parameter change, which might lead to invalid
pointers. We check the readiness of the stream and set up via
snd_pcm_oss_make_ready() at the beginning of read and write, but it's
called only once, by assuming that it remains ready in the rest.Second, many ioctls that may change the actual parameters
(i.e. setting runtime->oss.params=1) aren't protected, hence they can
be processed in a half-baked state.This patch is an attempt to plug these holes. The stream readiness
check is moved inside the read/write inner loop, so that the stream is
always set up in a proper state before further processing. Also, each
ioctl that may change the parameter is wrapped with the params_lock
for avoiding the races.The issues were triggered by syzkaller in a few different scenarios,
particularly the one below appearing as GPF in loopback_pos_update.Reported-by: syzbot+c4227aec125487ec3efa@syzkaller.appspotmail.com
Cc:
Signed-off-by: Takashi Iwai