Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add ANDROID USB patches #40

Merged
merged 11 commits into from
Aug 3, 2021
Merged

Add ANDROID USB patches #40

merged 11 commits into from
Aug 3, 2021

Conversation

Flamefire
Copy link
Contributor

@Flamefire Flamefire commented Jul 30, 2021 •
edited
Loading

This adds googles patches to the "usb: f_accessory" stuff.

In summary this adds ref-counting to a shared state to avoid use-after-free issues, so IMO should be added as a security bugfix.

There was a conflict due to 915bb5f which moved around setting _acc_dev, which basically invalidated the comment (which used the wrong function name)
This PR effectively reverts that commit, however 50d5b41 will reset the (new) _acc_dev on error, hence the safety is still there. The ref count checks ensure that this works.

Tests pending... Done

macpaul-lin-mtk and others added 11 commits July 30, 2021 17:27
@macpaul-lin-mtk @Flamefire
ANDROID: usb: gadget: f_accessory: fix CTS test stuck
ba55f97 
f_accessory: fix CTS test stuck since CTS 9.0.
 - Refine acc_read() process.

The data length that user (test program) wants to read is different
from they really requested. This will cause the test flow stuck on the
2nd or the 3rd transfers in accessory test.
(By connecting 2 phones with CtsVerifier.apk and
CtsVerifierUSBCompanion.apk installed.)

Bug: 174729307

Change-Id: I5367c8075ed37534e8bed94b60cc79135ae5aebc
Signed-off-by: Macpaul Lin <macpaul.lin@mediatek.com>
Signed-off-by: Giuliano Procida <gprocida@google.com>
@Flamefire
ANDROID: usb: f_accessory: Remove stale comments
92e3e9d 
Neither acc_gadget_bind() nor acc_gadget_register_driver() exist, so
remove the stale comments that refer to them.

Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: If396ba3bcac3ca59c48e5a5faa0a8520534ed625
Signed-off-by: Giuliano Procida <gprocida@google.com>
@Flamefire
ANDROID: usb: f_accessory: Remove useless non-debug prints
b28fecf 
Remove some useless print statements, as they can trivially be used to
spam the console and don't report anything meaningful.

Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I28052010fc3ec033a2c99efeb3f6c919d54d75c2
Signed-off-by: Giuliano Procida <gprocida@google.com>
@Flamefire
ANDROID: usb: f_accessory: Remove useless assignment
1b81301 
acc_alloc_inst() assigns to a local 'dev' variable, but then never uses
it. Remove the redundant assignment, and the local variable along with
it.

Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ide9c2e89fb12b846eb8739b302d1b742fc7eb6b5
Signed-off-by: Giuliano Procida <gprocida@google.com>
@Flamefire
ANDROID: usb: f_accessory: Wrap '_acc_dev' in get()/put() accessors
0da7579 
The '_acc_dev' global variable is a fancy use-after-free factory. Wrap
it in some get()/put() functions in preparation for introducing some
refcounting.

Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I4c839627648c209341a81efa0c001c8d71b878d4
Signed-off-by: Giuliano Procida <gprocida@google.com>
@Flamefire
ANDROID: usb: f_accessory: Add refcounting to global 'acc_dev'
add85b1 
Add refcounting to track the lifetime of the global 'acc_dev' structure,
as the underlying function directories can be removed while references
still exist to the dev node.

Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I248408e890d01167706c329146d63b64a6456df6
Signed-off-by: Giuliano Procida <gprocida@google.com>
@Flamefire
ANDROID: usb: f_accessory: Fix teardown ordering in acc_release()
3490d4c 
acc_release() attempts to synchronise with acc_open() using an atomic
'open_excl' member in 'struct acc_dev'. Unfortunately, acc_release()
prematurely resets this atomic variable to zero, meaning there is a
potential race on 'dev->disconnected':

acc_open()				acc_release()
						atomic_xchg(open_excl), 0)
	atomic_xchg(open_excl, 1)
	dev->disconnected = 0;			dev->disconnected = 1;

Fix the race by ensuring that the 'disconnected' field is written
before clearing 'open_excl' in acc_release().

Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ib9a21f2305f6d70de3e760da62dbfdd66889200a
Signed-off-by: Giuliano Procida <gprocida@google.com>
@Flamefire
ANDROID: usb: f_accessory: Don't corrupt global state on double regis…
50d5b41 
…tration

If acc_setup() is called when there is already an allocated instance,
misc_register() will fail but the error path leaves a dangling pointer
to freed memory in the global 'acc_dev' state.

Fix this by ensuring that the refcount is zero before we start, and then
using a cmpxchg() from NULL to serialise any concurrent initialisers.

Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I2c26289dcce7dbc493964516c49b05d04aaa6839
Signed-off-by: Giuliano Procida <gprocida@google.com>
@Flamefire
ANDROID: usb: f_accessory: Cancel any pending work before teardown
c746fec 
Tearing down and freeing the 'acc_dev' structure when there is
potentially asynchronous work queued involving its member fields is
likely to lead to use-after-free issues.

Cancel any pending work before freeing the structure.

Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I68a91274aea18034637b738d558d043ac74fadf4
Signed-off-by: Giuliano Procida <gprocida@google.com>
@Flamefire
ANDROID: usb: f_accessory: Avoid bitfields for shared variables
977ea69 
Using bitfields for shared variables is a "bad idea", as they require
a non-atomic read-modify-write to be generated by the compiler, which can
cause updates to unrelated bits in the same word to disappear.

Ensure the 'online' and 'disconnected' members of 'struct acc_dev' are
placed in separate variables by declaring them each as 'int'.

Bug: 173789633
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ia6031d82a764e83b2cc3502fbe5fb273511da752
Signed-off-by: Giuliano Procida <gprocida@google.com>
@Flamefire
ANDROID: usb: f_accessory: Don't drop NULL reference in acc_disconnect()
4a16180 
If get_acc_dev() fails to obtain a reference to the current device,
acc_disconnect() will attempt to put_acc_dev() with the resulting NULL
pointer, leading to a crash:

 | Unable to handle kernel NULL pointer dereference at virtual address 00000074
 | [...]
 | [<c0abb288>] (acc_disconnect) from [<c0a91a38>] (android_disconnect+0x1c/0x7c)
 | [<c0a91a38>] (android_disconnect) from [<c0a93958>] (usb_gadget_udc_reset+0x10/0x34)
 | [<c0a93958>] (usb_gadget_udc_reset) from [<c0a4a9c4>] (dwc3_gadget_reset_interrupt+0x88/0x4fc)
 | [<c0a4a9c4>] (dwc3_gadget_reset_interrupt) from [<c0a491f8>] (dwc3_process_event_buf+0x60/0x3e4)
 | [<c0a491f8>] (dwc3_process_event_buf) from [<c0a49180>] (dwc3_thread_interrupt+0x24/0x3c)
 | [<c0a49180>] (dwc3_thread_interrupt) from [<c02b3404>] (irq_thread_fn+0x1c/0x58)
 | [<c02b3404>] (irq_thread_fn) from [<c02b326c>] (irq_thread+0x1ec/0x2f4)
 | [<c02b326c>] (irq_thread) from [<c0260804>] (kthread+0x1a8/0x1ac)
 | [<c0260804>] (kthread) from [<c0200138>] (ret_from_fork+0x14/0x3c)

Follow the pattern used elsewhere, and return early if we fail to obtain
a reference.

Bug: 173789633
Reported-by: YongQin Liu <yongqin.liu@linaro.org>
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I37a2bff5bc1b6b8269788d08191181763bf0e896
Signed-off-by: Giuliano Procida <gprocida@google.com>
@Flamefire
Copy link
Contributor Author

Tested and no issues so far. Charging and USB transfer work

@derfelot
Copy link
Member

derfelot commented Aug 3, 2021

Thanks again ;)

@derfelot derfelot merged commit 7f98523 into whatawurst:lineage-18.1 Aug 3, 2021
@Flamefire Flamefire deleted the usb_patches branch August 3, 2021 14:59
Flamefire referenced this pull request in Flamefire/android_kernel_sony_msm8998 Jul 28, 2022
@pavelmachek
ARM: 9191/1: arm/stacktrace, kasan: Silence KASAN warnings in unwind_…
1dc2ceb 
…frame()

[ Upstream commit 9be4c88bb7924f68f88cfd47d925c2d046f51a73 ]

The following KASAN warning is detected by QEMU.

==================================================================
BUG: KASAN: stack-out-of-bounds in unwind_frame+0x508/0x870
Read of size 4 at addr c36bba90 by task cat/163

CPU: 1 PID: 163 Comm: cat Not tainted 5.10.0-rc1 #40
Hardware name: ARM-Versatile Express
[<c0113fac>] (unwind_backtrace) from [<c010e71c>] (show_stack+0x10/0x14)
[<c010e71c>] (show_stack) from [<c0b805b4>] (dump_stack+0x98/0xb0)
[<c0b805b4>] (dump_stack) from [<c0b7d658>] (print_address_description.constprop.0+0x58/0x4bc)
[<c0b7d658>] (print_address_description.constprop.0) from [<c031435c>] (kasan_report+0x154/0x170)
[<c031435c>] (kasan_report) from [<c0113c44>] (unwind_frame+0x508/0x870)
[<c0113c44>] (unwind_frame) from [<c010e298>] (__save_stack_trace+0x110/0x134)
[<c010e298>] (__save_stack_trace) from [<c01ce0d8>] (stack_trace_save+0x8c/0xb4)
[<c01ce0d8>] (stack_trace_save) from [<c0313520>] (kasan_set_track+0x38/0x60)
[<c0313520>] (kasan_set_track) from [<c0314cb8>] (kasan_set_free_info+0x20/0x2c)
[<c0314cb8>] (kasan_set_free_info) from [<c0313474>] (__kasan_slab_free+0xec/0x120)
[<c0313474>] (__kasan_slab_free) from [<c0311e20>] (kmem_cache_free+0x7c/0x334)
[<c0311e20>] (kmem_cache_free) from [<c01c35dc>] (rcu_core+0x390/0xccc)
[<c01c35dc>] (rcu_core) from [<c01013a8>] (__do_softirq+0x180/0x518)
[<c01013a8>] (__do_softirq) from [<c0135214>] (irq_exit+0x9c/0xe0)
[<c0135214>] (irq_exit) from [<c01a40e4>] (__handle_domain_irq+0xb0/0x110)
[<c01a40e4>] (__handle_domain_irq) from [<c0691248>] (gic_handle_irq+0xa0/0xb8)
[<c0691248>] (gic_handle_irq) from [<c0100b0c>] (__irq_svc+0x6c/0x94)
Exception stack(0xc36bb928 to 0xc36bb970)
b920:                   c36bb9c0 00000000 c0126919 c0101228 c36bb9c0 b76d7730
b940: c36b8000 c36bb9a0 c3335b00 c01ce0d8 00000003 c36bba3c c36bb940 c36bb978
b960: c010e298 c011373c 60000013 ffffffff
[<c0100b0c>] (__irq_svc) from [<c011373c>] (unwind_frame+0x0/0x870)
[<c011373c>] (unwind_frame) from [<00000000>] (0x0)

The buggy address belongs to the page:
page:(ptrval) refcount:0 mapcount:0 mapping:00000000 index:0x0 pfn:0x636bb
flags: 0x0()
raw: 00000000 00000000 ef867764 00000000 00000000 00000000 ffffffff 00000000
page dumped because: kasan: bad access detected

addr c36bba90 is located in stack of task cat/163 at offset 48 in frame:
 stack_trace_save+0x0/0xb4

this frame has 1 object:
 [32, 48) 'trace'

Memory state around the buggy address:
 c36bb980: f1 f1 f1 f1 00 04 f2 f2 00 00 f3 f3 00 00 00 00
 c36bba00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
>c36bba80: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
                 ^
 c36bbb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c36bbb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================

There is a same issue on x86 and has been resolved by the commit f7d27c3
("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to arm architecture too.

Signed-off-by: Lin Yujun <linyujun809@huawei.com>
Reported-by: He Ying <heying24@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ariffjenong pushed a commit to ariffjenong/android_kernel_sony_msm8998 that referenced this pull request Dec 16, 2022
@703joko
ARM: 9191/1: arm/stacktrace, kasan: Silence KASAN warnings in unwind_…
00d283c 
…frame()

[ Upstream commit 9be4c88bb7924f68f88cfd47d925c2d046f51a73 ]

The following KASAN warning is detected by QEMU.

==================================================================
BUG: KASAN: stack-out-of-bounds in unwind_frame+0x508/0x870
Read of size 4 at addr c36bba90 by task cat/163

CPU: 1 PID: 163 Comm: cat Not tainted 5.10.0-rc1 whatawurst#40
Hardware name: ARM-Versatile Express
[<c0113fac>] (unwind_backtrace) from [<c010e71c>] (show_stack+0x10/0x14)
[<c010e71c>] (show_stack) from [<c0b805b4>] (dump_stack+0x98/0xb0)
[<c0b805b4>] (dump_stack) from [<c0b7d658>] (print_address_description.constprop.0+0x58/0x4bc)
[<c0b7d658>] (print_address_description.constprop.0) from [<c031435c>] (kasan_report+0x154/0x170)
[<c031435c>] (kasan_report) from [<c0113c44>] (unwind_frame+0x508/0x870)
[<c0113c44>] (unwind_frame) from [<c010e298>] (__save_stack_trace+0x110/0x134)
[<c010e298>] (__save_stack_trace) from [<c01ce0d8>] (stack_trace_save+0x8c/0xb4)
[<c01ce0d8>] (stack_trace_save) from [<c0313520>] (kasan_set_track+0x38/0x60)
[<c0313520>] (kasan_set_track) from [<c0314cb8>] (kasan_set_free_info+0x20/0x2c)
[<c0314cb8>] (kasan_set_free_info) from [<c0313474>] (__kasan_slab_free+0xec/0x120)
[<c0313474>] (__kasan_slab_free) from [<c0311e20>] (kmem_cache_free+0x7c/0x334)
[<c0311e20>] (kmem_cache_free) from [<c01c35dc>] (rcu_core+0x390/0xccc)
[<c01c35dc>] (rcu_core) from [<c01013a8>] (__do_softirq+0x180/0x518)
[<c01013a8>] (__do_softirq) from [<c0135214>] (irq_exit+0x9c/0xe0)
[<c0135214>] (irq_exit) from [<c01a40e4>] (__handle_domain_irq+0xb0/0x110)
[<c01a40e4>] (__handle_domain_irq) from [<c0691248>] (gic_handle_irq+0xa0/0xb8)
[<c0691248>] (gic_handle_irq) from [<c0100b0c>] (__irq_svc+0x6c/0x94)
Exception stack(0xc36bb928 to 0xc36bb970)
b920:                   c36bb9c0 00000000 c0126919 c0101228 c36bb9c0 b76d7730
b940: c36b8000 c36bb9a0 c3335b00 c01ce0d8 00000003 c36bba3c c36bb940 c36bb978
b960: c010e298 c011373c 60000013 ffffffff
[<c0100b0c>] (__irq_svc) from [<c011373c>] (unwind_frame+0x0/0x870)
[<c011373c>] (unwind_frame) from [<00000000>] (0x0)

The buggy address belongs to the page:
page:(ptrval) refcount:0 mapcount:0 mapping:00000000 index:0x0 pfn:0x636bb
flags: 0x0()
raw: 00000000 00000000 ef867764 00000000 00000000 00000000 ffffffff 00000000
page dumped because: kasan: bad access detected

addr c36bba90 is located in stack of task cat/163 at offset 48 in frame:
 stack_trace_save+0x0/0xb4

this frame has 1 object:
 [32, 48) 'trace'

Memory state around the buggy address:
 c36bb980: f1 f1 f1 f1 00 04 f2 f2 00 00 f3 f3 00 00 00 00
 c36bba00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
>c36bba80: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
                 ^
 c36bbb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c36bbb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================

There is a same issue on x86 and has been resolved by the commit f7d27c3
("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to arm architecture too.

Signed-off-by: Lin Yujun <linyujun809@huawei.com>
Reported-by: He Ying <heying24@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ariffjenong pushed a commit to ariffjenong/android_kernel_sony_msm8998 that referenced this pull request Dec 16, 2022
@703joko
ARM: 9191/1: arm/stacktrace, kasan: Silence KASAN warnings in unwind_…
37c3288 
…frame()

[ Upstream commit 9be4c88bb7924f68f88cfd47d925c2d046f51a73 ]

The following KASAN warning is detected by QEMU.

==================================================================
BUG: KASAN: stack-out-of-bounds in unwind_frame+0x508/0x870
Read of size 4 at addr c36bba90 by task cat/163

CPU: 1 PID: 163 Comm: cat Not tainted 5.10.0-rc1 whatawurst#40
Hardware name: ARM-Versatile Express
[<c0113fac>] (unwind_backtrace) from [<c010e71c>] (show_stack+0x10/0x14)
[<c010e71c>] (show_stack) from [<c0b805b4>] (dump_stack+0x98/0xb0)
[<c0b805b4>] (dump_stack) from [<c0b7d658>] (print_address_description.constprop.0+0x58/0x4bc)
[<c0b7d658>] (print_address_description.constprop.0) from [<c031435c>] (kasan_report+0x154/0x170)
[<c031435c>] (kasan_report) from [<c0113c44>] (unwind_frame+0x508/0x870)
[<c0113c44>] (unwind_frame) from [<c010e298>] (__save_stack_trace+0x110/0x134)
[<c010e298>] (__save_stack_trace) from [<c01ce0d8>] (stack_trace_save+0x8c/0xb4)
[<c01ce0d8>] (stack_trace_save) from [<c0313520>] (kasan_set_track+0x38/0x60)
[<c0313520>] (kasan_set_track) from [<c0314cb8>] (kasan_set_free_info+0x20/0x2c)
[<c0314cb8>] (kasan_set_free_info) from [<c0313474>] (__kasan_slab_free+0xec/0x120)
[<c0313474>] (__kasan_slab_free) from [<c0311e20>] (kmem_cache_free+0x7c/0x334)
[<c0311e20>] (kmem_cache_free) from [<c01c35dc>] (rcu_core+0x390/0xccc)
[<c01c35dc>] (rcu_core) from [<c01013a8>] (__do_softirq+0x180/0x518)
[<c01013a8>] (__do_softirq) from [<c0135214>] (irq_exit+0x9c/0xe0)
[<c0135214>] (irq_exit) from [<c01a40e4>] (__handle_domain_irq+0xb0/0x110)
[<c01a40e4>] (__handle_domain_irq) from [<c0691248>] (gic_handle_irq+0xa0/0xb8)
[<c0691248>] (gic_handle_irq) from [<c0100b0c>] (__irq_svc+0x6c/0x94)
Exception stack(0xc36bb928 to 0xc36bb970)
b920:                   c36bb9c0 00000000 c0126919 c0101228 c36bb9c0 b76d7730
b940: c36b8000 c36bb9a0 c3335b00 c01ce0d8 00000003 c36bba3c c36bb940 c36bb978
b960: c010e298 c011373c 60000013 ffffffff
[<c0100b0c>] (__irq_svc) from [<c011373c>] (unwind_frame+0x0/0x870)
[<c011373c>] (unwind_frame) from [<00000000>] (0x0)

The buggy address belongs to the page:
page:(ptrval) refcount:0 mapcount:0 mapping:00000000 index:0x0 pfn:0x636bb
flags: 0x0()
raw: 00000000 00000000 ef867764 00000000 00000000 00000000 ffffffff 00000000
page dumped because: kasan: bad access detected

addr c36bba90 is located in stack of task cat/163 at offset 48 in frame:
 stack_trace_save+0x0/0xb4

this frame has 1 object:
 [32, 48) 'trace'

Memory state around the buggy address:
 c36bb980: f1 f1 f1 f1 00 04 f2 f2 00 00 f3 f3 00 00 00 00
 c36bba00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
>c36bba80: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
                 ^
 c36bbb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c36bbb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================

There is a same issue on x86 and has been resolved by the commit f7d27c3
("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to arm architecture too.

Signed-off-by: Lin Yujun <linyujun809@huawei.com>
Reported-by: He Ying <heying24@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ariffjenong pushed a commit to ariffjenong/android_kernel_sony_msm8998 that referenced this pull request Dec 16, 2022
@703joko
ARM: 9191/1: arm/stacktrace, kasan: Silence KASAN warnings in unwind_…
a8e9075 
…frame()

[ Upstream commit 9be4c88bb7924f68f88cfd47d925c2d046f51a73 ]

The following KASAN warning is detected by QEMU.

==================================================================
BUG: KASAN: stack-out-of-bounds in unwind_frame+0x508/0x870
Read of size 4 at addr c36bba90 by task cat/163

CPU: 1 PID: 163 Comm: cat Not tainted 5.10.0-rc1 whatawurst#40
Hardware name: ARM-Versatile Express
[<c0113fac>] (unwind_backtrace) from [<c010e71c>] (show_stack+0x10/0x14)
[<c010e71c>] (show_stack) from [<c0b805b4>] (dump_stack+0x98/0xb0)
[<c0b805b4>] (dump_stack) from [<c0b7d658>] (print_address_description.constprop.0+0x58/0x4bc)
[<c0b7d658>] (print_address_description.constprop.0) from [<c031435c>] (kasan_report+0x154/0x170)
[<c031435c>] (kasan_report) from [<c0113c44>] (unwind_frame+0x508/0x870)
[<c0113c44>] (unwind_frame) from [<c010e298>] (__save_stack_trace+0x110/0x134)
[<c010e298>] (__save_stack_trace) from [<c01ce0d8>] (stack_trace_save+0x8c/0xb4)
[<c01ce0d8>] (stack_trace_save) from [<c0313520>] (kasan_set_track+0x38/0x60)
[<c0313520>] (kasan_set_track) from [<c0314cb8>] (kasan_set_free_info+0x20/0x2c)
[<c0314cb8>] (kasan_set_free_info) from [<c0313474>] (__kasan_slab_free+0xec/0x120)
[<c0313474>] (__kasan_slab_free) from [<c0311e20>] (kmem_cache_free+0x7c/0x334)
[<c0311e20>] (kmem_cache_free) from [<c01c35dc>] (rcu_core+0x390/0xccc)
[<c01c35dc>] (rcu_core) from [<c01013a8>] (__do_softirq+0x180/0x518)
[<c01013a8>] (__do_softirq) from [<c0135214>] (irq_exit+0x9c/0xe0)
[<c0135214>] (irq_exit) from [<c01a40e4>] (__handle_domain_irq+0xb0/0x110)
[<c01a40e4>] (__handle_domain_irq) from [<c0691248>] (gic_handle_irq+0xa0/0xb8)
[<c0691248>] (gic_handle_irq) from [<c0100b0c>] (__irq_svc+0x6c/0x94)
Exception stack(0xc36bb928 to 0xc36bb970)
b920:                   c36bb9c0 00000000 c0126919 c0101228 c36bb9c0 b76d7730
b940: c36b8000 c36bb9a0 c3335b00 c01ce0d8 00000003 c36bba3c c36bb940 c36bb978
b960: c010e298 c011373c 60000013 ffffffff
[<c0100b0c>] (__irq_svc) from [<c011373c>] (unwind_frame+0x0/0x870)
[<c011373c>] (unwind_frame) from [<00000000>] (0x0)

The buggy address belongs to the page:
page:(ptrval) refcount:0 mapcount:0 mapping:00000000 index:0x0 pfn:0x636bb
flags: 0x0()
raw: 00000000 00000000 ef867764 00000000 00000000 00000000 ffffffff 00000000
page dumped because: kasan: bad access detected

addr c36bba90 is located in stack of task cat/163 at offset 48 in frame:
 stack_trace_save+0x0/0xb4

this frame has 1 object:
 [32, 48) 'trace'

Memory state around the buggy address:
 c36bb980: f1 f1 f1 f1 00 04 f2 f2 00 00 f3 f3 00 00 00 00
 c36bba00: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
>c36bba80: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
                 ^
 c36bbb00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 c36bbb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==================================================================

There is a same issue on x86 and has been resolved by the commit f7d27c3
("x86/mm, kasan: Silence KASAN warnings in get_wchan()").
The solution could be applied to arm architecture too.

Signed-off-by: Lin Yujun <linyujun809@huawei.com>
Reported-by: He Ying <heying24@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@Flamefire @derfelot @macpaul-lin-mtk