"LA.UM.9.14.r1-25000.02-LAHAINA.QSSI14.0"
* tag 'LA.UM.9.14.r1-25000.02-LAHAINA.QSSI14.0' of https://git.codelinaro.org/clo/la/kernel/msm-5.4:
msm-5.4.c3: qseecom: Fix possible race condition
msm: adsprpc: Avoid taking reference for group_info
adsprpc: Handle UAF scenario in put_args
msm-5.4.c3: qseecom: Fix possible race condition
USB: storage: Replace the sprintf with scnprintf
adsprpc: Handle UAF scenario in put_args
msm: adsprpc: Avoid taking reference for group_info
usb: gadget: f_gsi: bail out if opts is null
msm: ep_pcie: Avoid setting host wake pending flag for D0
msm: ep_pcie: Prevent repetitive wake operation if wake is in process
msm_ipa: Install exception rule for PPPoE-MPLS
securemsm-kernel: Decrement the server object ref count in mutex context
qcedev: fix UAF in qcedev_smmu
thermal: qcom: Add support to update tsens trip based on nvmem data
msm: eva: Fix UAF issue when remove module
msm: cvp: OOB write fix due to integer underflow
msm: ep_pcie: Avoid writing req_L1_exit during dstate change
msm: eva: Adding kref count for cvp_get_inst_from_id
Change-Id: I3dad70dec062688b50554d7676a4b85bcb42fad9
https://source.android.com/docs/security/bulletin/2024-09-01
CVE-2024-36972
* tag 'ASB-2024-09-05_11-5.4' of https://android.googlesource.com/kernel/common: (59 commits)
ANDROID: delete tool added by mistake
ANDROID: fix ENOMEM check of binder_proc_ext
ANDROID: binder: fix KMI issues due to frozen notification
BACKPORT: FROMGIT: binder: frozen notification binder_features flag
BACKPORT: FROMGIT: binder: frozen notification
BACKPORT: selftests/binderfs: add test for feature files
UPSTREAM: docs: binderfs: add section about feature files
BACKPORT: binderfs: add support for feature files
FROMLIST: binder: fix memory leaks of spam and pending work
FROMGIT: Binder: add TF_UPDATE_TXN to replace outdated txn
BACKPORT: binder: tell userspace to dump current backtrace when detected oneway spamming
UPSTREAM: net: sched: sch_multiq: fix possible OOB write in multiq_tune()
FROMLIST: binder: fix UAF caused by offsets overwrite
Revert "net: mac802154: Fix racy device stats updates by DEV_STATS_INC() and DEV_STATS_ADD()"
Linux 5.4.281
tap: add missing verification for short frame
tun: add missing verification for short frame
filelock: Fix fcntl/close race recovery compat path
ALSA: hda/realtek: Enable headset mic on Positivo SU C1400
jfs: don't walk off the end of ealist
...
Conflicts:
drivers/android/binder.c
include/uapi/linux/android/binder.h
Change-Id: I0cdb84a8241c0abaf6e5fad140ed19480655d53c
Remove the gen-hyprel binary added accidentally while backporting a
patch into an older branch. The tool gets generated in newer builds and
wasn't part of the gitignore file here.
Fixes: d1e87637cd ("BACKPORT: FROMGIT: binder: frozen notification")
Change-Id: I103358cb2ca9c5fb934f047033e44c04fe85298d
Signed-off-by: Carlos Llamas <cmllamas@google.com>
The check should be done against 'eproc' before it gets dereferenced.
Fixes: d49297739550 ("BACKPORT: binder: use euid from cred instead of using task")
Change-Id: Ief0c08212c4da8bdfdf628474de9dd30ee5a8db0
Signed-off-by: Carlos Llamas <cmllamas@google.com>
The patches to support binder's frozen notification feature break the
KMI. This change fixes such issues by (1) moving proc->delivered_freeze
into the existing proc_wrapper struction, (2) dropping the frozen stats
support and (3) amending the STG due to a harmless enum binder_work_type
addition.
These are the reported KMI issues fixed by this patch:
function symbol 'int __traceiter_binder_transaction_received(void*, struct binder_transaction*)' changed
CRC changed from 0x74e9c98b to 0xfe0f8640
type 'struct binder_proc' changed
byte size changed from 584 to 632
member 'struct list_head delivered_death' changed
offset changed by 256
member 'struct list_head delivered_freeze' was added
13 members ('u32 max_threads' .. 'u64 android_oem_data1') changed
offset changed by 384
type 'struct binder_thread' changed
byte size changed from 464 to 496
2 members ('atomic_t tmp_ref' .. 'bool is_dead') changed
offset changed by 224
4 members ('struct task_struct* task' .. 'enum binder_prio_state prio_state') changed
offset changed by 256
type 'struct binder_stats' changed
byte size changed from 216 to 244
member changed from 'atomic_t br[21]' to 'atomic_t br[23]'
type changed from 'atomic_t[21]' to 'atomic_t[23]'
number of elements changed from 21 to 23
member changed from 'atomic_t bc[19]' to 'atomic_t bc[22]'
offset changed from 672 to 736
type changed from 'atomic_t[19]' to 'atomic_t[22]'
number of elements changed from 19 to 22
member changed from 'atomic_t obj_created[7]' to 'atomic_t obj_created[8]'
offset changed from 1280 to 1440
type changed from 'atomic_t[7]' to 'atomic_t[8]'
number of elements changed from 7 to 8
member changed from 'atomic_t obj_deleted[7]' to 'atomic_t obj_deleted[8]'
offset changed from 1504 to 1696
type changed from 'atomic_t[7]' to 'atomic_t[8]'
number of elements changed from 7 to 8
type 'enum binder_work_type' changed
enumerator 'BINDER_WORK_FROZEN_BINDER' (10) was added
enumerator 'BINDER_WORK_CLEAR_FREEZE_NOTIFICATION' (11) was added
Bug: 363013421
Change-Id: If9f1f14a2eda215a4c9cb0823c50c8e0e8079ef1
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Add a flag to binder_features to indicate that the freeze notification
feature is available.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-6-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 363013421
(cherry picked from commit 30b968b002a92870325a5c9d1ce78eba0ce386e7
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
char-misc-next)
Change-Id: Ic26c8ae42d27c6fd8f5daed5eecabd1652e29502
[cmllamas: fix trivial conflicts due to missing extended_error]
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Frozen processes present a significant challenge in binder transactions.
When a process is frozen, it cannot, by design, accept and/or respond to
binder transactions. As a result, the sender needs to adjust its
behavior, such as postponing transactions until the peer process
unfreezes. However, there is currently no way to subscribe to these
state change events, making it impossible to implement frozen-aware
behaviors efficiently.
Introduce a binder API for subscribing to frozen state change events.
This allows programs to react to changes in peer process state,
mitigating issues related to binder transactions sent to frozen
processes.
Implementation details:
For a given binder_ref, the state of frozen notification can be one of
the followings:
1. Userspace doesn't want a notification. binder_ref->freeze is null.
2. Userspace wants a notification but none is in flight.
list_empty(&binder_ref->freeze->work.entry) = true
3. A notification is in flight and waiting to be read by userspace.
binder_ref_freeze.sent is false.
4. A notification was read by userspace and kernel is waiting for an ack.
binder_ref_freeze.sent is true.
When a notification is in flight, new state change events are coalesced into
the existing binder_ref_freeze struct. If userspace hasn't picked up the
notification yet, the driver simply rewrites the state. Otherwise, the
notification is flagged as requiring a resend, which will be performed
once userspace acks the original notification that's inflight.
See https://r.android.com/3070045 for how userspace is going to use this
feature.
Signed-off-by: Yu-Ting Tseng <yutingtseng@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20240709070047.4055369-4-yutingtseng@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 363013421
(cherry picked from commit d579b04a52a183db47dfcb7a44304d7747d551e1
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
char-misc-next)
Change-Id: I5dd32abba932ca7d03ae58660143e075ed778b81
[cmllamas: fix merge conflicts due to missing 0567461a7a6e]
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Verify that feature files are created successfully after mounting a
binderfs instance. Note that only "oneway_spam_detection" feature is
tested with this patch as it is currently the only feature listed.
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20210715031805.1725878-3-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 07e913418ce4ba5eb620dd4668bf91ec94e11136)
Bug: 191910201
Signed-off-by: Carlos Llamas <cmllamas@google.com>
[cmllamas: fix merge issues due to missing eaa163caa4cc]
Change-Id: I86d7ef34b3099c8714c319e48029aaf3dbf87081
Document how binder feature files can be used to determine whether a
feature is supported by the binder driver. "oneway_spam_detection" is
used as an example as it is the first available feature file.
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20210715031805.1725878-2-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 06e1721d2a265d1247093f5ad5ae2958ef10a604)
Bug: 191910201
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Change-Id: I9c4542e0ee65dd94a492fe0440ba8f1a48d8b797
Provide userspace with a mechanism to discover features supported by
the binder driver to refrain from using any unsupported ones in the
first place. Starting with "oneway_spam_detection" only new features
are to be listed under binderfs and all previous ones are assumed to
be supported.
Assuming an instance of binderfs has been mounted at /dev/binderfs,
binder feature files can be found under /dev/binderfs/features/.
Usage example:
$ mkdir /dev/binderfs
$ mount -t binder binder /dev/binderfs
$ cat /dev/binderfs/features/oneway_spam_detection
1
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20210715031805.1725878-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit fc470abf54b2bd6e539065e07905e767b443d719)
Bug: 191910201
Signed-off-by: Carlos Llamas <cmllamas@google.com>
[cmllamas: fix merge conflicts due to missing 095cf502b31e]
Change-Id: Ia5c03aa1881981bee26459e741134b83d5b59693
commit 1aa3aaf8953c84bad398adf6c3cabc9d6685bf7d upstream
A transaction complete work is allocated and queued for each
transaction. Under certain conditions the work->type might be marked as
BINDER_WORK_TRANSACTION_ONEWAY_SPAM_SUSPECT to notify userspace about
potential spamming threads or as BINDER_WORK_TRANSACTION_PENDING when
the target is currently frozen.
However, these work types are not being handled in binder_release_work()
so they will leak during a cleanup. This was reported by syzkaller with
the following kmemleak dump:
BUG: memory leak
unreferenced object 0xffff88810e2d6de0 (size 32):
comm "syz-executor338", pid 5046, jiffies 4294968230 (age 13.590s)
hex dump (first 32 bytes):
e0 6d 2d 0e 81 88 ff ff e0 6d 2d 0e 81 88 ff ff .m-......m-.....
04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff81573b75>] kmalloc_trace+0x25/0x90 mm/slab_common.c:1114
[<ffffffff83d41873>] kmalloc include/linux/slab.h:599 [inline]
[<ffffffff83d41873>] kzalloc include/linux/slab.h:720 [inline]
[<ffffffff83d41873>] binder_transaction+0x573/0x4050 drivers/android/binder.c:3152
[<ffffffff83d45a05>] binder_thread_write+0x6b5/0x1860 drivers/android/binder.c:4010
[<ffffffff83d486dc>] binder_ioctl_write_read drivers/android/binder.c:5066 [inline]
[<ffffffff83d486dc>] binder_ioctl+0x1b2c/0x3cf0 drivers/android/binder.c:5352
[<ffffffff816b25f2>] vfs_ioctl fs/ioctl.c:51 [inline]
[<ffffffff816b25f2>] __do_sys_ioctl fs/ioctl.c:871 [inline]
[<ffffffff816b25f2>] __se_sys_ioctl fs/ioctl.c:857 [inline]
[<ffffffff816b25f2>] __x64_sys_ioctl+0xf2/0x140 fs/ioctl.c:857
[<ffffffff84b30008>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff84b30008>] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
[<ffffffff84c0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
Fix the leaks by kfreeing these work types in binder_release_work() and
handle them as a BINDER_WORK_TRANSACTION_COMPLETE cleanup.
Cc: stable@vger.kernel.org
Fixes: a7dc1e6f99df ("binder: tell userspace to dump current backtrace when detected oneway spamming")
Reported-by: syzbot+7f10c1653e35933c0f1e@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=7f10c1653e35933c0f1e
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Todd Kjos <tkjos@google.com>
Link: https://lore.kernel.org/r/20230922175138.230331-1-cmllamas@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[cmllamas: backport to v5.15 by dropping BINDER_WORK_TRANSACTION_PENDING
as commit 0567461a7a6e is not present. Remove fixes tag accordingly.]
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Link: https://lore.kernel.org/all/20231208034842.997899-1-cmllamas@google.com/
Change-Id: I8e1ee7af87ef5706544e4f320e9498b8f4855a6b
[cmllamas: also backport to v5.4 to fix OOT 8a09136176f6]
Signed-off-by: Carlos Llamas <cmllamas@google.com>
When the target process is busy, incoming oneway transactions are
queued in the async_todo list. If the clients continue sending extra
oneway transactions while the target process is frozen, this queue can
become too large to accommodate new transactions. That's why binder
driver introduced ONEWAY_SPAM_DETECTION to detect this situation. It's
helpful to debug the async binder buffer exhausting issue, but the
issue itself isn't solved directly.
In real cases applications are designed to send oneway transactions
repeatedly, delivering updated inforamtion to the target process.
Typical examples are Wi-Fi signal strength and some real time sensor
data. Even if the apps might only care about the lastet information,
all outdated oneway transactions are still accumulated there until the
frozen process is thawed later. For this kind of situations, there's
no existing method to skip those outdated transactions and deliver the
latest one only.
This patch introduces a new transaction flag TF_UPDATE_TXN. To use it,
use apps can set this new flag along with TF_ONE_WAY. When such an
oneway transaction is to be queued into the async_todo list of a frozen
process, binder driver will check if any previous pending transactions
can be superseded by comparing their code, flags and target node. If
such an outdated pending transaction is found, the latest transaction
will supersede that outdated one. This effectively prevents the async
binder buffer running out and saves unnecessary binder read workloads.
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Li Li <dualli@google.com>
Link: https://lore.kernel.org/r/20220526220018.3334775-2-dualli@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 231624308
Test: manually check async binder buffer size of frozen apps
Test: stress test with kernel 4.14/4.19/5.10/5.15
(cherry picked from commit 9864bb4801331daa48514face9d0f4861e4d485b
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
char-misc-next)
Change-Id: I1c4bff1eda1ca15aaaad5bf696c8fc00be743176
When async binder buffer got exhausted, some normal oneway transactions
will also be discarded and may cause system or application failures. By
that time, the binder debug information we dump may not be relevant to
the root cause. And this issue is difficult to debug if without the
backtrace of the thread sending spam.
This change will send BR_ONEWAY_SPAM_SUSPECT to userspace when oneway
spamming is detected, request to dump current backtrace. Oneway spamming
will be reported only once when exceeding the threshold (target process
dips below 80% of its oneway space, and current process is responsible
for either more than 50 transactions, or more than 50% of the oneway
space). And the detection will restart when the async buffer has
returned to a healthy state.
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Hang Lu <hangl@codeaurora.org>
Link: https://lore.kernel.org/r/1617961246-4502-3-git-send-email-hangl@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bug: 181190340
Change-Id: Id3d2526099bc89f04d8ad3ad6e48141b2a8f2515
(cherry picked from commit a7dc1e6f99df59799ab0128d9c4e47bbeceb934d)
Signed-off-by: Hang Lu <hangl@codeaurora.org>
[cmllamas: fix trivial merge issue]
Signed-off-by: Carlos Llamas <cmllamas@google.com>
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>
(cherry picked from commit f0e3f64088)
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>
(cherry picked from commit de9f4fe6f8)
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>
(cherry picked from commit c6e7698c0c)
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>
In the config_ep_by_speed_and_alt function, select the corresponding
descriptor through g->speed. But some legacy or not well designed
function drivers may not support the corresponding speed. So, we can
directly display warnings instead of causing kernel panic. At the
same time, it indicates the reasons in warning message.
Change-Id: Ib8c979663d9f04212bcc3ef4e1c0dc5be26c6958
Reviewed-by: Peter Chen <peter.chen@kernel.org>
Signed-off-by: Qihang Hu <huqihang@oppo.com>
Link: https://lore.kernel.org/r/20211110101129.462357-1-huqihang@oppo.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mot-CRs-Fixed: (CR)
Reviewed-on: https://gerrit.mot.com/2264211
SME-Granted: SME Approvals Granted
SLTApproved: Slta Waiver
Tested-by: Jira Key
Reviewed-by: Igor Kovalenko <igork@motorola.com>
Submit-Approved: Jira Key
Currently, while parsing scan RNR Ie data is moved to
next neighbor_ap_info_field after parsing the current
neighbor_ap_info_field. But in last iteration pointer may
try to access invalid data if (uint8_t *)ie + rnr_ie_len + 2)
bytes are less than sizeof neighbor_ap_info_field and same
is the case with tbtt_length access.
Fix is to add a length check of data + next data size to be parsed
< (uint8_t *)ie + rnr_ie_len + 2) instead of adding a validation
of data length only.
CRs-Fixed: 3710080
Change-Id: I05e5a9a02f0f4f9bc468db894588e676f0a248c0
The passed in pointer in kgsl_count_hw_fences() can be a
kgsl_mem_entry pointer. This gets cross dereferenced to
a kgsl_drawobj_sync_event pointer and causes a NULL pointer
dereference. To avoid this cross dereference, decouple the two
paths and call kgsl_count_hw_fences() only in the appropriate
path.
Change-Id: I1088a0b67f1f82a20ddc94c94cbdd31a44b18da6
Signed-off-by: Harshdeep Dhatt <quic_hdhatt@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>
Since the split elf blobs will always contain the hash segment, we rely on
the blob file to get the hash rather than assume that it will be present in
the mdt file. This change uses the hash index to read the appropriate elf
blob to get the hash segment.
Change-Id: Iaf37a15f7794d417d01d9eda4a9df772623ae19c
Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
It may be that the offset of the first program header lies inside the mdt's
filesize, in this case the loader would incorrectly assume that the bins
were not split. The loading would then continue on to fail for split bins.
This change updates the logic used by the mdt loader to understand whether
the firmware images are split or not. It figures this out by checking if
each programs header's segment lies within the file or not.
Change-Id: I18ce4922eadceb96193584d829829878048ea045
Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
The assumption that the elf program header will always have the hash
segment program header at index 1 may not hold true in all cases. This
change updates the read metadata function to find the hash program header
dynamically.
Change-Id: Ic5aa0d290b24ec3273003d980fec070b9e058c4f
Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
