Fix possible race condition in data->type value in case of multithreaded
listener or app IOCTLs.
For example, below could cause inconsistent data->type value while
racing belows IOCTLs
Thread1 with QSEECOM_IOCTL_REGISTER_LISTENER_REQ
Thread2 with QSEECOM_IOCTL_UNREGISTER_LISTENER_REQ.
Change-Id: I436b63c044a66c324d94db27566a7be70981bd6b
Signed-off-by: Divisha Bisht <quic_divibish@quicinc.com>
'sprintf' has been deprecated, hence replace it with
a safer function scnprintf.
Change-Id: I9bc8e3dfd2032a0447f38fc98a3ad31d9d609cab
Signed-off-by: Rajashekar kuruva <quic_kuruva@quicinc.com>
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
Currently, the DSP updates header buffers with unused DMA handle fds.
In the put_args section, if any DMA handle FDs are present in the
header buffer, the corresponding map is freed. However, since the
header buffer is exposed to users in unsigned PD, users can update
invalid FDs. If this invalid FD matches with any FD that is already
in use, it could lead to a use-after-free (UAF) vulnerability.
As a solution,add DMA handle references for DMA FDs, and the map for
the FD will be freed only when a reference is found.
Acked-by: Om Deore <quic_odeore@quicinc.com>
Change-Id: I19ae21230bf11fe89858b10c9069a5daccabc392
Signed-off-by: Santosh Sakore <quic_ssakore@quicinc.com>
Currently, the get_current_groups API accesses group info, which
increases the usage refcount. If the IOCTL using the
get_current_groups API is called many times, the usage counter
overflows. To avoid this, access group info without taking a
reference. A reference is not required as group info is not
released during the IOCTL call.
Change-Id: Ib4de80cac8b36f73d8f5c6dd9824722153189285
Signed-off-by: ANANDU KRISHNAN E <quic_anane@quicinc.com>
Currently, functions gsi_inst_clean & gsi_free_inst utilises
gsi_opts without any check, however there is a possibility
that the opts structure could become NULL. In such case, due
to lack of if checks can result in NULL pointer dereference.
Change-Id: I548690e2eee377b5292f258972ae7e38417f3085
Signed-off-by: Prashanth K <quic_prashk@quicinc.com>
[ Upstream commit affc18fdc694190ca7575b9a86632a73b9fe043d ]
q->bands will be assigned to qopt->bands to execute subsequent code logic
after kmalloc. So the old q->bands should not be used in kmalloc.
Otherwise, an out-of-bounds write will occur.
Bug: 349777785
Fixes: c2999f7fb0 ("net: sched: multiq: don't call qdisc_put() while holding tree lock")
Signed-off-by: Hangyu Hua <hbh25y@gmail.com>
Acked-by: Cong Wang <cong.wang@bytedance.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 0f208fad86631e005754606c3ec80c0d44a11882)
Signed-off-by: Lee Jones <joneslee@google.com>
Change-Id: Iec8413c39878596795420ae58bbe6974890cf2de
Binder objects are processed and copied individually into the target
buffer during transactions. Any raw data in-between these objects is
copied as well. However, this raw data copy lacks an out-of-bounds
check. If the raw data exceeds the data section size then the copy
overwrites the offsets section. This eventually triggers an error that
attempts to unwind the processed objects. However, at this point the
offsets used to index these objects are now corrupted.
Unwinding with corrupted offsets can result in decrements of arbitrary
nodes and lead to their premature release. Other users of such nodes are
left with a dangling pointer triggering a use-after-free. This issue is
made evident by the following KASAN report (trimmed):
==================================================================
BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c
Write of size 4 at addr ffff47fc91598f04 by task binder-util/743
CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1
Hardware name: linux,dummy-virt (DT)
Call trace:
_raw_spin_lock+0xe4/0x19c
binder_free_buf+0x128/0x434
binder_thread_write+0x8a4/0x3260
binder_ioctl+0x18f0/0x258c
[...]
Allocated by task 743:
__kmalloc_cache_noprof+0x110/0x270
binder_new_node+0x50/0x700
binder_transaction+0x413c/0x6da8
binder_thread_write+0x978/0x3260
binder_ioctl+0x18f0/0x258c
[...]
Freed by task 745:
kfree+0xbc/0x208
binder_thread_read+0x1c5c/0x37d4
binder_ioctl+0x16d8/0x258c
[...]
==================================================================
To avoid this issue, let's check that the raw data copy is within the
boundaries of the data section.
Fixes: 6d98eb95b450 ("binder: avoid potential data leakage when copying txn")
Cc: Todd Kjos <tkjos@google.com>
Cc: stable@vger.kernel.org
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Bug: 352520660
Link: https://lore.kernel.org/all/20240822182353.2129600-1-cmllamas@google.com/
Change-Id: I1b2dd8403b63e5eeb58904558b7b542141c83fc2
Signed-off-by: Carlos Llamas <cmllamas@google.com>
In current implementation, when host wake request is received in D0 and
M3 states, the following sequence of events are happening causing next
host wake request from IPA/ client to fail.
Sequence of events:
1. Device is in waking up process in D0, M3 states and expecting M0
next.
2. Wake up request received as device in M3.
3. Host wake API is executed setting host_wake_pending flag as well.
4. M0 received as part of wake up from 1.
5. Device in D0, M0 states.
6. Device again went to suspend state as no transfers are happening.
7. Device in D3cold, M3 states
8. Wake up request received from IPA.
9. Host wake API is called again but its returning without any operation
as host_wake_pending flag is set. wake toggle is not done.
10. host_wake_pending flag is cleared only on receiving next D0.
11. Host wake requests are failing because of 9.
To handle this, avoiding setting of host_wake_pending flag when the host
wake request is received in D0 state.
Change-Id: I83acde55e6c116653c3ed00e6b4560e3db6390bd
Signed-off-by: Sai Chaitanya Kaveti <quic_skaveti@quicinc.com>
Sometimes, device receives two consecutive wake-up events, added into a
workqueue. Then device assert WAKE# and host deassert PERST# if device
in D3cold state, triggering deassert perst IRQ. In IRQ thread, device
flush the workqueue to make sure previous d3cold process has completed
before enable endpoint. commit 43917f862f7d ("msm: mhi_dev: Flush
workqueue before processing PERST deassert"). However, the second wake
event is also in the workqueue, so ep_pcie_core_wakeup_host_internal
is invoked and seeing dev->perst_deast is true, setted by deassert
PERST# IRQ. Then device goes to access MHI register to issue inband PME,
leading to NOC error because endpoint is still disabled.
So add a check to prevent wake operation if a previous wake has completed.
10567.834470: [0x8219195 mhi_sm_dev_event_manager] Handling
MHI_DEV_EVENT_CORE_WAKEUP event, current states: M3 & D3_COLD_STATE
10567.834498: ep_pcie_core_toggle_wake_gpio: PCIe V1711211: No. 115 to
assert PCIe WAKE#; perst is asserted; D3hot is received, WAKE GPIO
state:0
10567.834507: ep_pcie_core_wakeup_host_internal: PCIe V1711211: Set wake
pending : 1 and return ; perst is not de-asserted; D3hot is set
10567.849704: [0x8219195 mhi_dev_notify_sm_event] received:
MHI_DEV_EVENT_HW_ACC_WAKEUP
10567.849976: ep_pcie_handle_perst_irq: PCIe V1711211: No. 1018 PERST
deassertion
10567.850053: [0x8219195 mhi_sm_dev_event_manager] Handling
MHI_DEV_EVENT_HW_ACC_WAKEUP event, current states: M3 & D3_COLD_STATE
10567.850071: ep_pcie_core_wakeup_host_internal: PCIe V1711211: request to
assert WAKE# when in D3hot
10567.860093: ep_pcie_core_issue_inband_pme: PCIe V1711211: request to
assert inband wake.
Change-Id: I85fb37c4171c5ef4974c573f0abba199cb718a84
Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
Add code to install exception rule for icmp
and dhcp packet in DL direction for v4 and v6.
Change-Id: I27a2c3cb9cb342a5e4d22246e350bf721d784a15
Signed-off-by: Himansu Nayak <quic_himansu@quicinc.com>
This reverts commit e011febff8 which is
commit b8ec0dc3845f6c9089573cb5c2c4b05f7fc10728 upstream.
It breaks the Android kernel abi and can be brought back in the future
in an abi-safe way if it is really needed.
Bug: 161946584
Change-Id: I08cf60f05f5db95e255ce111e9556b0671b0cc09
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Changes in 5.4.281
gcc-plugins: Rename last_stmt() for GCC 14+
filelock: Remove locks reliably when fcntl/close race is detected
scsi: qedf: Set qed_slowpath_params to zero before use
ACPI: EC: Abort address space access upon error
ACPI: EC: Avoid returning AE_OK on errors in address space handler
wifi: mac80211: mesh: init nonpeer_pm to active by default in mesh sdata
wifi: mac80211: fix UBSAN noise in ieee80211_prep_hw_scan()
Input: silead - Always support 10 fingers
ila: block BH in ila_output()
kconfig: gconf: give a proper initial state to the Save button
kconfig: remove wrong expr_trans_bool()
fs/file: fix the check in find_next_fd()
mei: demote client disconnect warning on suspend to debug
wifi: cfg80211: wext: add extra SIOCSIWSCAN data check
KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()
ALSA: hda/realtek: Add more codec ID to no shutup pins list
mips: fix compat_sys_lseek syscall
Input: elantech - fix touchpad state on resume for Lenovo N24
bytcr_rt5640 : inverse jack detect for Archos 101 cesium
ASoC: ti: davinci-mcasp: Set min period size using FIFO config
ASoC: ti: omap-hdmi: Fix too long driver name
can: kvaser_usb: fix return value for hif_usb_send_regout
s390/sclp: Fix sclp_init() cleanup on failure
ALSA: dmaengine_pcm: terminate dmaengine before synchronize
net: usb: qmi_wwan: add Telit FN912 compositions
net: mac802154: Fix racy device stats updates by DEV_STATS_INC() and DEV_STATS_ADD()
powerpc/pseries: Whitelist dtl slub object for copying to userspace
powerpc/eeh: avoid possible crash when edev->pdev changes
scsi: libsas: Fix exp-attached device scan after probe failure scanned in again after probe failed
Bluetooth: hci_core: cancel all works upon hci_unregister_dev()
fs: better handle deep ancestor chains in is_subdir()
spi: imx: Don't expect DMA for i.MX{25,35,50,51,53} cspi devices
selftests/vDSO: fix clang build errors and warnings
hfsplus: fix uninit-value in copy_name
ARM: 9324/1: fix get_user() broken with veneer
ACPI: processor_idle: Fix invalid comparison with insertion sort for latency
drm/amdgpu: Fix signedness bug in sdma_v4_0_process_trap_irq()
net: relax socket state check at accept time.
ocfs2: add bounds checking to ocfs2_check_dir_entry()
jfs: don't walk off the end of ealist
ALSA: hda/realtek: Enable headset mic on Positivo SU C1400
filelock: Fix fcntl/close race recovery compat path
tun: add missing verification for short frame
tap: add missing verification for short frame
Linux 5.4.281
Change-Id: If3e8a4591ecbbace6792fd595d60744b4364668c
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
commit ed7f2afdd0e043a397677e597ced0830b83ba0b3 upstream.
The cited commit missed to check against the validity of the frame length
in the tap_get_user_xdp() path, which could cause a corrupted skb to be
sent downstack. Even before the skb is transmitted, the
tap_get_user_xdp()-->skb_set_network_header() may assume the size is more
than ETH_HLEN. Once transmitted, this could either cause out-of-bound
access beyond the actual length, or confuse the underlayer with incorrect
or inconsistent header length in the skb metadata.
In the alternative path, tap_get_user() already prohibits short frame which
has the length less than Ethernet header size from being transmitted.
This is to drop any frame shorter than the Ethernet header size just like
how tap_get_user() does.
CVE: CVE-2024-41090
Link: https://lore.kernel.org/netdev/1717026141-25716-1-git-send-email-si-wei.liu@oracle.com/
Fixes: 0efac27791 ("tap: accept an array of XDP buffs through sendmsg()")
Cc: stable@vger.kernel.org
Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com>
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Jason Wang <jasowang@redhat.com>
Link: https://patch.msgid.link/20240724170452.16837-2-dongli.zhang@oracle.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 049584807f1d797fc3078b68035450a9769eb5c3 upstream.
The cited commit missed to check against the validity of the frame length
in the tun_xdp_one() path, which could cause a corrupted skb to be sent
downstack. Even before the skb is transmitted, the
tun_xdp_one-->eth_type_trans() may access the Ethernet header although it
can be less than ETH_HLEN. Once transmitted, this could either cause
out-of-bound access beyond the actual length, or confuse the underlayer
with incorrect or inconsistent header length in the skb metadata.
In the alternative path, tun_get_user() already prohibits short frame which
has the length less than Ethernet header size from being transmitted for
IFF_TAP.
This is to drop any frame shorter than the Ethernet header size just like
how tun_get_user() does.
CVE: CVE-2024-41091
Inspired-by: https://lore.kernel.org/netdev/1717026141-25716-1-git-send-email-si-wei.liu@oracle.com/
Fixes: 043d222f93 ("tuntap: accept an array of XDP buffs through sendmsg()")
Cc: stable@vger.kernel.org
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Reviewed-by: Si-Wei Liu <si-wei.liu@oracle.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Reviewed-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Jason Wang <jasowang@redhat.com>
Link: https://patch.msgid.link/20240724170452.16837-3-dongli.zhang@oracle.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d0fa70aca54c8643248e89061da23752506ec0d4 upstream.
Add a check before visiting the members of ea to
make sure each ea stays within the ealist.
Signed-off-by: lei lu <llfamsec@gmail.com>
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6769a23697f17f9bf9365ca8ed62fe37e361a05a upstream.
The "instance" variable needs to be signed for the error handling to work.
Fixes: 8b2faf1a4f3b ("drm/amdgpu: add error handle to avoid out-of-bounds")
Reviewed-by: Bob Zhou <bob.zhou@amd.com>
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Siddh Raman Pant <siddh.raman.pant@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 233323f9b9f828cd7cd5145ad811c1990b692542 upstream.
The acpi_cst_latency_cmp() comparison function currently used for
sorting C-state latencies does not satisfy transitivity, causing
incorrect sorting results.
Specifically, if there are two valid acpi_processor_cx elements A and B
and one invalid element C, it may occur that A < B, A = C, and B = C.
Sorting algorithms assume that if A < B and A = C, then C < B, leading
to incorrect ordering.
Given the small size of the array (<=8), we replace the library sort
function with a simple insertion sort that properly ignores invalid
elements and sorts valid ones based on latency. This change ensures
correct ordering of the C-state latencies.
Fixes: 65ea8f2c6e23 ("ACPI: processor idle: Fix up C-state latency if not ordered")
Reported-by: Julian Sikorski <belegdol@gmail.com>
Closes: https://lore.kernel.org/lkml/70674dc7-5586-4183-8953-8095567e73df@gmail.com
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Tested-by: Julian Sikorski <belegdol@gmail.com>
Cc: All applicable <stable@vger.kernel.org>
Link: https://patch.msgid.link/20240701205639.117194-1-visitorckw@gmail.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 24d3ba0a7b44c1617c27f5045eecc4f34752ab03 upstream.
The 32-bit ARM kernel stops working if the kernel grows to the point
where veneers for __get_user_* are created.
AAPCS32 [1] states, "Register r12 (IP) may be used by a linker as a
scratch register between a routine and any subroutine it calls. It
can also be used within a routine to hold intermediate values between
subroutine calls."
However, bl instructions buried within the inline asm are unpredictable
for compilers; hence, "ip" must be added to the clobber list.
This becomes critical when veneers for __get_user_* are created because
veneers use the ip register since commit 02e541db05 ("ARM: 8323/1:
force linker to use PIC veneers").
[1]: https://github.com/ARM-software/abi-aa/blob/2023Q1/aapcs32/aapcs32.rst
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Cc: John Stultz <jstultz@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 73810cd45b99c6c418e1c6a487b52c1e74edb20d ]
When building with clang, via:
make LLVM=1 -C tools/testing/selftests
...there are several warnings, and an error. This fixes all of those and
allows these tests to run and pass.
1. Fix linker error (undefined reference to memcpy) by providing a local
version of memcpy.
2. clang complains about using this form:
if (g = h & 0xf0000000)
...so factor out the assignment into a separate step.
3. The code is passing a signed const char* to elf_hash(), which expects
a const unsigned char *. There are several callers, so fix this at
the source by allowing the function to accept a signed argument, and
then converting to unsigned operations, once inside the function.
4. clang doesn't have __attribute__((externally_visible)) and generates
a warning to that effect. Fortunately, gcc 12 and gcc 13 do not seem
to require that attribute in order to build, run and pass tests here,
so remove it.
Reviewed-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Edward Liaw <edliaw@google.com>
Reviewed-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
Tested-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
Signed-off-by: John Hubbard <jhubbard@nvidia.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ce1dac560a74220f2e53845ec0723b562288aed4 ]
While in commit 2dd33f9cec ("spi: imx: support DMA for imx35") it was
claimed that DMA works on i.MX25, i.MX31 and i.MX35 the respective
device trees don't add DMA channels. The Reference manuals of i.MX31 and
i.MX25 also don't mention the CSPI core being DMA capable. (I didn't
check the others.)
Since commit e267a5b3ec59 ("spi: spi-imx: Use dev_err_probe for failed
DMA channel requests") this results in an error message
spi_imx 43fa4000.spi: error -ENODEV: can't get the TX DMA channel!
during boot. However that isn't fatal and the driver gets loaded just
fine, just without using DMA.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://patch.msgid.link/20240508095610.2146640-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 391b59b045004d5b985d033263ccba3e941a7740 ]
Jan reported that 'cd ..' may take a long time in deep directory
hierarchies under a bind-mount. If concurrent renames happen it is
possible to livelock in is_subdir() because it will keep retrying.
Change is_subdir() from simply retrying over and over to retry once and
then acquire the rename lock to handle deep ancestor chains better. The
list of alternatives to this approach were less then pleasant. Change
the scope of rcu lock to cover the whole walk while at it.
A big thanks to Jan and Linus. Both Jan and Linus had proposed
effectively the same thing just that one version ended up being slightly
more elegant.
Reported-by: Jan Kara <jack@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0d151a103775dd9645c78c97f77d6e2a5298d913 ]
syzbot is reporting that calling hci_release_dev() from hci_error_reset()
due to hci_dev_put() from hci_error_reset() can cause deadlock at
destroy_workqueue(), for hci_error_reset() is called from
hdev->req_workqueue which destroy_workqueue() needs to flush.
We need to make sure that hdev->{rx_work,cmd_work,tx_work} which are
queued into hdev->workqueue and hdev->{power_on,error_reset} which are
queued into hdev->req_workqueue are no longer running by the moment
destroy_workqueue(hdev->workqueue);
destroy_workqueue(hdev->req_workqueue);
are called from hci_release_dev().
Call cancel_work_sync() on these work items from hci_unregister_dev()
as soon as hdev->list is removed from hci_dev_list.
Reported-by: syzbot <syzbot+da0a9c9721e36db712e8@syzkaller.appspotmail.com>
Closes: https://syzkaller.appspot.com/bug?extid=da0a9c9721e36db712e8
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ab2068a6fb84751836a84c26ca72b3beb349619d ]
The expander phy will be treated as broadcast flutter in the next
revalidation after the exp-attached end device probe failed, as follows:
[78779.654026] sas: broadcast received: 0
[78779.654037] sas: REVALIDATING DOMAIN on port 0, pid:10
[78779.654680] sas: ex 500e004aaaaaaa1f phy05 change count has changed
[78779.662977] sas: ex 500e004aaaaaaa1f phy05 originated BROADCAST(CHANGE)
[78779.662986] sas: ex 500e004aaaaaaa1f phy05 new device attached
[78779.663079] sas: ex 500e004aaaaaaa1f phy05:U:8 attached: 500e004aaaaaaa05 (stp)
[78779.693542] hisi_sas_v3_hw 0000:b4:02.0: dev[16:5] found
[78779.701155] sas: done REVALIDATING DOMAIN on port 0, pid:10, res 0x0
[78779.707864] sas: Enter sas_scsi_recover_host busy: 0 failed: 0
...
[78835.161307] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 tries: 1
[78835.171344] sas: sas_probe_sata: for exp-attached device 500e004aaaaaaa05 returned -19
[78835.180879] hisi_sas_v3_hw 0000:b4:02.0: dev[16:5] is gone
[78835.187487] sas: broadcast received: 0
[78835.187504] sas: REVALIDATING DOMAIN on port 0, pid:10
[78835.188263] sas: ex 500e004aaaaaaa1f phy05 change count has changed
[78835.195870] sas: ex 500e004aaaaaaa1f phy05 originated BROADCAST(CHANGE)
[78835.195875] sas: ex 500e004aaaaaaa1f rediscovering phy05
[78835.196022] sas: ex 500e004aaaaaaa1f phy05:U:A attached: 500e004aaaaaaa05 (stp)
[78835.196026] sas: ex 500e004aaaaaaa1f phy05 broadcast flutter
[78835.197615] sas: done REVALIDATING DOMAIN on port 0, pid:10, res 0x0
The cause of the problem is that the related ex_phy's attached_sas_addr was
not cleared after the end device probe failed, so reset it.
Signed-off-by: Xingui Yang <yangxingui@huawei.com>
Link: https://lore.kernel.org/r/20240619091742.25465-1-yangxingui@huawei.com
Reviewed-by: John Garry <john.g.garry@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 6a7db25aad8ce6512b366d2ce1d0e60bac00a09d ]
When dmaengine supports pause function, in suspend state,
dmaengine_pause() is called instead of dmaengine_terminate_async(),
In end of playback stream, the runtime->state will go to
SNDRV_PCM_STATE_DRAINING, if system suspend & resume happen
at this time, application will not resume playback stream, the
stream will be closed directly, the dmaengine_terminate_async()
will not be called before the dmaengine_synchronize(), which
violates the call sequence for dmaengine_synchronize().
This behavior also happens for capture streams, but there is no
SNDRV_PCM_STATE_DRAINING state for capture. So use
dmaengine_tx_status() to check the DMA status if the status is
DMA_PAUSED, then call dmaengine_terminate_async() to terminate
dmaengine before dmaengine_synchronize().
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://patch.msgid.link/1718851218-27803-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c5dcf8ab10606e76c1d8a0ec77f27d84a392e874 ]
The minimum period size was enforced to 64 as older devices integrating
McASP with EDMA used an internal FIFO of 64 samples.
With UDMA based platforms this internal McASP FIFO is optional, as the
DMA engine internally does some buffering which is already accounted for
when registering the platform. So we should read the actual FIFO
configuration (txnumevt/rxnumevt) instead of hardcoding frames.min to
64.
Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Signed-off-by: Jai Luthra <j-luthra@ti.com>
Link: https://lore.kernel.org/r/20240611-asoc_next-v3-2-fcfd84b12164@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a69ce592cbe0417664bc5a075205aa75c2ec1273 ]
The Lenovo N24 on resume becomes stuck in a state where it
sends incorrect packets, causing elantech_packet_check_v4 to fail.
The only way for the device to resume sending the correct packets is for
it to be disabled and then re-enabled.
This change adds a dmi check to trigger this behavior on resume.
Signed-off-by: Jonathan Denose <jdenose@google.com>
Link: https://lore.kernel.org/r/20240503155020.v2.1.Ifa0e25ebf968d8f307f58d678036944141ab17e6@changeid
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0d5679a0aae2d8cda72169452c32e5cb88a7ab33 ]
This is almost compatible, but passing a negative offset should result
in a EINVAL error, but on mips o32 compat mode would seek to a large
32-bit byte offset.
Use compat_sys_lseek() to correctly sign-extend the argument.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a986fa57fd81a1430e00b3c6cf8a325d6f894a63 ]
Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().
It looks up `stt` from tablefd, but then continues to use it after doing
fdput() on the returned fd. After the fdput() the tablefd is free to be
closed by another thread. The close calls kvm_spapr_tce_release() and
then release_spapr_tce_table() (via call_rcu()) which frees `stt`.
Although there are calls to rcu_read_lock() in
kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent
the UAF, because `stt` is used outside the locked regions.
With an artifcial delay after the fdput() and a userspace program which
triggers the race, KASAN detects the UAF:
BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505
CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1
Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV
Call Trace:
dump_stack_lvl+0xb4/0x108 (unreliable)
print_report+0x2b4/0x6ec
kasan_report+0x118/0x2b0
__asan_load4+0xb8/0xd0
kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
kvm_vfio_set_attr+0x524/0xac0 [kvm]
kvm_device_ioctl+0x144/0x240 [kvm]
sys_ioctl+0x62c/0x1810
system_call_exception+0x190/0x440
system_call_vectored_common+0x15c/0x2ec
...
Freed by task 0:
...
kfree+0xec/0x3e0
release_spapr_tce_table+0xd4/0x11c [kvm]
rcu_core+0x568/0x16a0
handle_softirqs+0x23c/0x920
do_softirq_own_stack+0x6c/0x90
do_softirq_own_stack+0x58/0x90
__irq_exit_rcu+0x218/0x2d0
irq_exit+0x30/0x80
arch_local_irq_restore+0x128/0x230
arch_local_irq_enable+0x1c/0x30
cpuidle_enter_state+0x134/0x5cc
cpuidle_enter+0x6c/0xb0
call_cpuidle+0x7c/0x100
do_idle+0x394/0x410
cpu_startup_entry+0x60/0x70
start_secondary+0x3fc/0x410
start_secondary_prolog+0x10/0x14
Fix it by delaying the fdput() until `stt` is no longer in use, which
is effectively the entire function. To keep the patch minimal add a call
to fdput() at each of the existing return paths. Future work can convert
the function to goto or __cleanup style cleanup.
With the fix in place the test case no longer triggers the UAF.
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Closes: https://lore.kernel.org/all/20240610024437.GA1464458@ZenIV/
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://msgid.link/20240614122910.3499489-1-mpe@ellerman.id.au
Signed-off-by: Sasha Levin <sashal@kernel.org>
