commit 4071bf121d upstream.
There are sleep in atomic bug that could cause kernel panic during
firmware download process. The root cause is that nlmsg_new with
GFP_KERNEL parameter is called in fw_dnld_timeout which is a timer
handler. The call trace is shown below:
BUG: sleeping function called from invalid context at include/linux/sched/mm.h:265
Call Trace:
kmem_cache_alloc_node
__alloc_skb
nfc_genl_fw_download_done
call_timer_fn
__run_timers.part.0
run_timer_softirq
__do_softirq
...
The nlmsg_new with GFP_KERNEL parameter may sleep during memory
allocation process, and the timer handler is run as the result of
a "software interrupt" that should not call any other function
that could sleep.
This patch changes allocation mode of netlink message from GFP_KERNEL
to GFP_ATOMIC in order to prevent sleep in atomic bug. The GFP_ATOMIC
flag makes memory allocation operation could be used in atomic context.
Bug: 245675148
Fixes: 9674da8759 ("NFC: Add firmware upload netlink command")
Fixes: 9ea7187c53 ("NFC: netlink: Rename CMD_FW_UPLOAD to CMD_FW_DOWNLOAD")
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220504055847.38026-1-duoming@zju.edu.cn
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I510b617174c0575cc6f438b2edf44f0262f9c09c
Ensure that pointer authentication is initialized when the vcpu
is initialized as well, and not only when the vcpu is reset.
Bug: 249192647
Signed-off-by: Fuad Tabba <tabba@google.com>
Change-Id: Ida39a3ee5e6b4b0d3255bfef95601890afd80709
Vendor could decide to bypass this function.
Bug: 238390134
Change-Id: Ia6bc71c7569d21da9ae226e5d8739f97b9ca1a4f
Signed-off-by: Rick Yiu <rickyiu@google.com>
Ignore kvm-arm.mode if !is_hyp_mode_available(). Specifically, we want
to avoid switching kvm_mode to KVM_MODE_PROTECTED if hypervisor mode is
not available. This prevents "Protected KVM" cpu capability being
reported when Linux is booting in EL1 and would not have KVM enabled.
Reasonably though, we should warn if the command line is requesting a
KVM mode at all if KVM isn't actually available. Allow
"kvm-arm.mode=none" to skip the warning since this would disable KVM
anyway.
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220920190658.2880184-1-quic_eberman@quicinc.com
Bug: 249052880
(cherry picked from commit b2a4d007c3https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git next)
Change-Id: I196649fc00537e563a1fab0a22bf23c5b7abe00d
Signed-off-by: Elliot Berman <quic_eberman@quicinc.com>
commit cc5250cdb4 upstream.
We won't really have enough skbs to need a 64-bit cookie,
and on 32-bit platforms storing the 64-bit cookie into the
void *rate_driver_data doesn't work anyway. Switch back to
using just a 32-bit cookie and uintptr_t for the type to
avoid compiler warnings about all this.
Fixes: 4ee186fa7e ("wifi: mac80211_hwsim: fix race condition in pending packet")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Cc: Jeongik Cha <jeongik@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6dece5ad6e)
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Bug: 236994625
Change-Id: I81b075297ec2248f706aebc914cd5e2783665bbc
commit 58b6259d82 upstream.
The robots report that we're now casting to a differently
sized integer, which is correct, and the previous patch
had erroneously removed it.
Reported-by: kernel test robot <lkp@intel.com>
Fixes: 4ee186fa7e ("wifi: mac80211_hwsim: fix race condition in pending packet")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Cc: Jeongik Cha <jeongik@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit d400222f49)
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Bug: 236994625
Change-Id: I4b5cfa77c47d4d03b46600f0b543e27340c228c0
commit 4ee186fa7e upstream.
A pending packet uses a cookie as an unique key, but it can be duplicated
because it didn't use atomic operators.
And also, a pending packet can be null in hwsim_tx_info_frame_received_nl
due to race condition with mac80211_hwsim_stop.
For this,
* Use an atomic type and operator for a cookie
* Add a lock around the loop for pending packets
Signed-off-by: Jeongik Cha <jeongik@google.com>
Link: https://lore.kernel.org/r/20220704084354.3556326-1-jeongik@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit eb8fc4277b)
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Bug: 236994625
Change-Id: Ic6613c8869a51b5de303e40406f023af689b9d64
This patch addresses an issue seen where SCHED_FIFO prio 99
tasks were being woken up on a cpu where a long-running softirq
was executing, and the RT task was not being migrated, causing
long (10+ms wakeup latencies).
Prior to upstream commit 934fc3314b ("sched/cpupri: Remap
CPUPRI_NORMAL to MAX_RT_PRIO-1") the task->prio -> cpupri
mapping is a little ackward.
For RT tasks, its calculated as:
cpupri = MAX_RT_PRIO - prio + 1;
See:
https://android.googlesource.com/kernel/common/+/refs/heads/android13-5.10/kernel/sched/cpupri.c#39
This is added ontop of the also ackward detail that the
task->prio is inverted (RT prio99 -> 0), means the cpupri
mapping for RT tasks goes from 2->101. This makes it easy to
evaluate the cpupri incorrectly.
Which it turns out happened In commit 3adfd8e344 ("ANDROID:
sched: avoid placing RT threads on cores handling softirqs"):
3adfd8e344%5E%21/
With the lines:
int task_pri = convert_prio(p->prio);
bool drop_nopreempts = task_pri <= MAX_RT_PRIO;
Where the added logic to decide to migrate a rt task off of a
cpu depended on this drop_nopreempts being true.
This works properly for rt tasks from prio 99 to 1, but for the
case of task->prio == 0 (userland rt prio 99 tasks) it breaks,
as the cpupri will be MAX_RT_PRIO - 0 + 1, which then gets
checked as <= MAX_RT_PRIO.
This prevents the cpu from being dropped from the scheduling
set and prevents the rt user prio 99 task from migrating, which
results in high priority rt tasks being left on cpus where long
running softirqs are executing, causing long latencies.
This patch fixes the off by one by changing the evaulation
to MAX_RT_PRIO + 1, so that user-prio 99 tasks will also be
migrated if appropriate.
Luckilly this odd cpupri mapping has been fixed upstream, making
this patch no longer necessary in 5.15 and newer kernels.
Fixes: 3adfd8e344 ("ANDROID: sched: avoid placing RT threads on cores handling softirqs")
Signed-off-by: John Stultz <jstultz@google.com>
Change-Id: Ia2db7cd461eb4c90f5850b791de1ae95582f7530
This reverts commit 34f087452f.
The hook android_vh_wq_lockup_pool is not used by any vendor, so remove
it to help with merge issues with future LTS releases.
If this is needed by any real user, it can easily be reverted to add it
back and then the symbol should be added to the abi list at the same
time to prevent it from being removed again later.
Bug: 203756332
Bug: 169374262
Cc: Sangmoon Kim <sangmoon.kim@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I84eb7e1abc535a4efecd2b6071ef6d25fa2c1e2e
Test: fuse_test passes, with appropriate user code directories can be
hidden
Bug: 219958836
Signed-off-by: Paul Lawrence <paullawrence@google.com>
Change-Id: Ia77d4bf9e63d0dd4535e53e9e07c3216fd4b8430
struct cgroup_taskset is defined in kernel/cgroup/cgroup-internal.h,
however libabigail is not finding its definition based on the
instantiation of the hooks, so force it to be defined by defining a
dummy exported symbol. Since cgroup_taskset is defined in a
subsystem-private header, create a new vendor_hooks.c file in
kernel/cgroup to define the dummy symbol.
Update the XML with the new type definitions
Bug: 233047575
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I7a2bf2a722bf5aec0c702f215d572cc8e5336f9a
There were 3 remaining types directly referenced by vendor
hooks that were not fully-defined in the KMI:
struct blk_mq_alloc_data is defined in block/blk-mq.h, however
libabigail is not finding its definition based on the instantiation
of the hooks, so force it to be defined by defining a dummy exported
symbol. Since blk_mq_alloc_data is defined in a subsystem-private
header, create a new vendor_hooks.c file in block/ to define
the dummy symbol.
Bug: 233047575
Bug: 248263460
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I6419caba1c6a159b7a64b9d28e983d753393af86
android13-5.10 is broken on Dragonboard 845c because of
recently added snd_pcm_* symbols.
So updated the symbols list by running:
"BUILD_CONFIG=common/build.config.db845c \
KMI_SYMBOL_LIST_ADD_ONLY=1 build/build_abi.sh -s"
And the abi_gki_aarch64 ABI by running:
"BUILD_CONFIG=common/build.config.gki.aarch64 \
ABI_DEFINITION=abi_gki_aarch64.xml KMI_SYMBOL_LIST_ADD_ONLY=1 \
build/build_abi.sh --update --print-report"
========================================================
ABI DIFFERENCES HAVE BEEN DETECTED!
3 symbol(s) added
'int snd_pcm_create_iec958_consumer_default(u8 *, size_t)'
'int snd_pcm_fill_iec958_consumer(struct snd_pcm_runtime *, u8 *, size_t)'
'int snd_pcm_fill_iec958_consumer_hw_params(struct snd_pcm_hw_params *, u8 *, size_t)'
========================================================
Bug: 146449535
Fixes: 8de9ae8605 ("UPSTREAM: ALSA: iec958: Split status creation and fill")
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Change-Id: I0ae0be501faea03f67feb9358b8e44f70571f2df
In BUILD.bazel, explicitly list abi_definition,
kmi_symbol_list, and additional_kmi_symbol_lists.
This avoids using the glob expression which may
accidentally match editor backup files.
Bug: 246344503
Test: TH
Change-Id: I3cd494dee47b68a0fe7c3c80dd379b5af6b060fe
Signed-off-by: Yifan Hong <elsk@google.com>
Add an explicite check for ATTR_KILL_SUID and ATTR_MODE in incfs_setattr.
Both of these attributes can not be set at the same time, otherwise
notify_change() function will check it and invoke BUG(), crashing
the system.
Bug: 243394930
Signed-off-by: Tadeusz Struk <tadeusz.struk@linaro.org>
Change-Id: I91080d68efbd62f1441e20a5c02feef3d1b06e4e
This reverts commit 3d35c6b91d.
Patch "scsi: ufs: core: Reduce the power mode change timeout" caused a
spike in the number of UFS suspend timeouts. Hence revert that change
and also later UFS driver changes.
Bug: b/246990788
Change-Id: I5aae929f0598020dc5e7c440946eb0d2101b07cc
Signed-off-by: Bart Van Assche <bvanassche@google.com>
This reverts commit f68d040c31.
Patch "scsi: ufs: core: Reduce the power mode change timeout" caused a
spike in the number of UFS suspend timeouts. Hence revert that change
and also later UFS driver changes.
Bug: b/246990788
Change-Id: Ic20594727d47dc6d9af9a320d64bd7011112e789
Signed-off-by: Bart Van Assche <bvanassche@google.com>
GZIP-compressed files end with 4 byte data that represents the size
of the original input. The decompressors (the self-extracting kernel)
exploit it to know the vmlinux size beforehand. To mimic the GZIP's
trailer, Kbuild provides cmd_{bzip2,lzma,lzo,lz4,xzkern,zstd22}.
Unfortunately these macros are used everywhere despite the appended
size data is only useful for the decompressors.
There is no guarantee that such hand-crafted trailers are safely ignored.
In fact, the kernel refuses compressed initramdfs with the garbage data.
That is why usr/Makefile overrides size_append to make it no-op.
To limit the use of such broken compressed files, this commit renames
the existing macros as follows:
cmd_bzip2 --> cmd_bzip2_with_size
cmd_lzma --> cmd_lzma_with_size
cmd_lzo --> cmd_lzo_with_size
cmd_lz4 --> cmd_lz4_with_size
cmd_xzkern --> cmd_xzkern_with_size
cmd_zstd22 --> cmd_zstd22_with_size
To keep the decompressors working, I updated the following Makefiles
accordingly:
arch/arm/boot/compressed/Makefile
arch/h8300/boot/compressed/Makefile
arch/mips/boot/compressed/Makefile
arch/parisc/boot/compressed/Makefile
arch/s390/boot/compressed/Makefile
arch/sh/boot/compressed/Makefile
arch/x86/boot/compressed/Makefile
I reused the current macro names for the normal usecases; they produce
the compressed data in the proper format.
I did not touch the following:
arch/arc/boot/Makefile
arch/arm64/boot/Makefile
arch/csky/boot/Makefile
arch/mips/boot/Makefile
arch/riscv/boot/Makefile
arch/sh/boot/Makefile
kernel/Makefile
This means those Makefiles will stop appending the size data.
I dropped the 'override size_append' hack from usr/Makefile.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
Bug: 135791357
(cherry picked from commit 7ce7e984abhttps://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master)
Change-Id: I3524909ef3daab85f7d22afdebc2e5bbfd5e5cf3
[szuweilin: Resolved the conflict about non-existing zstd22 in arch/s390/boot/compressed/Makefile]
Signed-off-by: SzuWei Lin <szuweilin@google.com>
The following deadlocks have been observed on multiple test setups:
* ufshcd_wl_suspend() is waiting for blk_execute_rq() to complete while it
holds host_sem.
* ufshcd_eh_host_reset_handler() invokes ufshcd_err_handler() and the
latter function tries to obtain host_sem.
This is a deadlock because blk_execute_rq() can't execute SCSI commands
while the host is in the SHOST_RECOVERY state and because the error
handler cannot make progress either.
* ufshcd_wl_runtime_resume() is waiting for blk_execute_rq() to finish
while it holds host_sem.
* ufshcd_eh_host_reset_handler() invokes ufshcd_err_handler() and the
latter function calls pm_runtime_resume().
This is a deadlock because of the same reason as the previous scenario.
Fix both deadlocks by not obtaining host_sem from the power management
code paths. Removing the host_sem locking from the power management code
is safe because the ufshcd_err_handler() is already serialized against
SCSI command execution.
Cc: dh0421.hwang@samsung.com
Cc: Asutosh Das <asutoshd@codeaurora.org>
Fixes: b294ff3e34 ("scsi: ufs: core: Enable power management for wlun")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Bug: 240498410
Bug: 246990788
Bug: 247073231
Bug: 247081382
Bug: 247082093
Link: https://lore.kernel.org/linux-scsi/
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Change-Id: Ifb9b429ba89ff6d8a133d96a172eaefc09d85955
The IEC958 status bit is usually set by the userspace after hw_params
has been called, so in order to use whatever is set by the userspace, we
need to implement the prepare hook. Let's add it to the hdmi_codec_ops,
and mandate that either prepare or hw_params is implemented.
Bug: 239396464
Change-Id: I06ccde5d8185955bb60783b597f0205811460968
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210525132354.297468-6-maxime@cerno.tech
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
(cherry picked from commit 2fef64eec2)
The IEC958 status bits can be exposed and modified by the userspace
through dedicated ALSA controls.
This patch implements those controls for the hdmi-codec driver. It
relies on a default value being setup at probe time that can later be
overridden by the control put.
The hw_params callback is then called with a buffer filled with the
proper bits for the current parameters being passed on so the underlying
driver can just reuse those bits as is.
Bug: 239396464
Change-Id: I99f37b7e74655687e73a75ba19fd2de8041f8646
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210525132354.297468-5-maxime@cerno.tech
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
(cherry picked from commit 7a8e1d4421)
In some situations, like a codec probe, we need to provide an IEC status
default but don't have access to the sampling rate and width yet since
no stream has been configured yet.
Each and every driver has its own default, whereas the core iec958 code
also has some buried in the snd_pcm_create_iec958_consumer functions.
Let's split these functions in two to provide a default that doesn't
rely on the sampling rate and width, and another function to fill them
when available.
Bug: 239396464
Change-Id: I277899145367b219b337bc796f2faee8c4917082
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20210525132354.297468-3-maxime@cerno.tech
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
(cherry picked from commit 9eafc11f92)
The doc currently mentions that the IEC958 Playback Default should be
exposed on the PCM iface, and the Playback Mask on the mixer iface.
It's a bit confusing to advise to have two related controls on two
separate ifaces, and it looks like the drivers that currently expose
those controls use any combination of the mixer and PCM ifaces.
Let's try to clarify the situation a bit, and encourage to at least have
the controls on the same iface.
Bug: 239396464
Change-Id: Ie0fb033564972f74154c378c644c581dc4d06dfa
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20210525132354.297468-2-maxime@cerno.tech
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
(cherry picked from commit aa7899537a)
Sound is broken on the DragonBoard 410c (apq8016_sbc) since 5.10:
hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_component_set_jack on hdmi-audio-codec.1.auto: -95
qcom-apq8016-sbc 7702000.sound: Failed to set jack: -95
ADV7533: ASoC: error at snd_soc_link_init on ADV7533: -95
hdmi-audio-codec hdmi-audio-codec.1.auto: ASoC: error at snd_soc_component_set_jack on hdmi-audio-codec.1.auto: -95
qcom-apq8016-sbc: probe of 7702000.sound failed with error -95
This happens because apq8016_sbc calls snd_soc_component_set_jack() on
all codec DAIs and attempts to ignore failures with return code -ENOTSUPP.
-ENOTSUPP is also excluded from error logging in soc_component_ret().
However, hdmi_codec_set_jack() returns -E*OP*NOTSUPP if jack detection
is not supported, which is not handled in apq8016_sbc and soc_component_ret().
Make it return -ENOTSUPP instead to fix sound and silence the errors.
Bug: 239396464
Change-Id: Id38ce1cdfc80daaac7d77212cecd29dd6fa4e877
Cc: Cheng-Yi Chiang <cychiang@chromium.org>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Fixes: 55c5cc63ab ("ASoC: hdmi-codec: Use set_jack ops to set jack")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Acked-by: Nicolin Chen <nicoleotsuka@gmail.com>
Link: https://lore.kernel.org/r/20210107165131.2535-1-stephan@gerhold.net
Signed-off-by: Mark Brown <broonie@kernel.org>
(cherry picked from commit 2a0435df96)
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
In plugged callback, ELD should be updated from display driver so that
user space can query information from ELD immediately after receiving jack
plugged event.
When jack is unplugged, clear ELD buffer so that user space does not get
obsolete information of unplugged HDMI.
Bug: 239396464
Change-Id: I2245de6e6f7dbc64863267db864dafdd3af95747
Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org>
Link: https://lore.kernel.org/r/20201118043852.1338877-1-cychiang@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
(cherry picked from commit 25ce4f2b35)
aosp/2215503 remove inclusions from hook definition headers
and build breakage detected on pixel device.
include/trace/hooks/mm.h:80:40: error: declaration of 'struct vm_unmapped_area_info' will not be visible outside of this function
Fix this by adding struct vm_unmapped_area_info forward declaration.
Fixes: 7108d9d0e5 ("ANDROID: remove inclusions from hook definition headers")
Bug: 233047575
Signed-off-by: Robin Peng <robinpeng@google.com>
Change-Id: I8989ba78977a26e13c79f9efb156bf8317c1010e
commit 4caae58406 upstream.
The device-mapper framework provides a mechanism to mark targets as
immutable (and hence fail table reloads that try to change the target
type). Add the DM_TARGET_IMMUTABLE flag to the dm-verity target's
feature flags to prevent switching the verity target with a different
target type.
Bug: 234475629
Fixes: a4ffc15219 ("dm: add verity target")
Cc: stable@vger.kernel.org
Signed-off-by: Sarthak Kukreti <sarthakkukreti@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Iaeec7fa3be98a646062439e4551f84242dacfb45
commit 189b0ddc24 upstream.
pipe_resize_ring() needs to take the pipe->rd_wait.lock spinlock to
prevent post_one_notification() from trying to insert into the ring
whilst the ring is being replaced.
The occupancy check must be done after the lock is taken, and the lock
must be taken after the new ring is allocated.
The bug can lead to an oops looking something like:
BUG: KASAN: use-after-free in post_one_notification.isra.0+0x62e/0x840
Read of size 4 at addr ffff88801cc72a70 by task poc/27196
...
Call Trace:
post_one_notification.isra.0+0x62e/0x840
__post_watch_notification+0x3b7/0x650
key_create_or_update+0xb8b/0xd20
__do_sys_add_key+0x175/0x340
__x64_sys_add_key+0xbe/0x140
do_syscall_64+0x5c/0xc0
entry_SYSCALL_64_after_hwframe+0x44/0xae
Reported by Selim Enes Karaduman @Enesdex working with Trend Micro Zero
Day Initiative.
Bug: 244395411
Fixes: c73be61ced ("pipe: Add general notification queue support")
Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-17291
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I129164eb9dba557d5a4370f4eca124b9916774a6
commit fee060cd52 upstream.
Whenever x86_decode_emulated_instruction() detects a breakpoint, it
returns the value that kvm_vcpu_check_breakpoint() writes into its
pass-by-reference second argument. Unfortunately this is completely
bogus because the expected outcome of x86_decode_emulated_instruction
is an EMULATION_* value.
Then, if kvm_vcpu_check_breakpoint() does "*r = 0" (corresponding to
a KVM_EXIT_DEBUG userspace exit), it is misunderstood as EMULATION_OK
and x86_emulate_instruction() is called without having decoded the
instruction. This causes various havoc from running with a stale
emulation context.
The fix is to move the call to kvm_vcpu_check_breakpoint() where it was
before commit 4aa2691dcb ("KVM: x86: Factor out x86 instruction
emulation with decoding") introduced x86_decode_emulated_instruction().
The other caller of the function does not need breakpoint checks,
because it is invoked as part of a vmexit and the processor has already
checked those before executing the instruction that #GP'd.
This fixes CVE-2022-1852.
Bug: 235183128
Reported-by: Qiuhao Li <qiuhao@sysec.org>
Reported-by: Gaoning Pan <pgn@zju.edu.cn>
Reported-by: Yongkang Jia <kangel@zju.edu.cn>
Fixes: 4aa2691dcb ("KVM: x86: Factor out x86 instruction emulation with decoding")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20220311032801.3467418-2-seanjc@google.com>
[Rewrote commit message according to Qiuhao's report, since a patch
already existed to fix the bug. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I3acbb7fc23566c4108f15960c420384af52c2703
Fix the position of the trace point.
Bug: 241946090
Fixes: 737a5314c9 ("ANDROID: power: Add vendor hook for suspend")
Signed-off-by: Ziyi Cui <ziyic@google.com>
Change-Id: I8bf231ee35e0c0ebcb35722f4c527ab61116901e
To avoid changing the visibiliy of data types when including
hook definition headers remove header file inclusions from
the hook definition header files.
Instead, the hook definition headers should just have forward
declarations that don't require full definition.
To provide full definitions of the types for the KMI, the
headers that define the types should be included by the
source file that instantiates the hooks - normally
vendor_hooks.c.
Since the KMI is frozen, some of the inclusions are still
required to preserve the CRC associated with symbols. Keep
these inclusions under #ifdef __GENKSYMS__.
This patch results in 17 fewer opaque types in the KMI
(80 vs 97). Of the remaining 80 opaque types, 50 are
defined in C files (and therefore are truly opaque and
cannot be used by vendor modules). That leaves 30
types that still need definition in the KMI.
Bug: 233047575
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: Ibc1173eb4b07fcec21c7abd8e0ab1950b3fb5b34
Remove the obsolete use of CONFIG_TRACEPOINTS in hook definition
header files. The !CONFIG_TRACEPOINTS case is correctly handled
by the included trace header files.
Bug: 233047575
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I957649bcfef375284f2885cf732ff2960c303837
commit 353f7988dd upstream.
When the pipe is closed, we mark the associated watchqueue defunct by
calling watch_queue_clear(). However, while that is protected by the
watchqueue lock, new watchqueue entries aren't actually added under that
lock at all: they use the pipe->rd_wait.lock instead, and looking up
that pipe happens without any locking.
The watchqueue code uses the RCU read-side section to make sure that the
wqueue entry itself hasn't disappeared, but that does not protect the
pipe_info in any way.
So make sure to actually hold the wqueue lock when posting watch events,
properly serializing against the pipe being torn down.
Bug: 235277737
Reported-by: Noam Rathaus <noamr@ssd-disclosure.com>
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: I42b0d56021be1d8950c3642ae0acc5cdccadb394
1 symbol(s) added
'void __bitmap_xor(unsigned long int *, const unsigned long int *, const unsigned long int *, unsigned int)'
Bug: 228779790
Signed-off-by: Jack Diver <diverj@google.com>
Change-Id: Ia7622941d313214eaf1aaf26aba64e0e149fa7ca
