Prevent Zygisk/KernelSU detection through common methods #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
itsHanibee
approved these changes
Dec 23, 2023
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
[ Upstream commit 0c8b0bf42c8cef56f7cd9cd876fbb7ece9217064 ]
The kunit tests discovered a sleeping in atomic bug. The allocations
in the regcache-rbtree code should use the map->alloc_flags instead of
GFP_KERNEL.
[ 5.005510] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306
[ 5.005960] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 117, name: kunit_try_catch
[ 5.006219] preempt_count: 1, expected: 0
[ 5.006414] 1 lock held by kunit_try_catch/117:
[ 5.006590] #0: 833b9010 (regmap_kunit:86:(config)->lock){....}-{2:2}, at: regmap_lock_spinlock+0x14/0x1c
[ 5.007493] irq event stamp: 162
[ 5.007627] hardirqs last enabled at (161): [<80786738>] crng_make_state+0x1a0/0x294
[ 5.007871] hardirqs last disabled at (162): [<80c531ec>] _raw_spin_lock_irqsave+0x7c/0x80
[ 5.008119] softirqs last enabled at (0): [<801110ac>] copy_process+0x810/0x2138
[ 5.008356] softirqs last disabled at (0): [<00000000>] 0x0
[ 5.008688] CPU: 0 PID: 117 Comm: kunit_try_catch Tainted: G N 6.4.4-rc3-g0e8d2fdfb188 #1
[ 5.009011] Hardware name: Generic DT based system
[ 5.009277] unwind_backtrace from show_stack+0x18/0x1c
[ 5.009497] show_stack from dump_stack_lvl+0x38/0x5c
[ 5.009676] dump_stack_lvl from __might_resched+0x188/0x2d0
[ 5.009860] __might_resched from __kmem_cache_alloc_node+0x1dc/0x25c
[ 5.010061] __kmem_cache_alloc_node from kmalloc_trace+0x30/0xc8
[ 5.010254] kmalloc_trace from regcache_rbtree_write+0x26c/0x468
[ 5.010446] regcache_rbtree_write from _regmap_write+0x88/0x140
[ 5.010634] _regmap_write from regmap_write+0x44/0x68
[ 5.010803] regmap_write from basic_read_write+0x8c/0x270
[ 5.010980] basic_read_write from kunit_try_run_case+0x48/0xa0
Fixes: 28644c8 ("regmap: Add the rbtree cache support")
Reported-by: Guenter Roeck <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Dan Carpenter <[email protected]>
Tested-by: Guenter Roeck <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
[ Upstream commit c2f8fd7949603efb03908e05abbf7726748c8de3 ]
syzkaller reported null-ptr-deref [0] related to AF_NETROM.
This is another self-accept issue from the strace log. [1]
syz-executor creates an AF_NETROM socket and calls connect(), which
is blocked at that time. Then, sk->sk_state is TCP_SYN_SENT and
sock->state is SS_CONNECTING.
[pid 5059] socket(AF_NETROM, SOCK_SEQPACKET, 0) = 4
[pid 5059] connect(4, {sa_family=AF_NETROM, sa_data="..." <unfinished ...>
Another thread calls connect() concurrently, which finally fails
with -EINVAL. However, the problem here is the socket state is
reset even while the first connect() is blocked.
[pid 5060] connect(4, NULL, 0 <unfinished ...>
[pid 5060] <... connect resumed>) = -1 EINVAL (Invalid argument)
As sk->state is TCP_CLOSE and sock->state is SS_UNCONNECTED, the
following listen() succeeds. Then, the first connect() looks up
itself as a listener and puts skb into the queue with skb->sk itself.
As a result, the next accept() gets another FD of itself as 3, and
the first connect() finishes.
[pid 5060] listen(4, 0 <unfinished ...>
[pid 5060] <... listen resumed>) = 0
[pid 5060] accept(4, NULL, NULL <unfinished ...>
[pid 5060] <... accept resumed>) = 3
[pid 5059] <... connect resumed>) = 0
Then, accept4() is called but blocked, which causes the general protection
fault later.
[pid 5059] accept4(4, NULL, 0x20000400, SOCK_NONBLOCK <unfinished ...>
After that, another self-accept occurs by accept() and writev().
[pid 5060] accept(4, NULL, NULL <unfinished ...>
[pid 5061] writev(3, [{iov_base=...}] <unfinished ...>
[pid 5061] <... writev resumed>) = 99
[pid 5060] <... accept resumed>) = 6
Finally, the leader thread close()s all FDs. Since the three FDs
reference the same socket, nr_release() does the cleanup for it
three times, and the remaining accept4() causes the following fault.
[pid 5058] close(3) = 0
[pid 5058] close(4) = 0
[pid 5058] close(5) = -1 EBADF (Bad file descriptor)
[pid 5058] close(6) = 0
[pid 5058] <... exit_group resumed>) = ?
[ 83.456055][ T5059] general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
To avoid the issue, we need to return an error for connect() if
another connect() is in progress, as done in __inet_stream_connect().
[0]:
general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
CPU: 0 PID: 5059 Comm: syz-executor.0 Not tainted 6.5.0-rc5-syzkaller-00194-gace0ab3a4b54 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
RIP: 0010:__lock_acquire+0x109/0x5de0 kernel/locking/lockdep.c:5012
Code: 45 85 c9 0f 84 cc 0e 00 00 44 8b 05 11 6e 23 0b 45 85 c0 0f 84 be 0d 00 00 48 ba 00 00 00 00 00 fc ff df 4c 89 d1 48 c1 e9 03 <80> 3c 11 00 0f 85 e8 40 00 00 49 81 3a a0 69 48 90 0f 84 96 0d 00
RSP: 0018:ffffc90003d6f9e0 EFLAGS: 00010006
RAX: ffff8880244c8000 RBX: 1ffff920007adf6c RCX: 0000000000000003
RDX: dffffc0000000000 RSI: 0000000000000000 RDI: 0000000000000018
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000018 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS: 00007f51d519a6c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f51d5158d58 CR3: 000000002943f000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
lock_acquire kernel/locking/lockdep.c:5761 [inline]
lock_acquire+0x1ae/0x510 kernel/locking/lockdep.c:5726
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x3a/0x50 kernel/locking/spinlock.c:162
prepare_to_wait+0x47/0x380 kernel/sched/wait.c:269
nr_accept+0x20d/0x650 net/netrom/af_netrom.c:798
do_accept+0x3a6/0x570 net/socket.c:1872
__sys_accept4_file net/socket.c:1913 [inline]
__sys_accept4+0x99/0x120 net/socket.c:1943
__do_sys_accept4 net/socket.c:1954 [inline]
__se_sys_accept4 net/socket.c:1951 [inline]
__x64_sys_accept4+0x96/0x100 net/socket.c:1951
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f51d447cae9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f51d519a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000120
RAX: ffffffffffffffda RBX: 00007f51d459bf80 RCX: 00007f51d447cae9
RDX: 0000000020000400 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 00007f51d44c847a R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000800 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007f51d459bf80 R15: 00007ffc25c34e48
</TASK>
Link: https://syzkaller.appspot.com/text?tag=CrashLog&x=152cdb63a80000 [1]
Fixes: 1da177e ("Linux-2.6.12-rc2")
Reported-by: [email protected]
Closes: https://syzkaller.appspot.com/bug?extid=666c97e4686410e79649
Signed-off-by: Kuniyuki Iwashima <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
[ Upstream commit dfe261107c080709459c32695847eec96238852b ]
Commit: 699826f4e30a ("IB/isert: Fix incorrect release of isert connection") is
causing problems on OPA when DEVICE_REMOVAL is happening.
------------[ cut here ]------------
WARNING: CPU: 52 PID: 2117247 at drivers/infiniband/core/cq.c:359
ib_cq_pool_cleanup+0xac/0xb0 [ib_core]
Modules linked in: nfsd nfs_acl target_core_user uio tcm_fc libfc
scsi_transport_fc tcm_loop target_core_pscsi target_core_iblock target_core_file
rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs
rfkill rpcrdma rdma_ucm ib_srpt sunrpc ib_isert iscsi_target_mod target_core_mod
opa_vnic ib_iser libiscsi ib_umad scsi_transport_iscsi rdma_cm ib_ipoib iw_cm
ib_cm hfi1(-) rdmavt ib_uverbs intel_rapl_msr intel_rapl_common sb_edac ib_core
x86_pkg_temp_thermal intel_powerclamp coretemp i2c_i801 mxm_wmi rapl iTCO_wdt
ipmi_si iTCO_vendor_support mei_me ipmi_devintf mei intel_cstate ioatdma
intel_uncore i2c_smbus joydev pcspkr lpc_ich ipmi_msghandler acpi_power_meter
acpi_pad xfs libcrc32c sr_mod sd_mod cdrom t10_pi sg crct10dif_pclmul
crc32_pclmul crc32c_intel drm_kms_helper drm_shmem_helper ahci libahci
ghash_clmulni_intel igb drm libata dca i2c_algo_bit wmi fuse
CPU: 52 PID: 2117247 Comm: modprobe Not tainted 6.5.0-rc1+ #1
Hardware name: Intel Corporation S2600CWR/S2600CW, BIOS
SE5C610.86B.01.01.0014.121820151719 12/18/2015
RIP: 0010:ib_cq_pool_cleanup+0xac/0xb0 [ib_core]
Code: ff 48 8b 43 40 48 8d 7b 40 48 83 e8 40 4c 39 e7 75 b3 49 83
c4 10 4d 39 fc 75 94 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc <0f> 0b eb a1
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f
RSP: 0018:ffffc10bea13fc80 EFLAGS: 00010206
RAX: 000000000000010c RBX: ffff9bf5c7e66c00 RCX: 000000008020001d
RDX: 000000008020001e RSI: fffff175221f9900 RDI: ffff9bf5c7e67640
RBP: ffff9bf5c7e67600 R08: ffff9bf5c7e64400 R09: 000000008020001d
R10: 0000000040000000 R11: 0000000000000000 R12: ffff9bee4b1e8a18
R13: dead000000000122 R14: dead000000000100 R15: ffff9bee4b1e8a38
FS: 00007ff1e6d38740(0000) GS:ffff9bfd9fb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005652044ecc68 CR3: 0000000889b5c005 CR4: 00000000001706e0
Call Trace:
<TASK>
? __warn+0x80/0x130
? ib_cq_pool_cleanup+0xac/0xb0 [ib_core]
? report_bug+0x195/0x1a0
? handle_bug+0x3c/0x70
? exc_invalid_op+0x14/0x70
? asm_exc_invalid_op+0x16/0x20
? ib_cq_pool_cleanup+0xac/0xb0 [ib_core]
disable_device+0x9d/0x160 [ib_core]
__ib_unregister_device+0x42/0xb0 [ib_core]
ib_unregister_device+0x22/0x30 [ib_core]
rvt_unregister_device+0x20/0x90 [rdmavt]
hfi1_unregister_ib_device+0x16/0xf0 [hfi1]
remove_one+0x55/0x1a0 [hfi1]
pci_device_remove+0x36/0xa0
device_release_driver_internal+0x193/0x200
driver_detach+0x44/0x90
bus_remove_driver+0x69/0xf0
pci_unregister_driver+0x2a/0xb0
hfi1_mod_cleanup+0xc/0x3c [hfi1]
__do_sys_delete_module.constprop.0+0x17a/0x2f0
? exit_to_user_mode_prepare+0xc4/0xd0
? syscall_trace_enter.constprop.0+0x126/0x1a0
do_syscall_64+0x5c/0x90
? syscall_exit_to_user_mode+0x12/0x30
? do_syscall_64+0x69/0x90
? syscall_exit_work+0x103/0x130
? syscall_exit_to_user_mode+0x12/0x30
? do_syscall_64+0x69/0x90
? exc_page_fault+0x65/0x150
entry_SYSCALL_64_after_hwframe+0x6e/0xd8
RIP: 0033:0x7ff1e643f5ab
Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48 83 c8 ff c3
66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0
ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89 01 48
RSP: 002b:00007ffec9103cc8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
RAX: ffffffffffffffda RBX: 00005615267fdc50 RCX: 00007ff1e643f5ab
RDX: 0000000000000000 RSI: 0000000000000800 RDI: 00005615267fdcb8
RBP: 00005615267fdc50 R08: 0000000000000000 R09: 0000000000000000
R10: 00007ff1e659eac0 R11: 0000000000000206 R12: 00005615267fdcb8
R13: 0000000000000000 R14: 00005615267fdcb8 R15: 00007ffec9105ff8
</TASK>
---[ end trace 0000000000000000 ]---
And...
restrack: ------------[ cut here ]------------
infiniband hfi1_0: BUG: RESTRACK detected leak of resources
restrack: Kernel PD object allocated by ib_isert is not freed
restrack: Kernel CQ object allocated by ib_core is not freed
restrack: Kernel QP object allocated by rdma_cm is not freed
restrack: ------------[ cut here ]------------
Fixes: 699826f4e30a ("IB/isert: Fix incorrect release of isert connection")
Reported-by: Dennis Dalessandro <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]
Link: https://lore.kernel.org/r/a27982d3235005c58f6d321f3fad5eb6e1beaf9e.1692604607.git.leonro@nvidia.com
Tested-by: Dennis Dalessandro <[email protected]>
Signed-off-by: Leon Romanovsky <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
[ Upstream commit f4f8a7803119005e87b716874bec07c751efafec ] The opt_num field is controlled by user mode and is not currently validated inside the kernel. An attacker can take advantage of this to trigger an OOB read and potentially leak information. BUG: KASAN: slab-out-of-bounds in nf_osf_match_one+0xbed/0xd10 net/netfilter/nfnetlink_osf.c:88 Read of size 2 at addr ffff88804bc64272 by task poc/6431 CPU: 1 PID: 6431 Comm: poc Not tainted 6.0.0-rc4 #1 Call Trace: nf_osf_match_one+0xbed/0xd10 net/netfilter/nfnetlink_osf.c:88 nf_osf_find+0x186/0x2f0 net/netfilter/nfnetlink_osf.c:281 nft_osf_eval+0x37f/0x590 net/netfilter/nft_osf.c:47 expr_call_ops_eval net/netfilter/nf_tables_core.c:214 nft_do_chain+0x2b0/0x1490 net/netfilter/nf_tables_core.c:264 nft_do_chain_ipv4+0x17c/0x1f0 net/netfilter/nft_chain_filter.c:23 [..] Also add validation to genre, subtype and version fields. Fixes: 11eeef4 ("netfilter: passive OS fingerprint xtables match") Reported-by: Lucas Leong <[email protected]> Signed-off-by: Wander Lairson Costa <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
… delayed items
commit e110f8911ddb93e6f55da14ccbbe705397b30d0b upstream.
When running delayed items we are holding a delayed node's mutex and then
we will attempt to modify a subvolume btree to insert/update/delete the
delayed items. However if have an error during the insertions for example,
btrfs_insert_delayed_items() may return with a path that has locked extent
buffers (a leaf at the very least), and then we attempt to release the
delayed node at __btrfs_run_delayed_items(), which requires taking the
delayed node's mutex, causing an ABBA type of deadlock. This was reported
by syzbot and the lockdep splat is the following:
WARNING: possible circular locking dependency detected
6.5.0-rc7-syzkaller-00024-g93f5de5f648d #0 Not tainted
------------------------------------------------------
syz-executor.2/13257 is trying to acquire lock:
ffff88801835c0c0 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256
but task is already holding lock:
ffff88802a5ab8e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_lock+0x3c/0x2a0 fs/btrfs/locking.c:198
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (btrfs-tree-00){++++}-{3:3}:
__lock_release kernel/locking/lockdep.c:5475 [inline]
lock_release+0x36f/0x9d0 kernel/locking/lockdep.c:5781
up_write+0x79/0x580 kernel/locking/rwsem.c:1625
btrfs_tree_unlock_rw fs/btrfs/locking.h:189 [inline]
btrfs_unlock_up_safe+0x179/0x3b0 fs/btrfs/locking.c:239
search_leaf fs/btrfs/ctree.c:1986 [inline]
btrfs_search_slot+0x2511/0x2f80 fs/btrfs/ctree.c:2230
btrfs_insert_empty_items+0x9c/0x180 fs/btrfs/ctree.c:4376
btrfs_insert_delayed_item fs/btrfs/delayed-inode.c:746 [inline]
btrfs_insert_delayed_items fs/btrfs/delayed-inode.c:824 [inline]
__btrfs_commit_inode_delayed_items+0xd24/0x2410 fs/btrfs/delayed-inode.c:1111
__btrfs_run_delayed_items+0x1db/0x430 fs/btrfs/delayed-inode.c:1153
flush_space+0x269/0xe70 fs/btrfs/space-info.c:723
btrfs_async_reclaim_metadata_space+0x106/0x350 fs/btrfs/space-info.c:1078
process_one_work+0x92c/0x12c0 kernel/workqueue.c:2600
worker_thread+0xa63/0x1210 kernel/workqueue.c:2751
kthread+0x2b8/0x350 kernel/kthread.c:389
ret_from_fork+0x2e/0x60 arch/x86/kernel/process.c:145
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
-> #0 (&delayed_node->mutex){+.+.}-{3:3}:
check_prev_add kernel/locking/lockdep.c:3142 [inline]
check_prevs_add kernel/locking/lockdep.c:3261 [inline]
validate_chain kernel/locking/lockdep.c:3876 [inline]
__lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144
lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761
__mutex_lock_common+0x1d8/0x2530 kernel/locking/mutex.c:603
__mutex_lock kernel/locking/mutex.c:747 [inline]
mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:799
__btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256
btrfs_release_delayed_node fs/btrfs/delayed-inode.c:281 [inline]
__btrfs_run_delayed_items+0x2b5/0x430 fs/btrfs/delayed-inode.c:1156
btrfs_commit_transaction+0x859/0x2ff0 fs/btrfs/transaction.c:2276
btrfs_sync_file+0xf56/0x1330 fs/btrfs/file.c:1988
vfs_fsync_range fs/sync.c:188 [inline]
vfs_fsync fs/sync.c:202 [inline]
do_fsync fs/sync.c:212 [inline]
__do_sys_fsync fs/sync.c:220 [inline]
__se_sys_fsync fs/sync.c:218 [inline]
__x64_sys_fsync+0x196/0x1e0 fs/sync.c:218
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(btrfs-tree-00);
lock(&delayed_node->mutex);
lock(btrfs-tree-00);
lock(&delayed_node->mutex);
*** DEADLOCK ***
3 locks held by syz-executor.2/13257:
#0: ffff88802c1ee370 (btrfs_trans_num_writers){++++}-{0:0}, at: spin_unlock include/linux/spinlock.h:391 [inline]
#0: ffff88802c1ee370 (btrfs_trans_num_writers){++++}-{0:0}, at: join_transaction+0xb87/0xe00 fs/btrfs/transaction.c:287
#1: ffff88802c1ee398 (btrfs_trans_num_extwriters){++++}-{0:0}, at: join_transaction+0xbb2/0xe00 fs/btrfs/transaction.c:288
#2: ffff88802a5ab8e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_lock+0x3c/0x2a0 fs/btrfs/locking.c:198
stack backtrace:
CPU: 0 PID: 13257 Comm: syz-executor.2 Not tainted 6.5.0-rc7-syzkaller-00024-g93f5de5f648d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
check_noncircular+0x375/0x4a0 kernel/locking/lockdep.c:2195
check_prev_add kernel/locking/lockdep.c:3142 [inline]
check_prevs_add kernel/locking/lockdep.c:3261 [inline]
validate_chain kernel/locking/lockdep.c:3876 [inline]
__lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144
lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761
__mutex_lock_common+0x1d8/0x2530 kernel/locking/mutex.c:603
__mutex_lock kernel/locking/mutex.c:747 [inline]
mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:799
__btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256
btrfs_release_delayed_node fs/btrfs/delayed-inode.c:281 [inline]
__btrfs_run_delayed_items+0x2b5/0x430 fs/btrfs/delayed-inode.c:1156
btrfs_commit_transaction+0x859/0x2ff0 fs/btrfs/transaction.c:2276
btrfs_sync_file+0xf56/0x1330 fs/btrfs/file.c:1988
vfs_fsync_range fs/sync.c:188 [inline]
vfs_fsync fs/sync.c:202 [inline]
do_fsync fs/sync.c:212 [inline]
__do_sys_fsync fs/sync.c:220 [inline]
__se_sys_fsync fs/sync.c:218 [inline]
__x64_sys_fsync+0x196/0x1e0 fs/sync.c:218
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f3ad047cae9
Code: 28 00 00 00 75 (...)
RSP: 002b:00007f3ad12510c8 EFLAGS: 00000246 ORIG_RAX: 000000000000004a
RAX: ffffffffffffffda RBX: 00007f3ad059bf80 RCX: 00007f3ad047cae9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000005
RBP: 00007f3ad04c847a R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007f3ad059bf80 R15: 00007ffe56af92f8
</TASK>
------------[ cut here ]------------
Fix this by releasing the path before releasing the delayed node in the
error path at __btrfs_run_delayed_items().
Reported-by: [email protected]
Link: https://lore.kernel.org/linux-btrfs/[email protected]/
CC: [email protected] # 4.14+
Signed-off-by: Filipe Manana <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
This reverts commit 839f4e8 As of the commit 839f4e8 ("ALSA: jack: Fix mutex call in snd_jack_report()"), the change was introduced in order to fix commit c093b62 ("ALSA: jack: Access input_dev under mutex") which was later on reverted in commit 9508bec ("Revert "ALSA: jack: Access input_dev under mutex"") as of reason that it broke kernel ABI and is not relevant for Android system. Furthermore, this mismerge also lead to following null pointer dereference in certain scenarios like plugging in 3.5mm headset. [ 1142.234701] Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 [ 1142.234720] Mem abort info: [ 1142.234729] ESR = 0x96000005 [ 1142.234739] Exception class = DABT (current EL), IL = 32 bits [ 1142.234747] SET = 0, FnV = 0 [ 1142.234755] EA = 0, S1PTW = 0 [ 1142.234762] Data abort info: [ 1142.234770] ISV = 0, ISS = 0x00000005 [ 1142.234778] CM = 0, WnR = 0 [ 1142.234790] user pgtable: 4k pages, 39-bit VAs, pgdp = 0000000016d049a1 [ 1142.234799] [0000000000000028] pgd=00000000eb5a7003, pud=00000000eb5a7003, pmd=0000000000000000 [ 1142.234817] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 1142.234828] Modules linked in: [ 1142.234839] Process kworker/5:0 (pid: 5915, stack limit = 0x000000000ffb215a) [ 1142.234853] CPU: 5 PID: 5915 Comm: kworker/5:0 Tainted: G W 4.19.294-Mi8937v2-gb3b17955ff52 #1 [ 1142.234862] Hardware name: Qualcomm Technologies, Inc. MSM8940-PMI8937 MTP (DT) [ 1142.234886] Workqueue: events wcd_correct_swch_plug [ 1142.234899] pstate: 80400005 (Nzcv daif +PAN -UAO) [ 1142.234914] pc : input_event+0x2c/0x84 [ 1142.234929] lr : snd_jack_report+0xc4/0x17c [ 1142.234937] sp : ffffff801c07bbe0 [ 1142.234945] x29: ffffff801c07bbe0 x28: 0000000000000402 [ 1142.234957] x27: ffffff800a110028 x26: ffffffc0d2e92480 [ 1142.234969] x25: ffffffc0cb9b32c0 x24: ffffff800a46f398 [ 1142.234981] x23: ffffff800a110028 x22: 0000000000000000 [ 1142.234992] x21: 0000000000000005 x20: 000000000000000c [ 1142.235004] x19: ffffffc0cb9da400 x18: 0000000005f5e100 [ 1142.235015] x17: 0000000000000000 x16: 0000000000000000 [ 1142.235026] x15: ffffffffff21d823 x14: 0000000001312d00 [ 1142.235038] x13: 0000000000000000 x12: 0000000038e38e39 [ 1142.235049] x11: 0000000000000000 x10: 0000000000000003 [ 1142.235060] x9 : ffffff800a4ce000 x8 : 0000000000000000 [ 1142.235072] x7 : 0000000000000001 x6 : ffffffc0ef490a83 [ 1142.235083] x5 : 0000000000000001 x4 : 0000000000000001 [ 1142.235094] x3 : 0000000000000000 x2 : 0000000000000002 [ 1142.235105] x1 : 0000000000000005 x0 : 0000000000000000 [ 1142.235117] Call trace: [ 1142.235128] input_event+0x2c/0x84 [ 1142.235140] snd_jack_report+0xc4/0x17c [ 1142.235152] snd_soc_jack_report+0x1ec/0x21c [ 1142.235164] wcd_mbhc_report_plug+0x414/0x6f4 [ 1142.235176] wcd_mbhc_find_plug_and_report+0xcc/0x27c [ 1142.235188] wcd_correct_swch_plug+0x198/0xbf0 [ 1142.235203] process_one_work+0x224/0x3ec [ 1142.235215] worker_thread+0x260/0x4a8 [ 1142.235227] kthread+0x138/0x154 [ 1142.235239] ret_from_fork+0x10/0x18 [ 1142.235254] Code: 53067c28 2a0103f5 aa0003f6 8b284c08 (f9401508) [ 1142.235265] ---[ end trace 98bff2bd0de72df6 ]--- [ 1142.328772] Kernel panic - not syncing: Fatal exception Bug: 304056831 Co-authored-by: Hridaya Prajapati <[email protected]> Signed-off-by: Hridaya Prajapati <[email protected]> Signed-off-by: Yumi Yukimura <[email protected]> Change-Id: I146cf474603681243c62672491aaf3c5187551d7
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
[ Upstream commit a154f5f643c6ecddd44847217a7a3845b4350003 ] The following call trace shows a deadlock issue due to recursive locking of mutex "device_mutex". First lock acquire is in target_for_each_device() and second in target_free_device(). PID: 148266 TASK: ffff8be21ffb5d00 CPU: 10 COMMAND: "iscsi_ttx" #0 [ffffa2bfc9ec3b18] __schedule at ffffffffa8060e7f #1 [ffffa2bfc9ec3ba0] schedule at ffffffffa8061224 #2 [ffffa2bfc9ec3bb8] schedule_preempt_disabled at ffffffffa80615ee #3 [ffffa2bfc9ec3bc8] __mutex_lock at ffffffffa8062fd7 #4 [ffffa2bfc9ec3c40] __mutex_lock_slowpath at ffffffffa80631d3 #5 [ffffa2bfc9ec3c50] mutex_lock at ffffffffa806320c #6 [ffffa2bfc9ec3c68] target_free_device at ffffffffc0935998 [target_core_mod] #7 [ffffa2bfc9ec3c90] target_core_dev_release at ffffffffc092f975 [target_core_mod] #8 [ffffa2bfc9ec3ca0] config_item_put at ffffffffa79d250f #9 [ffffa2bfc9ec3cd0] config_item_put at ffffffffa79d2583 #10 [ffffa2bfc9ec3ce0] target_devices_idr_iter at ffffffffc0933f3a [target_core_mod] #11 [ffffa2bfc9ec3d00] idr_for_each at ffffffffa803f6fc #12 [ffffa2bfc9ec3d60] target_for_each_device at ffffffffc0935670 [target_core_mod] #13 [ffffa2bfc9ec3d98] transport_deregister_session at ffffffffc0946408 [target_core_mod] #14 [ffffa2bfc9ec3dc8] iscsit_close_session at ffffffffc09a44a6 [iscsi_target_mod] #15 [ffffa2bfc9ec3df0] iscsit_close_connection at ffffffffc09a4a88 [iscsi_target_mod] #16 [ffffa2bfc9ec3df8] finish_task_switch at ffffffffa76e5d07 #17 [ffffa2bfc9ec3e78] iscsit_take_action_for_connection_exit at ffffffffc0991c23 [iscsi_target_mod] #18 [ffffa2bfc9ec3ea0] iscsi_target_tx_thread at ffffffffc09a403b [iscsi_target_mod] #19 [ffffa2bfc9ec3f08] kthread at ffffffffa76d8080 #20 [ffffa2bfc9ec3f50] ret_from_fork at ffffffffa8200364 Fixes: 36d4cb4 ("scsi: target: Avoid that EXTENDED COPY commands trigger lock inversion") Signed-off-by: Junxiao Bi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
commit 3061b6491f491197a35e14e49f805d661b02acd4 upstream. For ARM processor, unaligned access to device memory is not allowed. Method memcpy does not take care of alignment. USB detection failure with the unalingned address of memory, with below kernel crash. To fix the unalingned address kernel panic, replace memcpy with memcpy_toio method. Kernel crash: Unable to handle kernel paging request at virtual address ffff80000c05008a Mem abort info: ESR = 0x96000061 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x21: alignment fault Data abort info: ISV = 0, ISS = 0x00000061 CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp=000000000143b000 [ffff80000c05008a] pgd=100000087ffff003, p4d=100000087ffff003, pud=100000087fffe003, pmd=1000000800bcc003, pte=00680000a0010713 Internal error: Oops: 96000061 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.19-xilinx-v2022.1 #1 Hardware name: ZynqMP ZCU102 Rev1.0 (DT) pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __memcpy+0x30/0x260 lr : __xudc_ep0_queue+0xf0/0x110 sp : ffff800008003d00 x29: ffff800008003d00 x28: ffff800009474e80 x27: 00000000000000a0 x26: 0000000000000100 x25: 0000000000000012 x24: ffff000800bc8080 x23: 0000000000000001 x22: 0000000000000012 x21: ffff000800bc8080 x20: 0000000000000012 x19: ffff000800bc8080 x18: 0000000000000000 x17: ffff800876482000 x16: ffff800008004000 x15: 0000000000004000 x14: 00001f09785d0400 x13: 0103020101005567 x12: 0781400000000200 x11: 00000000c5672a10 x10: 00000000000008d0 x9 : ffff800009463cf0 x8 : ffff8000094757b0 x7 : 0201010055670781 x6 : 4000000002000112 x5 : ffff80000c05009a x4 : ffff000800a15012 x3 : ffff00080362ad80 x2 : 0000000000000012 x1 : ffff000800a15000 x0 : ffff80000c050088 Call trace: __memcpy+0x30/0x260 xudc_ep0_queue+0x3c/0x60 usb_ep_queue+0x38/0x44 composite_ep0_queue.constprop.0+0x2c/0xc0 composite_setup+0x8d0/0x185c configfs_composite_setup+0x74/0xb0 xudc_irq+0x570/0xa40 __handle_irq_event_percpu+0x58/0x170 handle_irq_event+0x60/0x120 handle_fasteoi_irq+0xc0/0x220 handle_domain_irq+0x60/0x90 gic_handle_irq+0x74/0xa0 call_on_irq_stack+0x2c/0x60 do_interrupt_handler+0x54/0x60 el1_interrupt+0x30/0x50 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x78/0x7c arch_cpu_idle+0x18/0x2c do_idle+0xdc/0x15c cpu_startup_entry+0x28/0x60 rest_init+0xc8/0xe0 arch_call_rest_init+0x10/0x1c start_kernel+0x694/0x6d4 __primary_switched+0xa4/0xac Fixes: 1f7c516 ("usb: gadget: Add xilinx usb2 device support") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Cc: [email protected] Signed-off-by: Piyush Mehta <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
commit f74a7afc224acd5e922c7a2e52244d891bbe44ee upstream. Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup. Signed-off-by: Ricardo Cañuelo <[email protected]> Cc: stable <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
commit 3d887d512494d678b17c57b835c32f4e48d34f26 upstream. As drm_dp_get_mst_branch_device_by_guid() is called from drm_dp_get_mst_branch_device_by_guid(), mstb parameter has to be checked, otherwise NULL dereference may occur in the call to the memcpy() and cause following: [12579.365869] BUG: kernel NULL pointer dereference, address: 0000000000000049 [12579.365878] #PF: supervisor read access in kernel mode [12579.365880] #PF: error_code(0x0000) - not-present page [12579.365882] PGD 0 P4D 0 [12579.365887] Oops: 0000 [#1] PREEMPT SMP NOPTI ... [12579.365895] Workqueue: events_long drm_dp_mst_up_req_work [12579.365899] RIP: 0010:memcmp+0xb/0x29 [12579.365921] Call Trace: [12579.365927] get_mst_branch_device_by_guid_helper+0x22/0x64 [12579.365930] drm_dp_mst_up_req_work+0x137/0x416 [12579.365933] process_one_work+0x1d0/0x419 [12579.365935] worker_thread+0x11a/0x289 [12579.365938] kthread+0x13e/0x14f [12579.365941] ? process_one_work+0x419/0x419 [12579.365943] ? kthread_blkcg+0x31/0x31 [12579.365946] ret_from_fork+0x1f/0x30 As get_mst_branch_device_by_guid_helper() is recursive, moving condition to the first line allow to remove a similar one for step over of NULL elements inside a loop. Fixes: 5e93b82 ("drm/dp/mst: move GUID storage from mgr, port to only mst branch") Cc: <[email protected]> # 4.14+ Signed-off-by: Lukasz Majczak <[email protected]> Reviewed-by: Radoslaw Biernacki <[email protected]> Signed-off-by: Manasi Navare <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
commit 6c2f421174273de8f83cde4286d1c076d43a2d35 upstream.
Several core drivers and buses expect that driver_override is a
dynamically allocated memory thus later they can kfree() it.
However such assumption is not documented, there were in the past and
there are already users setting it to a string literal. This leads to
kfree() of static memory during device release (e.g. in error paths or
during unbind):
kernel BUG at ../mm/slub.c:3960!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
...
(kfree) from [<c058da50>] (platform_device_release+0x88/0xb4)
(platform_device_release) from [<c0585be0>] (device_release+0x2c/0x90)
(device_release) from [<c0a69050>] (kobject_put+0xec/0x20c)
(kobject_put) from [<c0f2f120>] (exynos5_clk_probe+0x154/0x18c)
(exynos5_clk_probe) from [<c058de70>] (platform_drv_probe+0x6c/0xa4)
(platform_drv_probe) from [<c058b7ac>] (really_probe+0x280/0x414)
(really_probe) from [<c058baf4>] (driver_probe_device+0x78/0x1c4)
(driver_probe_device) from [<c0589854>] (bus_for_each_drv+0x74/0xb8)
(bus_for_each_drv) from [<c058b48c>] (__device_attach+0xd4/0x16c)
(__device_attach) from [<c058a638>] (bus_probe_device+0x88/0x90)
(bus_probe_device) from [<c05871fc>] (device_add+0x3dc/0x62c)
(device_add) from [<c075ff10>] (of_platform_device_create_pdata+0x94/0xbc)
(of_platform_device_create_pdata) from [<c07600ec>] (of_platform_bus_create+0x1a8/0x4fc)
(of_platform_bus_create) from [<c0760150>] (of_platform_bus_create+0x20c/0x4fc)
(of_platform_bus_create) from [<c07605f0>] (of_platform_populate+0x84/0x118)
(of_platform_populate) from [<c0f3c964>] (of_platform_default_populate_init+0xa0/0xb8)
(of_platform_default_populate_init) from [<c01031f8>] (do_one_initcall+0x8c/0x404)
Provide a helper which clearly documents the usage of driver_override.
This will allow later to reuse the helper and reduce the amount of
duplicated code.
Convert the platform driver to use a new helper and make the
driver_override field const char (it is not modified by the core).
Reviewed-by: Rafael J. Wysocki <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
[ Upstream commit 5104fdf50d326db2c1a994f8b35dcd46e63ae4ad ] In certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log: 1. Navigate to the directory: /sys/kernel/debug/dri/0 2. Execute command: cat amdgpu_regs_smc 3. Exception Log:: [4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000 [4005007.702562] #PF: supervisor instruction fetch in kernel mode [4005007.702567] #PF: error_code(0x0010) - not-present page [4005007.702570] PGD 0 P4D 0 [4005007.702576] Oops: 0010 [#1] SMP NOPTI [4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G OE 5.15.0-43-generic #46-Ubunt u [4005007.702590] RIP: 0010:0x0 [4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. [4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206 [4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68 [4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000 [4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980 [4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000 [4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000 [4005007.702622] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000 [4005007.702626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0 [4005007.702633] Call Trace: [4005007.702636] <TASK> [4005007.702640] amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu] [4005007.703002] full_proxy_read+0x5c/0x80 [4005007.703011] vfs_read+0x9f/0x1a0 [4005007.703019] ksys_read+0x67/0xe0 [4005007.703023] __x64_sys_read+0x19/0x20 [4005007.703028] do_syscall_64+0x5c/0xc0 [4005007.703034] ? do_user_addr_fault+0x1e3/0x670 [4005007.703040] ? exit_to_user_mode_prepare+0x37/0xb0 [4005007.703047] ? irqentry_exit_to_user_mode+0x9/0x20 [4005007.703052] ? irqentry_exit+0x19/0x30 [4005007.703057] ? exc_page_fault+0x89/0x160 [4005007.703062] ? asm_exc_page_fault+0x8/0x30 [4005007.703068] entry_SYSCALL_64_after_hwframe+0x44/0xae [4005007.703075] RIP: 0033:0x7f5e07672992 [4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e c 28 48 89 54 24 [4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992 [4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003 [4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010 [4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000 [4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000 [4005007.703105] </TASK> [4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_ iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v 2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca [4005007.703184] CR2: 0000000000000000 [4005007.703188] ---[ end trace ac65a538d240da39 ]--- [4005007.800865] RIP: 0010:0x0 [4005007.800871] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. [4005007.800874] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206 [4005007.800878] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68 [4005007.800881] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000 [4005007.800883] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980 [4005007.800886] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000 [4005007.800888] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000 [4005007.800891] FS: 00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000 [4005007.800895] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [4005007.800898] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0 Signed-off-by: Qu Huang <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
[ Upstream commit 18f039428c7df183b09c69ebf10ffd4e521035d2 ] Inspired by syzbot reports using a stack of multiple ipvlan devices. Reduce stack size needed in ipvlan_process_v6_outbound() by moving the flowi6 struct used for the route lookup in an non inlined helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack, immediately reclaimed. Also make sure ipvlan_process_v4_outbound() is not inlined. We might also have to lower MAX_NEST_DEV, because only syzbot uses setups with more than four stacked devices. BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000) stack guard page: 0000 [#1] SMP KASAN CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023 RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188 Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89 RSP: 0018:ffffc9000e804000 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568 RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000 FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <#DF> </#DF> <TASK> [<ffffffff81f281d1>] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31 [<ffffffff817e5bf2>] instrument_atomic_read include/linux/instrumented.h:72 [inline] [<ffffffff817e5bf2>] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] [<ffffffff817e5bf2>] cpumask_test_cpu include/linux/cpumask.h:506 [inline] [<ffffffff817e5bf2>] cpu_online include/linux/cpumask.h:1092 [inline] [<ffffffff817e5bf2>] trace_lock_acquire include/trace/events/lock.h:24 [inline] [<ffffffff817e5bf2>] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632 [<ffffffff8563221e>] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306 [<ffffffff8561464d>] rcu_read_lock include/linux/rcupdate.h:747 [inline] [<ffffffff8561464d>] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221 [<ffffffff85618120>] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606 [<ffffffff856f65b5>] pol_lookup_func include/net/ip6_fib.h:584 [inline] [<ffffffff856f65b5>] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116 [<ffffffff85618009>] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638 [<ffffffff8561821a>] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651 [<ffffffff838bd5a3>] ip6_route_output include/net/ip6_route.h:100 [inline] [<ffffffff838bd5a3>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline] [<ffffffff838bd5a3>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff838bd5a3>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff838bd5a3>] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline] [<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline] [<ffffffff855ce4cd>] neigh_output include/net/neighbour.h:543 [inline] [<ffffffff855ce4cd>] ip6_finish_output2+0x160d/0x1ae0 net/ipv6/ip6_output.c:139 [<ffffffff855b8616>] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline] [<ffffffff855b8616>] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211 [<ffffffff855b7e3c>] NF_HOOK_COND include/linux/netfilter.h:298 [inline] [<ffffffff855b7e3c>] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232 [<ffffffff8575d27f>] dst_output include/net/dst.h:444 [inline] [<ffffffff8575d27f>] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161 [<ffffffff838bdae4>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline] [<ffffffff838bdae4>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff838bdae4>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff838bdae4>] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline] [<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline] [<ffffffff855ce4cd>] neigh_output include/net/neighbour.h:543 [inline] [<ffffffff855ce4cd>] ip6_finish_output2+0x160d/0x1ae0 net/ipv6/ip6_output.c:139 [<ffffffff855b8616>] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline] [<ffffffff855b8616>] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211 [<ffffffff855b7e3c>] NF_HOOK_COND include/linux/netfilter.h:298 [inline] [<ffffffff855b7e3c>] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232 [<ffffffff8575d27f>] dst_output include/net/dst.h:444 [inline] [<ffffffff8575d27f>] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161 [<ffffffff838bdae4>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline] [<ffffffff838bdae4>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff838bdae4>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff838bdae4>] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline] [<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline] [<ffffffff855ce4cd>] neigh_output include/net/neighbour.h:543 [inline] [<ffffffff855ce4cd>] ip6_finish_output2+0x160d/0x1ae0 net/ipv6/ip6_output.c:139 [<ffffffff855b8616>] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline] [<ffffffff855b8616>] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211 [<ffffffff855b7e3c>] NF_HOOK_COND include/linux/netfilter.h:298 [inline] [<ffffffff855b7e3c>] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232 [<ffffffff8575d27f>] dst_output include/net/dst.h:444 [inline] [<ffffffff8575d27f>] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161 [<ffffffff838bdae4>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline] [<ffffffff838bdae4>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff838bdae4>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff838bdae4>] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff855ce4cd>] dev_queue_xmit include/linux/netdevice.h:3067 [inline] [<ffffffff855ce4cd>] neigh_hh_output include/net/neighbour.h:529 [inline] [<ffffffff855ce4cd>] neigh_output include/net/neighbour.h:543 [inline] [<ffffffff855ce4cd>] ip6_finish_output2+0x160d/0x1ae0 net/ipv6/ip6_output.c:139 [<ffffffff855b8616>] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline] [<ffffffff855b8616>] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211 [<ffffffff855b7e3c>] NF_HOOK_COND include/linux/netfilter.h:298 [inline] [<ffffffff855b7e3c>] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232 [<ffffffff8575d27f>] dst_output include/net/dst.h:444 [inline] [<ffffffff8575d27f>] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161 [<ffffffff838bdae4>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline] [<ffffffff838bdae4>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff838bdae4>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff838bdae4>] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff838c2909>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84d03900>] netdev_start_xmit include/linux/netdevice.h:4966 [inline] [<ffffffff84d03900>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84d03900>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff84d080e2>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff84d4a65e>] dev_queue_xmit include/linux/netdevice.h:3067 [inline] [<ffffffff84d4a65e>] neigh_resolve_output+0x64e/0x750 net/core/neighbour.c:1560 [<ffffffff855ce503>] neigh_output include/net/neighbour.h:545 [inline] [<ffffffff855ce503>] ip6_finish_output2+0x1643/0x1ae0 net/ipv6/ip6_output.c:139 [<ffffffff855b8616>] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline] [<ffffffff855b8616>] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211 [<ffffffff855b7e3c>] NF_HOOK_COND include/linux/netfilter.h:298 [inline] [<ffffffff855b7e3c>] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232 [<ffffffff855b9ce4>] dst_output include/net/dst.h:444 [inline] [<ffffffff855b9ce4>] NF_HOOK include/linux/netfilter.h:309 [inline] [<ffffffff855b9ce4>] ip6_xmit+0x11a4/0x1b20 net/ipv6/ip6_output.c:352 [<ffffffff8597984e>] sctp_v6_xmit+0x9ae/0x1230 net/sctp/ipv6.c:250 [<ffffffff8594623e>] sctp_packet_transmit+0x25de/0x2bc0 net/sctp/output.c:653 [<ffffffff858f5142>] sctp_packet_singleton+0x202/0x310 net/sctp/outqueue.c:783 [<ffffffff858ea411>] sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline] [<ffffffff858ea411>] sctp_outq_flush+0x661/0x3d40 net/sctp/outqueue.c:1212 [<ffffffff858f02f9>] sctp_outq_uncork+0x79/0xb0 net/sctp/outqueue.c:764 [<ffffffff8589f060>] sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline] [<ffffffff8589f060>] sctp_do_sm+0x55c0/0x5c30 net/sctp/sm_sideeffect.c:1170 [<ffffffff85941567>] sctp_primitive_ASSOCIATE+0x97/0xc0 net/sctp/primitive.c:73 [<ffffffff859408b2>] sctp_sendmsg_to_asoc+0xf62/0x17b0 net/sctp/socket.c:1839 [<ffffffff85910b5e>] sctp_sendmsg+0x212e/0x33b0 net/sctp/socket.c:2029 [<ffffffff8544d559>] inet_sendmsg+0x149/0x310 net/ipv4/af_inet.c:849 [<ffffffff84c6c4d2>] sock_sendmsg_nosec net/socket.c:716 [inline] [<ffffffff84c6c4d2>] sock_sendmsg net/socket.c:736 [inline] [<ffffffff84c6c4d2>] ____sys_sendmsg+0x572/0x8c0 net/socket.c:2504 [<ffffffff84c6ca91>] ___sys_sendmsg net/socket.c:2558 [inline] [<ffffffff84c6ca91>] __sys_sendmsg+0x271/0x360 net/socket.c:2587 [<ffffffff84c6cbff>] __do_sys_sendmsg net/socket.c:2596 [inline] [<ffffffff84c6cbff>] __se_sys_sendmsg net/socket.c:2594 [inline] [<ffffffff84c6cbff>] __x64_sys_sendmsg+0x7f/0x90 net/socket.c:2594 [<ffffffff85b32553>] do_syscall_x64 arch/x86/entry/common.c:51 [inline] [<ffffffff85b32553>] do_syscall_64+0x53/0x80 arch/x86/entry/common.c:84 [<ffffffff85c00087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: 2ad7bf3 ("ipvlan: Initial check-in of the IPVLAN driver.") Reported-by: syzbot <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Cc: Mahesh Bandewar <[email protected]> Cc: Willem de Bruijn <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
commit 5a22fbcc10f3f7d94c5d88afbbffa240a3677057 upstream.
When LAN9303 is MDIO-connected two callchains exist into
mdio->bus->write():
1. switch ports 1&2 ("physical" PHYs):
virtual (switch-internal) MDIO bus (lan9303_switch_ops->phy_{read|write})->
lan9303_mdio_phy_{read|write} -> mdiobus_{read|write}_nested
2. LAN9303 virtual PHY:
virtual MDIO bus (lan9303_phy_{read|write}) ->
lan9303_virt_phy_reg_{read|write} -> regmap -> lan9303_mdio_{read|write}
If the latter functions just take
mutex_lock(&sw_dev->device->bus->mdio_lock) it triggers a LOCKDEP
false-positive splat. It's false-positive because the first
mdio_lock in the second callchain above belongs to virtual MDIO bus, the
second mdio_lock belongs to physical MDIO bus.
Consequent annotation in lan9303_mdio_{read|write} as nested lock
(similar to lan9303_mdio_phy_{read|write}, it's the same physical MDIO bus)
prevents the following splat:
WARNING: possible circular locking dependency detected
5.15.71 #1 Not tainted
------------------------------------------------------
kworker/u4:3/609 is trying to acquire lock:
ffff000011531c68 (lan9303_mdio:131:(&lan9303_mdio_regmap_config)->lock){+.+.}-{3:3}, at: regmap_lock_mutex
but task is already holding lock:
ffff0000114c44d8 (&bus->mdio_lock){+.+.}-{3:3}, at: mdiobus_read
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&bus->mdio_lock){+.+.}-{3:3}:
lock_acquire
__mutex_lock
mutex_lock_nested
lan9303_mdio_read
_regmap_read
regmap_read
lan9303_probe
lan9303_mdio_probe
mdio_probe
really_probe
__driver_probe_device
driver_probe_device
__device_attach_driver
bus_for_each_drv
__device_attach
device_initial_probe
bus_probe_device
deferred_probe_work_func
process_one_work
worker_thread
kthread
ret_from_fork
-> #0 (lan9303_mdio:131:(&lan9303_mdio_regmap_config)->lock){+.+.}-{3:3}:
__lock_acquire
lock_acquire.part.0
lock_acquire
__mutex_lock
mutex_lock_nested
regmap_lock_mutex
regmap_read
lan9303_phy_read
dsa_slave_phy_read
__mdiobus_read
mdiobus_read
get_phy_device
mdiobus_scan
__mdiobus_register
dsa_register_switch
lan9303_probe
lan9303_mdio_probe
mdio_probe
really_probe
__driver_probe_device
driver_probe_device
__device_attach_driver
bus_for_each_drv
__device_attach
device_initial_probe
bus_probe_device
deferred_probe_work_func
process_one_work
worker_thread
kthread
ret_from_fork
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&bus->mdio_lock);
lock(lan9303_mdio:131:(&lan9303_mdio_regmap_config)->lock);
lock(&bus->mdio_lock);
lock(lan9303_mdio:131:(&lan9303_mdio_regmap_config)->lock);
*** DEADLOCK ***
5 locks held by kworker/u4:3/609:
#0: ffff000002842938 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work
#1: ffff80000bacbd60 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work
#2: ffff000007645178 (&dev->mutex){....}-{3:3}, at: __device_attach
#3: ffff8000096e6e78 (dsa2_mutex){+.+.}-{3:3}, at: dsa_register_switch
#4: ffff0000114c44d8 (&bus->mdio_lock){+.+.}-{3:3}, at: mdiobus_read
stack backtrace:
CPU: 1 PID: 609 Comm: kworker/u4:3 Not tainted 5.15.71 #1
Workqueue: events_unbound deferred_probe_work_func
Call trace:
dump_backtrace
show_stack
dump_stack_lvl
dump_stack
print_circular_bug
check_noncircular
__lock_acquire
lock_acquire.part.0
lock_acquire
__mutex_lock
mutex_lock_nested
regmap_lock_mutex
regmap_read
lan9303_phy_read
dsa_slave_phy_read
__mdiobus_read
mdiobus_read
get_phy_device
mdiobus_scan
__mdiobus_register
dsa_register_switch
lan9303_probe
lan9303_mdio_probe
...
Cc: [email protected]
Fixes: dc70058 ("net: dsa: LAN9303: add MDIO managed mode support")
Signed-off-by: Alexander Sverdlin <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Abeni <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
[ Upstream commit fc43e9c857b7aa55efba9398419b14d9e35dcc7d ] hid_debug_events_release releases resources bound to the HID device instance. hid_device_release releases the underlying HID device instance potentially before hid_debug_events_release has completed releasing debug resources bound to the same HID device instance. Reference count to prevent the HID device instance from being torn down preemptively when HID debugging support is used. When count reaches zero, release core resources of HID device instance using hiddev_free. The crash: [ 120.728477][ T4396] kernel BUG at lib/list_debug.c:53! [ 120.728505][ T4396] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 120.739806][ T4396] Modules linked in: bcmdhd dhd_static_buf 8822cu pcie_mhi r8168 [ 120.747386][ T4396] CPU: 1 PID: 4396 Comm: hidt_bridge Not tainted 5.10.110 #257 [ 120.754771][ T4396] Hardware name: Rockchip RK3588 EVB4 LP4 V10 Board (DT) [ 120.761643][ T4396] pstate: 60400089 (nZCv daIf +PAN -UAO -TCO BTYPE=--) [ 120.768338][ T4396] pc : __list_del_entry_valid+0x98/0xac [ 120.773730][ T4396] lr : __list_del_entry_valid+0x98/0xac [ 120.779120][ T4396] sp : ffffffc01e62bb60 [ 120.783126][ T4396] x29: ffffffc01e62bb60 x28: ffffff818ce3a200 [ 120.789126][ T4396] x27: 0000000000000009 x26: 0000000000980000 [ 120.795126][ T4396] x25: ffffffc012431000 x24: ffffff802c6d4e00 [ 120.801125][ T4396] x23: ffffff8005c66f00 x22: ffffffc01183b5b8 [ 120.807125][ T4396] x21: ffffff819df2f100 x20: 0000000000000000 [ 120.813124][ T4396] x19: ffffff802c3f0700 x18: ffffffc01d2cd058 [ 120.819124][ T4396] x17: 0000000000000000 x16: 0000000000000000 [ 120.825124][ T4396] x15: 0000000000000004 x14: 0000000000003fff [ 120.831123][ T4396] x13: ffffffc012085588 x12: 0000000000000003 [ 120.837123][ T4396] x11: 00000000ffffbfff x10: 0000000000000003 [ 120.843123][ T4396] x9 : 455103d46b329300 x8 : 455103d46b329300 [ 120.849124][ T4396] x7 : 74707572726f6320 x6 : ffffffc0124b8cb5 [ 120.855124][ T4396] x5 : ffffffffffffffff x4 : 0000000000000000 [ 120.861123][ T4396] x3 : ffffffc011cf4f90 x2 : ffffff81fee7b948 [ 120.867122][ T4396] x1 : ffffffc011cf4f90 x0 : 0000000000000054 [ 120.873122][ T4396] Call trace: [ 120.876259][ T4396] __list_del_entry_valid+0x98/0xac [ 120.881304][ T4396] hid_debug_events_release+0x48/0x12c [ 120.886617][ T4396] full_proxy_release+0x50/0xbc [ 120.891323][ T4396] __fput+0xdc/0x238 [ 120.895075][ T4396] ____fput+0x14/0x24 [ 120.898911][ T4396] task_work_run+0x90/0x148 [ 120.903268][ T4396] do_exit+0x1bc/0x8a4 [ 120.907193][ T4396] do_group_exit+0x8c/0xa4 [ 120.911458][ T4396] get_signal+0x468/0x744 [ 120.915643][ T4396] do_signal+0x84/0x280 [ 120.919650][ T4396] do_notify_resume+0xd0/0x218 [ 120.924262][ T4396] work_pending+0xc/0x3f0 [ Rahul Rameshbabu <[email protected]>: rework changelog ] Fixes: cd667ce ("HID: use debugfs for events/reports dumping") Signed-off-by: Charles Yi <[email protected]> Signed-off-by: Jiri Kosina <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
[ Upstream commit 7bf9a6b46549852a37e6d07e52c601c3c706b562 ] xen_vcpu_info is a percpu area than needs to be mapped by Xen. Currently, it could cross a page boundary resulting in Xen being unable to map it: [ 0.567318] kernel BUG at arch/arm64/xen/../../arm/xen/enlighten.c:164! [ 0.574002] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Fix the issue by using __alloc_percpu and requesting alignment for the memory allocation. Signed-off-by: Stefano Stabellini <[email protected]> Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2311221501340.2053963@ubuntu-linux-20-04-desktop Fixes: 24d5373 ("arm/xen: Use alloc_percpu rather than __alloc_percpu") Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: Juergen Gross <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
commit 2b3a7a302c9804e463f2ea5b54dc3a6ad106a344 upstream. The pcm state can be SNDRV_PCM_STATE_DISCONNECTED at disconnect callback, and there is not an entry of SNDRV_PCM_STATE_DISCONNECTED in snd_pcm_state_names. This patch adds the missing entry to resolve this issue. cat /proc/asound/card2/pcm0p/sub0/status That results in stack traces like the following: [ 99.702732][ T5171] Unexpected kernel BRK exception at EL1 [ 99.702774][ T5171] Internal error: BRK handler: f2005512 [#1] PREEMPT SMP [ 99.703858][ T5171] Modules linked in: bcmdhd(E) (...) [ 99.747425][ T5171] CPU: 3 PID: 5171 Comm: cat Tainted: G C OE 5.10.189-android13-4-00003-g4a17384380d8-ab11086999 #1 [ 99.748447][ T5171] Hardware name: Rockchip RK3588 CVTE V10 Board (DT) [ 99.749024][ T5171] pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 99.749616][ T5171] pc : snd_pcm_substream_proc_status_read+0x264/0x2bc [ 99.750204][ T5171] lr : snd_pcm_substream_proc_status_read+0xa4/0x2bc [ 99.750778][ T5171] sp : ffffffc0175abae0 [ 99.751132][ T5171] x29: ffffffc0175abb80 x28: ffffffc009a2c498 [ 99.751665][ T5171] x27: 0000000000000001 x26: ffffff810cbae6e8 [ 99.752199][ T5171] x25: 0000000000400cc0 x24: ffffffc0175abc60 [ 99.752729][ T5171] x23: 0000000000000000 x22: ffffff802f558400 [ 99.753263][ T5171] x21: ffffff81d8d8ff00 x20: ffffff81020cdc00 [ 99.753795][ T5171] x19: ffffff802d110000 x18: ffffffc014fbd058 [ 99.754326][ T5171] x17: 0000000000000000 x16: 0000000000000000 [ 99.754861][ T5171] x15: 000000000000c276 x14: ffffffff9a976fda [ 99.755392][ T5171] x13: 0000000065689089 x12: 000000000000d72e [ 99.755923][ T5171] x11: ffffff802d110000 x10: 00000000000000e0 [ 99.756457][ T5171] x9 : 9c431600c8385d00 x8 : 0000000000000008 [ 99.756990][ T5171] x7 : 0000000000000000 x6 : 000000000000003f [ 99.757522][ T5171] x5 : 0000000000000040 x4 : ffffffc0175abb70 [ 99.758056][ T5171] x3 : 0000000000000001 x2 : 0000000000000001 [ 99.758588][ T5171] x1 : 0000000000000000 x0 : 0000000000000000 [ 99.759123][ T5171] Call trace: [ 99.759404][ T5171] snd_pcm_substream_proc_status_read+0x264/0x2bc [ 99.759958][ T5171] snd_info_seq_show+0x54/0xa4 [ 99.760370][ T5171] seq_read_iter+0x19c/0x7d4 [ 99.760770][ T5171] seq_read+0xf0/0x128 [ 99.761117][ T5171] proc_reg_read+0x100/0x1f8 [ 99.761515][ T5171] vfs_read+0xf4/0x354 [ 99.761869][ T5171] ksys_read+0x7c/0x148 [ 99.762226][ T5171] __arm64_sys_read+0x20/0x30 [ 99.762625][ T5171] el0_svc_common+0xd0/0x1e4 [ 99.763023][ T5171] el0_svc+0x28/0x98 [ 99.763358][ T5171] el0_sync_handler+0x8c/0xf0 [ 99.763759][ T5171] el0_sync+0x1b8/0x1c0 [ 99.764118][ T5171] Code: d65f03c0 b9406102 17ffffae 94191565 (d42aa240) [ 99.764715][ T5171] ---[ end trace 1eeffa3e17c58e10 ]--- [ 99.780720][ T5171] Kernel panic - not syncing: BRK handler: Fatal exception Signed-off-by: Jason Zhang <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
itsHanibee
pushed a commit
that referenced
this pull request
Jan 2, 2024
It's not valid to call into zRAM from bio_endio(): [ 3534.259953] WARNING: CPU: 3 PID: 44 at drivers/block/zram/zcomp.c:204 zram_bvec_rw.isra.0+0x5d8/0x670 [ 3534.259998] CPU: 3 PID: 44 Comm: ksoftirqd/3 Tainted: G W 5.10.157-rt87-Sultan #1 [ 3534.260006] Hardware name: GS201 PANTHER MP based on GS201 (DT) [ 3534.260013] pstate: 60c00005 (nZCv daif +PAN +UAO -TCO BTYPE=--) [ 3534.260020] pc : zram_bvec_rw.isra.0+0x5d8/0x670 [ 3534.260025] lr : zram_bvec_rw.isra.0+0x22c/0x670 [ 3534.260030] sp : ffffff800364ad90 [ 3534.260033] x29: ffffff800364ad90 x28: ffffffff250b8088 [ 3534.260040] x27: 0000000000000000 x26: ffffff80036410c0 [ 3534.260046] x25: ffffff80036410c0 x24: 00000000706ff060 [ 3534.260051] x23: ffffffff250b8080 x22: 0000000000000000 [ 3534.260056] x21: 0000000000000000 x20: 0000000000046a92 [ 3534.260061] x19: ffffff806924bb00 x18: ffffffe080552700 [ 3534.260066] x17: ffffff80087d1340 x16: 0000000000000000 [ 3534.260071] x15: 0000000000000004 x14: 0000000000000002 [ 3534.260075] x13: 00000059ddcc240c x12: 0000000000000062 [ 3534.260080] x11: 0000000000000028 x10: 0000000000000008 [ 3534.260085] x9 : 0000000000000001 x8 : 0000000000000048 [ 3534.260090] x7 : ffffff8068c2a838 x6 : 0000000000000000 [ 3534.260095] x5 : ffffff80036410c0 x4 : 0000000000000000 [ 3534.260099] x3 : ffffffe07fe97790 x2 : 0000000000000000 [ 3534.260104] x1 : 0000000000000100 x0 : 0000000000000100 [ 3534.260112] Call trace: [ 3534.260116] zram_bvec_rw.isra.0+0x5d8/0x670 [ 3534.260123] zram_rw_page+0x98/0x18c [ 3534.260142] bdev_write_page.isra.0+0x84/0x160 [ 3534.260156] swap_writepage.lto_priv.0+0x80/0x344 [ 3534.260173] shrink_page_list.lto_priv.0+0x1278/0x1b30 [ 3534.260188] shrink_inactive_list+0x174/0x444 [ 3534.260194] shrink_node.lto_priv.0+0x750/0xd3c [ 3534.260199] __alloc_pages_slowpath.constprop.0+0x7e8/0x26c0 [ 3534.260213] __alloc_pages_nodemask.constprop.0.isra.0+0x2c0/0x5c0 [ 3534.260219] z_erofs_lz4_decompress.lto_priv.0+0xa40/0xe0c [ 3534.260237] z_erofs_decompress_pcluster.isra.0+0x3a8/0x9a0 [ 3534.260244] z_erofs_decompress_kickoff+0x114/0x140 [ 3534.260252] z_erofs_decompressqueue_endio+0x19c/0x220 [ 3534.260259] bio_endio.lto_priv.0+0x114/0x140 [ 3534.260276] dec_pending.lto_priv.0+0x15c/0x230 [ 3534.260293] clone_endio.lto_priv.0+0xb0/0x1cc [ 3534.260300] bio_endio.lto_priv.0+0x114/0x140 [ 3534.260306] blk_update_request.lto_priv.0+0x1ac/0x4e8 [ 3534.260313] scsi_end_request+0x30/0x480 [ 3534.260326] scsi_finish_command+0x174/0xa44 [ 3534.260332] scsi_softirq_done+0xf4/0x170 [ 3534.260337] blk_done_softirq+0x7c/0x90 [ 3534.260349] _stext+0x16c/0x2f0 [ 3534.260360] run_ksoftirqd+0x134/0x1e0 [ 3534.260377] smpboot_thread_fn+0x33c/0x388 [ 3534.260390] kthread+0x12c/0x138 [ 3534.260394] ret_from_fork+0x10/0x18 [ 3534.260409] ---[ end trace 000000000000003d ]--- Plus, direct reclaim of any sort can deadlock from bio_endio(): [15613.934969] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks: [15613.934988] rcu: Tasks blocked on level-0 rcu_node (CPUs 0-7): P192/2:b..l [15613.935018] (detected by 4, t=5252 jiffies, g=1739825, q=134) [15613.935033] task:irq/228-ufshcd state:D stack: 0 pid: 192 ppid: 2 flags:0x00000008 [15613.935052] Call trace: [15613.935056] __schedule.lto_priv.0+0x3c0/0xf84 [15613.935107] schedule+0x30/0xd0 [15613.935124] schedule_timeout.lto_priv.0+0xc4/0xf8 [15613.935145] wait_for_completion.lto_priv.0+0xb0/0x158 [15613.935159] __flush_work.isra.0+0x194/0x2c8 [15613.935176] __alloc_pages_slowpath.constprop.0+0x191c/0x26b0 [15613.935198] __alloc_pages_nodemask.constprop.0.isra.0+0x348/0x730 [15613.935212] z_erofs_lz4_decompress.lto_priv.0+0xa2c/0xde0 [15613.935235] z_erofs_decompress_pcluster.isra.0+0x424/0x840 [15613.935254] z_erofs_decompress_kickoff+0xd8/0x168 [15613.935264] z_erofs_decompressqueue_endio+0x188/0x224 [15613.935273] bio_endio.lto_priv.0+0x1e4/0x230 [15613.935287] dec_pending.lto_priv.0+0x158/0x240 [15613.935302] clone_endio.lto_priv.0+0xac/0x1c8 [15613.935313] bio_endio.lto_priv.0+0x1e4/0x230 [15613.935324] blk_update_request.lto_priv.0+0x1b8/0x520 [15613.935337] scsi_end_request+0x30/0x3e0 [15613.935355] scsi_finish_command+0x1f8/0xad0 [15613.935363] scsi_softirq_done+0xf4/0x170 [15613.935372] blk_done_softirq+0x7c/0x90 [15613.935386] __do_softirq+0x110/0x240 [15613.935398] __local_bh_enable_ip.constprop.0+0x78/0xdc [15613.935410] irq_forced_thread_fn+0x70/0x84 [15613.935422] irq_thread+0x2e4/0x4e0 [15613.935430] kthread+0x100/0x134 [15613.935445] ret_from_fork+0x10/0x18 In order to make the allocation never fail without using I/O or direct reclaim, loop and retry indefinitely because the page allocator requires __GFP_DIRECT_RECLAIM to be used in conjunction with __GFP_NOFAIL. Signed-off-by: Sultan Alsawaf <[email protected]> Signed-off-by: Tashfin Shakeer Rhythm <[email protected]>
itsHanibee
added a commit
that referenced
this pull request
Jan 20, 2024
Signed-off-by: hani <[email protected]>
itsHanibee
added a commit
that referenced
this pull request
Jan 20, 2024
Signed-off-by: hani <[email protected]>
|
Thanks for this. allow me to cherry pick your stuff. backslashxx/mojito_krenol@f99125f -- edit. shorthand for this is SuSFS ඞ |
yea that's fine, it's foss. i don't mind |
backslashxx
pushed a commit
to backslashxx/mojito_krenol
that referenced
this pull request
Mar 9, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
backslashxx
pushed a commit
to backslashxx/msm8953-kernel
that referenced
this pull request
Mar 9, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
natsumerinchan
added a commit
to natsumerinchan/kernel_oneplus_sm8350
that referenced
this pull request
Mar 9, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 Co-Authored-By: Kartatz <[email protected]>
alternoegraha
pushed a commit
to alternoegraha/wwy_kernel_xiaomi_fog_rebase
that referenced
this pull request
Mar 9, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 Signed-off-by: alternoegraha <[email protected]>
mateoalfaro
pushed a commit
to mateoalfaro/kernel_xiaomi_vayu
that referenced
this pull request
Mar 10, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
losshye
pushed a commit
to losshye/sea_kernel_xiaomi_sm6225
that referenced
this pull request
Jun 10, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 Signed-off-by: alternoegraha <[email protected]>
roniwae
added a commit
to roniwae/komplit
that referenced
this pull request
Jun 12, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
roniwae
added a commit
to roniwae/komplit
that referenced
this pull request
Jun 12, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
forkposix
added a commit
to forkposix/amagas_kernel_lemonade
that referenced
this pull request
Jun 25, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
forkposix
added a commit
to forkposix/amagas_kernel_lemonade
that referenced
this pull request
Jun 25, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
forkposix
added a commit
to forkposix/amagas_kernel_lemonade
that referenced
this pull request
Jun 25, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
forkposix
added a commit
to forkposix/amagas_kernel_lemonade
that referenced
this pull request
Jun 25, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
arswb
pushed a commit
to SkiddieKernel/android_kernel_xiaomi_sm6150
that referenced
this pull request
Jun 27, 2024
Prevent Zygisk/KernelSU detection through common methods This prevents the kernel from revealing KernelSU/Zygisk mount points in /proc for non-system apps and also prevents scanning the filesystem for suspicious files and directories. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 + guard everything properly Signed-off-by: backslashxx <[email protected]> Signed-off-by: Aris Wibowo <[email protected]>
arswb
pushed a commit
to SkiddieKernel/android_kernel_xiaomi_sm6150
that referenced
this pull request
Jun 27, 2024
Prevent Zygisk/KernelSU detection through common methods This prevents the kernel from revealing KernelSU/Zygisk mount points in /proc for non-system apps and also prevents scanning the filesystem for suspicious files and directories. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 + guard everything properly Signed-off-by: backslashxx <[email protected]> Signed-off-by: Aris Wibowo <[email protected]>
thubble
added a commit
to thubble/android_kernel_oneplus_sm8350
that referenced
this pull request
Jun 28, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 Cherry-picked from amagas kernel: forkposix@c5f7bf0
alternoegraha
pushed a commit
to alternoegraha/wwy_kernel_xiaomi_fog_rebase
that referenced
this pull request
Jul 25, 2024
Prevent Zygisk/KernelSU detection through common methods This prevents the kernel from revealing KernelSU/Zygisk mount points in /proc for non-system apps and also prevents scanning the filesystem for suspicious files and directories. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 + guard everything properly Signed-off-by: backslashxx <[email protected]>
alternoegraha
pushed a commit
to alternoegraha/wwy_kernel_xiaomi_fog_rebase
that referenced
this pull request
Jul 25, 2024
Prevent Zygisk/KernelSU detection through common methods This prevents the kernel from revealing KernelSU/Zygisk mount points in /proc for non-system apps and also prevents scanning the filesystem for suspicious files and directories. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 + guard everything properly Signed-off-by: backslashxx <[email protected]>
aslenofarid
pushed a commit
to AslenoLineageStuff/msm-4.4
that referenced
this pull request
Aug 1, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
aslenofarid
pushed a commit
to aslenofarid/kernel_asus_sdm660
that referenced
this pull request
Aug 3, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
saku-bruh
pushed a commit
to XperiaLabs/kernel_sony_sagami-clo
that referenced
this pull request
Sep 7, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 Signed-off-by: Pranav Vashi <[email protected]> Signed-off-by: onettboots <[email protected]>
asterixiverz
pushed a commit
to asterixiverz/kernel_xiaomi_fog-msm4.19
that referenced
this pull request
Sep 9, 2024
Prevent Zygisk/KernelSU detection through common methods This prevents the kernel from revealing KernelSU/Zygisk mount points in /proc for non-system apps and also prevents scanning the filesystem for suspicious files and directories. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 + guard everything properly Signed-off-by: backslashxx <[email protected]> Signed-off-by: Iverz <[email protected]>
asterixiverz
pushed a commit
to asterixiverz/kernel_xiaomi_fog-msm4.19
that referenced
this pull request
Sep 9, 2024
Prevent Zygisk/KernelSU detection through common methods This prevents the kernel from revealing KernelSU/Zygisk mount points in /proc for non-system apps and also prevents scanning the filesystem for suspicious files and directories. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 + guard everything properly Signed-off-by: backslashxx <[email protected]> Signed-off-by: Iverz <[email protected]>
whyakari
pushed a commit
to MoeKernel/android_kernel_motorola_bangkk
that referenced
this pull request
Sep 10, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
zxrovx
pushed a commit
to zxrovx/Liliya-Nethunter
that referenced
this pull request
Sep 12, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
asterixiverz
pushed a commit
to asterixiverz/kernel_xiaomi_fog-msm4.19
that referenced
this pull request
Sep 13, 2024
Prevent Zygisk/KernelSU detection through common methods This prevents the kernel from revealing KernelSU/Zygisk mount points in /proc for non-system apps and also prevents scanning the filesystem for suspicious files and directories. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 + guard everything properly Signed-off-by: backslashxx <[email protected]> Signed-off-by: asterixiverz <[email protected]>
asterixiverz
pushed a commit
to asterixiverz/kernel_xiaomi_fog-msm4.19
that referenced
this pull request
Sep 13, 2024
Prevent Zygisk/KernelSU detection through common methods This prevents the kernel from revealing KernelSU/Zygisk mount points in /proc for non-system apps and also prevents scanning the filesystem for suspicious files and directories. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 + guard everything properly Signed-off-by: backslashxx <[email protected]>
mgs28-mh
pushed a commit
to mgs28-mh/kernel_xiaomi_fog-4.19
that referenced
this pull request
Sep 21, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
ghazzor
pushed a commit
to ghazzor/kernel_moto_695_5.4
that referenced
this pull request
Sep 21, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
mgs28-mh
pushed a commit
to mgs28-mh/kernel_xiaomi_fog-4.19
that referenced
this pull request
Sep 22, 2024
Prevent Zygisk/KernelSU detection through common methods This prevents the kernel from revealing KernelSU/Zygisk mount points in /proc for non-system apps and also prevents scanning the filesystem for suspicious files and directories. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 + guard everything properly Signed-off-by: backslashxx <[email protected]>
Samw662
pushed a commit
to Samw662/android_kernel_motorola_bangkk
that referenced
this pull request
Oct 10, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
iqbal45778
pushed a commit
to iqbal45778/msm-4.14
that referenced
this pull request
Nov 26, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 Signed-off-by: Pranav Vashi <[email protected]>
iqbal45778
pushed a commit
to iqbal45778/msm-4.14
that referenced
this pull request
Nov 26, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 Signed-off-by: Pranav Vashi <[email protected]>
iqbal45778
pushed a commit
to iqbal45778/kernel_xiaomi_mojito
that referenced
this pull request
Nov 28, 2024
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3 Signed-off-by: Pranav Vashi <[email protected]>
Blacklucifer82
pushed a commit
to Blacklucifer82/android_kernel_motorola_sm6375
that referenced
this pull request
Jan 24, 2025
This prevents the kernel from revealing KernelSU/Zygisk mount points for non-system apps and also prevents scanning the filesystem for suspicious files and directories like /sdcard/TWRP. KernelSU v0.7.2 introduced a new tmpfs mount point at /debug_ramdisk, which is intended for modules to store temporary files during pre/post installation (See tiann/KernelSU@706cd1e). I updated the antidetection logic to also hide this directory for non-system apps. Signed-off-by: Kartatz <[email protected]> from: Dominium-Apum/kernel_xiaomi_chime#1 Dominium-Apum/kernel_xiaomi_chime#3
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This prevents the kernel from revealing KernelSU/Zygisk mount points in
/procfor non-system apps and also prevents scanning the filesystem for suspicious files and directories like/sdcard/TWRP.