strset_add_str_mem() might reallocate the strset data buffer in order to
accommodate the provided string 's'. However, if 's' points to a string
already present in the buffer, it becomes dangling after the realloc.
This leads to a use-after-free when attempting to memcpy() the string
into the new buffer.
One scenario that triggers this problematic path is when resolve_btfids
attempts to patch kfunc prototypes using existing BTF parameter names:
| resolve_btfids: function bpf_list_push_back_impl already exists in BTF
| Segmentation fault (core dumped)
Compiling resolve_btfids with fsanitize=address generates a detailed
report of the UAF:
| =================================================================
| ERROR: AddressSanitizer: heap-use-after-free on address 0x7f4c4a500bd4
| ==1507892==ERROR: AddressSanitizer: heap-use-after-free on address 0x7f4c4a500bd4 at pc 0x55d25155a2a8 bp 0x7ffcef879060 sp 0x7ffcef878818
| READ of size 5 at 0x7f4c4a500bd4 thread T0
| #0 0x55d25155a2a7 in memcpy (tools/bpf/resolve_btfids/resolve_btfids+0xcf2a7)
| #1 0x55d2515d708e in strset__add_str tools/lib/bpf/strset.c:162:2
| #2 0x55d2515c730b in btf__add_str tools/lib/bpf/btf.c:2109:8
| #3 0x55d2515c9020 in btf__add_func_param tools/lib/bpf/btf.c:3108:14
| #4 0x55d25159f0b5 in process_kfunc_with_implicit_args tools/bpf/resolve_btfids/main.c:1196:9
| #5 0x55d25159e004 in btf2btf tools/bpf/resolve_btfids/main.c:1229:9
| #6 0x55d25159cee7 in main tools/bpf/resolve_btfids/main.c:1535:6
| #7 0x7f4c78e29f76 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
| #8 0x7f4c78e2a026 in __libc_start_main csu/../csu/libc-start.c:360:3
| #9 0x55d2514bb860 in _start (tools/bpf/resolve_btfids/resolve_btfids+0x30860)
|
| 0x7f4c4a500bd4 is located 13268 bytes inside of 2829000-byte region [0x7f4c4a4fd800,0x7f4c4a7b02c8)
| freed by thread T0 here:
| #0 0x55d25155b700 in realloc (tools/bpf/resolve_btfids/resolve_btfids+0xd0700)
| #1 0x55d2515c426c in libbpf_reallocarray tools/lib/bpf/./libbpf_internal.h:220:9
| #2 0x55d2515c426c in libbpf_add_mem tools/lib/bpf/btf.c:224:13
|
| previously allocated by thread T0 here:
| #0 0x55d25155b2e3 in malloc (tools/bpf/resolve_btfids/resolve_btfids+0xd02e3)
| #1 0x55d2515d6e7d in strset__new tools/lib/bpf/strset.c:58:20
While resolve_btfids could be refactored to avoid this call path, let's
instead fix this issue at the source in strset__add_str() and avoid
similar scenarios.
Let's check if set->strs_data was reallocated and whether 's' points to
an internal string within the old strset buffer. In such case, 's' is
reconstructed to point to the new buffer.
While already here, also fix strset__find_str() which suffers from the
same problem by factoring out the common operations into a new helper
function strset_str_append().
Fixes: 90d76d3ece ("libbpf: Extract internal set-of-strings datastructure APIs")
Suggested-by: Andrii Nakryiko <andrii@kernel.org>
Suggested-by: Mykyta Yatsenko <yatsenko@meta.com>
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20260523162722.2718940-1-cmllamas@google.com
Bug: 512529051
(cherry picked from commit b23705e6afb6ac4ae6d220dcb35975698667dd76)
Change-Id: I424a1d896df5134fa4abc7a0fff4c46c0c966a98
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This reverts commit 6c59ee8c14.
A newer version of this fix has landed as commit b23705e6afb6 ("libbpf:
Fix UAF in strset__add_str()") upstream. Let's switch to that instead.
Bug: 512529051
Change-Id: I732cdac57e8a7bd7272e048296fca570944e9930
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Upstream added a new backtrace-suppression kunit test module that builds
by default with CONFIG_KUNIT_TEST, so add it to the list of kunit common
modules.
Fixes: bbc960d009 ("kunit: Add backtrace suppression self-tests")
Change-Id: I954b297b363b229d7458aabb553077df5cfbe28b
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Steps on the way to v7.2-rc1
Resolves trivial merge conflicts in:
drivers/md/Kconfig
drivers/md/Makefile
Cc: Eric Biggers <ebiggers@google.com>
Change-Id: Ibbfe7df1bd9a979e5a6fe9cf1295229fe6046afa
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Steps on the way to v7.2-rc1
Resolves trivial merge conflicts in:
kernel/sched/fair.c
kernel/sched/sched.h
Cc: John Stultz <jstultz@google.com>
Change-Id: I49b142eba0e69f4a41425dae76f298c25c07dc68
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This reverts commit e1061a9371.
Upstream refactored util_est_update() in commit 6d2051403d
("sched/fair: Update util_est after updating util_avg during dequeue")
and this vendor hook needs to be refactored accordingly. Remove it now
but it can reland after the updates if really needed.
Bug: 170508405
Cc: Rick Yiu <rickyiu@google.com>
Change-Id: Ic49b4f8cd3a7de9c411b86e38e6a09fdde9c39b7
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This reverts commit 3d5bad71a7.
Upstream has removed pick_next_task_fair() in commit 5ad278dd20
("sched: Remove sched_class::pick_next_task()"), so we can't have this
hook there anymore. Plus, it doesn't seem to be critical functionality
to be in android-mainline.
Bug: 413566818
Cc: John Stultz <jstultz@google.com>
Change-Id: Ifc26a14474668f8462e1c9c94fdb969a2b76aab3
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Since commit 541c8f2468 ("dma-buf: detach fence ops on signal v3"),
I'm seeing the BUG_ON() triggering in drm_crtc's fence_to_crtc() via
drm_crtc_fence_get_driver_name() regularly:
Call trace:
panic+0x58/0x5c
die+0x160/0x178
bug_brk_handler+0x70/0xa4
call_el1_break_hook+0x3c/0x1a0
do_el1_brk64+0x24/0x74
el1_brk64+0x34/0x54
el1h_64_sync_handler+0x80/0xfc
el1h_64_sync+0x84/0x88
drm_crtc_fence_get_driver_name+0x60/0x68 (P)
sync_file_get_name+0x184/0x45c
sync_file_ioctl+0x404/0xf70
__arm64_sys_ioctl+0x124/0x1dc
This looks to be caused by a code flow similar to the following:
+++ snip +++
thread A thread B
ioctl(SYNC_IOC_FILE_INFO)
sync_file_ioctl()
sync_file_get_name()
dma_fence_signal_timestamp_locked() dma_fence_driver_name()
ops = rcu_dereference(fence->ops)
if (!dma_fence_test_signaled_flag())
ops->get_driver_name(fence) i.e.
drm_crtc_fence_get_driver_name()
test_and_set_bit(SIGNALED)
RCU_INIT_POINTER(fence->ops, NULL)
drm_crtc_fence_get_driver_name()
BUG_ON(rcu_access_pointer(fence->ops)
!= &drm_crtc_fence_ops)
+++ snap +++
In other words, a fence's ops pointer can now change to NULL on signal,
which wasn't the case before the culprit commit and hence the BUG_ON()
triggers.
Simply drop the BUG_ON() as it's usage of fence ops is invalid now, and
because using BUG_ON() and friends to take down the system is an
unacceptable way to handle a failure.
Note that the adjacent drm_crtc_fence_get_timeline_name() has the same
problem and is fixed by this patch as well.
Fixes: 541c8f2468 ("dma-buf: detach fence ops on signal v3")
Cc: stable@vger.kernel.org
Reviewed-by: Philipp Stanner <phasta@kernel.org>
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://lore.kernel.org/all/20260721-linux-drm_crtc_fix2-v3-2-afa8c71506e6@linaro.org/
Bug: 521531791
Test: TH
Change-Id: I01392d150a93846f70889920ca120ec5c8baeee4
Signed-off-by: André Draszik <draszik@google.com>
This partially reverts commit 80fa614e2f ("selftests: timers: Remove
local NSEC_PER_SEC and USEC_PER_SEC defines").
The original commit removed local definitions of NSEC_PER_SEC and
USEC_PER_SEC in favor of including <include/vdso/time64.h>. However,
NSEC_PER_SEC in vdso/time64.h is defined as 1000000000L, which is
32-bit on 32-bit architectures. This causes integer overflow warnings
in several timer tests when doing arithmetic like NSEC_PER_SEC * 10 on
32-bit systems.
To fix this, restore the local definitions of NSEC_PER_SEC and
USEC_PER_SEC in the test files, but use "LL" suffix consistently
(1000000000LL and 1000000LL) to ensure 64-bit arithmetic and avoid
overflows.
We keep the cleanup from the original commit that renamed plural
definitions (NSECS_PER_SEC/USECS_PER_SEC) to singular ones in
posix_timers.c, but we now define them locally there as well.
This also removes the dependency of the selftests on the internal
kernel header <include/vdso/time64.h>.
Signed-off-by: Wake Liu <wakel@google.com>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Acked-by: John Stultz <jstultz@google.com>
Link: https://patch.msgid.link/20260610014721.718362-1-wakel@google.com
Bug: 444295917
(cherry picked from commit f44ce7fdbdd00a596455b8689b62c12d5530d610
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core)
Change-Id: I6ff5716b95ae429fe39e40034ada78d633e12956
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This reverts commit 127c77fc4e.
Let's bring back this commit as doing so avoids conflicts with new
upstream patches such as commit b00385b8d0 ("selftests/posix_timers:
Use CLOCK_THREAD_CPUTIME_ID for ITIMER_PROF measurements") from John.
Instead of the revert, we can cherry-pick Wake's fix directly from the
tip tree [1].
Bug: 444295917
Cc: Wake Liu <wakel@google.com>
Cc: John Stultz <jstultz@google.com>
Link: https://git.kernel.org/tip/f44ce7fdbdd0 [1]
Change-Id: I5f28c56849db94c3bcb3b2669e824d2d5814b483
Signed-off-by: Carlos Llamas <cmllamas@google.com>
Consolidate TEST_MAPPING config in arch/x86 by add the config to upper
level and remove configs in subfolders.
Test: presubmit
Bug: 436349608
Change-Id: Ie5792c3dbf1a789799c55df15ab4afc761c54989
Signed-off-by: Betty Zhou <bettyzhou@google.com>
Last references were removed in http://r.android.com/3552603 and
http://r.android.com/3552602.
Since mixed-build-prefix is no longer used, we can safely remove its
definition and export.
Bug: 205893923
Test: tools/bazel build //common-modules/virtual-device:virtual_device_x86_64
Change-Id: I467d7a01648bbd079640e645e09b9f5edbdee3b3
Signed-off-by: Ulises Mendez Martinez <umendez@google.com>
Update TEST_MAPPING in common/net to be import based for majority of tests.
Test: presubmit
Bug: 436349608
Change-Id: I73df7d1b3ea3f4c373de9d0cfb386d24656c36fc
Signed-off-by: Betty Zhou <bettyzhou@google.com>
Remove TEST_MAPPING in common/drivers/ and common/kernel subfolders and consolidate the tests in upper level at common/drivers in common/kernel.
Test: presubmit
Bug: 436349608
Change-Id: I86f5e951e8bb3b702c21d68afa59e7d0620770a9
Signed-off-by: Betty Zhou <bettyzhou@google.com>
In [1], sashiko reported the following issue:
=== snip ===
Looking at how these fences are managed, drm_crtc_create_fence()
creates a dma_fence without taking a reference to the drm_device or
drm_crtc. Because the sync_file framework exposes this fence to
userspace, the fence can outlive the CRTC.
The dma_fence contract requires that data accessed by dma_fence_ops
(like get_driver_name) must remain valid for an RCU grace period after
the fence is signaled. However, drm_crtc_cleanup() and the subsequent
freeing of the device do not wait for an RCU grace period via
synchronize_rcu().
If userspace calls ioctl(SYNC_IOC_FILE_INFO) concurrently with a device
hot-unplug:
CPU1 (Userspace)
sync_file_get_name()
ops = rcu_dereference(fence->ops);
if (!dma_fence_test_signaled_flag())
// Preempted or delayed here
CPU2 (Driver Teardown)
Signals the fence (setting fence->ops = NULL)
Destroys and frees the CRTC without waiting for an RCU grace period
CPU1 (Resumes)
ops->get_driver_name(fence) -> drm_crtc_fence_get_driver_name()
crtc = fence_to_crtc(fence); // Casts to the freed CRTC
return crtc->dev->driver->name; // Use-after-free
...
Does the CRTC or DRM device need to be kept alive for the RCU grace
period, or should the fence hold a proper reference to prevent the
use-after-free when get_driver_name() and get_timeline_name() access
the freed CRTC structure?
=== snap ===
I believe this to be a correct observation and this patch implements
the suggestion of waiting for an RCU grace period before proceeding
with destruction of the drm_crtc, so that get_driver_name() and
get_timeline_name() can still work.
Link: https://sashiko.dev/#/patchset/20260618-linux-drm_crtc_fix2-v1-1-c03e77b36f34@linaro.org?part=1
Fixes: 6d6003c4b6 ("drm/fence: add fence timeline to drm_crtc")
Cc: stable@vger.kernel.org
Reviewed-by: Philipp Stanner <phasta@kernel.org>
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://lore.kernel.org/all/20260721-linux-drm_crtc_fix2-v3-1-afa8c71506e6@linaro.org/
Bug: 521531791
Test: TH
Change-Id: Ib7607bfbf5f619c8c4d19d306dff7288063177f1
Signed-off-by: André Draszik <draszik@google.com>
This reverts commit 44ee1179cb.
Upstream reverted the equivalent patch in commit c1855dd0a6 ("clk: qcom:
Revert sync_state based clk_disable_unused") after finding some issues
with this approach [1]. Also, keeping this patch creates build issues
with further upstream patches, so let's just drop it. If this is really
needed please work on landing this functionality upstream.
Bug: 535619959
Cc: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id9f47b9225b14dc8dce29394f4b55534c6c7df34
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This reverts commit ed7a77c50f.
Upstream reverted the equivalent patch in commit c1855dd0a6 ("clk: qcom:
Revert sync_state based clk_disable_unused") after finding some issues
with this approach [1]. Also, keeping this patch creates build issues
with further upstream patches, so let's just drop it. If this is really
needed please work on landing this functionality upstream.
Bug: 535619959
Cc: Greg Kroah-Hartman <gregkh@google.com>
Link: https://lore.kernel.org/all/20230222153415.5npe4axg4mupzvw4@ripper/ [1]
Change-Id: Ie8d6962080e6ddf1f7824910a69399dbfb01d245
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This reverts commit fe7d795db4.
Upstream reverted the equivalent patch in commit c1855dd0a6 ("clk: qcom:
Revert sync_state based clk_disable_unused") after finding some issues
with this approach [1]. Also, keeping this patch creates build issues
with further upstream patches, so let's just drop it. If this is really
needed please work on landing this functionality upstream.
Bug: 535619959
Cc: Greg Kroah-Hartman <gregkh@google.com>
Link: https://lore.kernel.org/all/20230222153415.5npe4axg4mupzvw4@ripper/ [1]
Change-Id: Idec2aca7f460322546766eeb68a6f48974e39705
Signed-off-by: Carlos Llamas <cmllamas@google.com>
The TEST_MAPPING in common/fs is updated to import based for majority of the tests.
Test: presubmit
Bug: 436349608
Change-Id: Ifd4db9082d01d0ef252b5c70324c92c285311fa8
Signed-off-by: Betty Zhou <bettyzhou@google.com>
Update TEST_MAPPING in common/drivers/android to be import based for most of the tests.
Signed-off-by: Betty Zhou <bettyzhou@google.com>
Test: presubmit
Bug: 436349608
Change-Id: I00f768d3efe8b50ac17624e041d7eaf9c8e100d7
* These have been recently broken by a dependency upgrade. This commit
disables them while they get fixed.
Bug: 536813037
Bug: 536732335
Bug: 536739090
Change-Id: I279fbb2ce563e3597e96ec762b26866d12b0ea22
Signed-off-by: Ulises Mendez Martinez <umendez@google.com>
This will allow mixed builds to use source-built pahole.
Bug: 477549297
Change-Id: Ibc9293bef1fa9ce4ebeb8c0ba1126e9ce0ec0713
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
This config option is not used by microdroid VMs and already has been
removed upstream.
Bug: 529833761
Test: presubmit
Change-Id: Ie89025a7b3029c16562b1d4f11e9f77f5b7b74d3
Merged-In: Ie89025a7b3029c16562b1d4f11e9f77f5b7b74d3
Signed-off-by: Nikita Ioffe <ioffe@google.com>
(cherry picked from commit 6df17ae72b6245aeb206aff24190a76cf33561c0)
The CRYPTO_LZ4 config is now implicitly selected via HIBERNATION, so
remove it from our gki_defconfig files.
Fixes: 2068d7715e ("PM: hibernate: make LZ4 available for hibernation compression")
Change-Id: Ia298ccce5f6c2bd46a767f65dc6d82a0215f965e
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This reverts commit 9bd7b75557.
It creates merge conflicts with upstream patches. Plus, it doesn't seem
to be critical functionality for it to live in android-mainline branch.
However, it can be later reapplied if really needed.
Bug: 312392542
Cc: vincent wang <vincentwang3@lenovo.com>
Change-Id: Ib2fd55877dffb8a0199862780f0f3db71526a921
Signed-off-by: Carlos Llamas <cmllamas@google.com>
This makes the kernel builds use source-built pahole.
Bug: 477549297
Change-Id: I7ceb5d5349c1e920ff996a4d629ad0d1ad53948e
Signed-off-by: Siddharth Nayyar <sidnayyar@google.com>
This reverts commit 7c4637b548.
Reason for revert: Qais raised some skepticism that the impact is as bad as earlier reported. Wants to have it still as an option to evaluate.
Bug: 458065944
Change-Id: I9ee82670e1a4802486083d987e0646ae3d447d36
Signed-off-by: John Stultz <jstultz@google.com>
CONFIG_RCU_LAZY causes RCU grace periods to be delayed, which negatively
impacts kfree_rcu() and sheaves freeing performance in SLUB allocations.
Since there is no active benefit or necessity for HZ=1000 in mainline,
disable/remove CONFIG_RCU_LAZY from gki_defconfig to prevent memory
reclamation regressions.
Bug: 458065944
Test: Verified gki_defconfig changes and RCU_LAZY removal
Change-Id: Ib30072f6f1a89a46907eda2167a366fa39139ea1
Signed-off-by: Howard Chen <howardsoc@google.com>
The sw_sync driver is useful for debugging and testing GPU drivers, and
is leveraged by several tests in the igt-gpu-tools test suite.
The driver carries a warning that it poses a risk of unsafe fence
management that can lead to userspace-initiated system deadlocks, so it
has been disabled in Android kernels to protect against this
possibility.
GMS requirements for Android 12 and newer disallow shipping devices with
debugfs mounted.
Beginning in the Android 4.9 kernel, sw_sync is only exposed through
debugfs, so enabling in newer GKI kernels for debugging and testing no
longer poses the risk to shipping builds.
Bug: 513375529
Test: tools/bazel build //common:kernel_aarch64
Test: tools/bazel build //common:kernel_x86_64
Test: adb shell ls /sys/kernel/debug/sync/sw_sync
Signed-off-by: Ryan Neph <ryanneph@google.com>
Cherrypick-From: https://android-review.googlesource.com/q/commit:f83948e947ffb1a8b1798cd576bc7d58263d9279
Merged-In: I5ab41385c9c30cdb1a4b21123eb4777c17adcb5a
Change-Id: I5ab41385c9c30cdb1a4b21123eb4777c17adcb5a
To support XL APKs, increase INCFS_MAX_HASH_AREA_SIZE from 1280 MB (1.25 GB) to 1792 MB (1.75 GB). A 1792 MB hash area supports APKs up to about 238 GB (~222 GiB), while keeping total block calculations below the 32-bit signed integer overflow boundary (2.0 GB).
Test:
Without increasing the limit:
adb install -t --incremental large_app_200gb.apk
Performing Incremental Install
Serving...
Failure [INSTALL_FAILED_MEDIA_UNAVAILABLE: Failed to add file to IncFS: large_app_200gb.apk, reason: : makeFile() failed with errno 7]
Install failed.
With the increased limit:
adb install -t --incremental large_app_200gb.apk
Performing Incremental Install
Serving...
Success
Bug: 522943057
Change-Id: I860604030438074048689c4675ea02740f0d5aa8
Signed-off-by: Sneh Saraff <snehsaraff@google.com>
Acquire bc->ranges_lock earlier in the function to protect
trimmed_list and ranges traversal against concurrent modifications.
Bug: 499160651
Change-Id: I06f034d7e9ddc024930b33216f911f7a321cafe0
Signed-off-by: Vova Sharaienko <sharaienko@google.com>
Add missing #undef TRACE_INCLUDE_PATH before #define in include/trace/hooks/sched.h to prevent -Werror,-Wmacro-redefined when multiple trace hook headers are included in the same compilation unit.
Modified files: include/trace/hooks/sched.h
Fixes: a1fc1fba46 ("ANDROID: sched: add restrict vendor hook to modify task placement policy in EAS")
Bug: 532033601
Change-Id: I4218417f58ff15aaa295ffda05ceccc8705bc448
Signed-off-by: Jiameng Li <lijiameng3@xiaomi.corp-partner.google.com>
Enable hard lockup detector.
This enables hard lockup detection in Android devices. However, we'll
only enable hardlockup_panic in desktop devices (in a separate CL).
ARM64 devices prefer to use the buddy detector in case the perf detector
isn't available.
Bug: 484396742
Test: cat /proc/sys/kernel/nmi_watchdog -> 1
echo 1 >/proc/sys/kernel/hardlockup_panic
echo HARDLOCKUP >/sys/kernel/debug/provoke-crash/DIRECT
adb shell getprop | grep reason
cat /sys/fs/pstore/console-ramoops-0
Change-Id: I12c33b998ae30b3a4dc1e168cf25e0fe4d477df5
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Carlos Llamas
Ulises Mendez Martinez
André Draszik
Wake Liu
Betty Zhou
Siddharth Nayyar
Nikita Ioffe
John Stultz
Howard Chen
Ryan Neph
Sneh Saraff
Vova Sharaienko
Jiameng Li
Tzung-Bi Shih