5.13 / 5.14 #60

hyder365 · 2021-07-26T18:48:07Z

Linux 5.14 is on rc3 as of right now, and linux-hardened still doesn't have a 5.13 patch. Is there a reason the 5.13 branch (one month old) is being skipped? Thanks.

anthraxx · 2021-07-27T10:19:27Z

Yes, because the port is incomplete. Feel free to participate, primarily the "slub: add multi-purpose random canaries" fails during boot.

Bernhard40 · 2021-08-12T17:13:00Z

Should offending patch be temporarily reverted then?

hyder365 · 2021-08-12T18:13:01Z

Should offending patch be temporarily reverted then?

This seems to happen with every mainline release. Can anyone speak as to when the last attempt to upstream the overall patchset was? Or any part of it? Time has shown that this is a losing game, with the people left vulnerable for weeks/months being the real losers.

anthraxx · 2021-08-12T18:41:29Z

@hyder365 how about you contribute then? I'm sick of all the vampires taking all the work for free without giving back but choose all possibility to cry a river. It's a massive time investment here that im doing on top of my day job for free. Use the LTS tags. If you dont like it, and dont want to contribute to make it better or faster, dont use it.

@Bernhard40 5.13 is nearly finished, test workspaces boot and seem to function, most likely the release will be during the weekend

tsautereau-anssi · 2021-08-12T19:40:10Z

For the record and for people that really want to help us instead of just complaining, 5.13 is particularly annoying due to KASAN changes – see da844b787245 and d57a964e09c2 — that conflict with SLUB hardenings in linux-hardened. This is actually not the first time. By the way, 5.12 brought KFENCE, which is a bit problematic too especially with slab canaries, and we're still not set on the best way to handle that.

Nowadays I'd say that the bulk of linux-hardened is in mm/slab.h and mm/slub.c, so you could start by looking at what patches do to those files. The more people understand these changes, the more they can help us for each rebase and the quicker linux-hardened will be ready after each mainline release.

We're doing what we can to maintain this patchset, when we have time for it. People that are not satisfied with this work and don't help can always fork linux-hardened or just stop using it and go back to running vanilla, but they're not entitled to anything here.

anthraxx · 2021-08-18T00:59:16Z

We have finished and synced up the remaining work for 5.13. I have tagged an RC1 pre-release which I will give some more real world workload (and invite for a quick test) before moving on to stable releases.

https://github.com/anthraxx/linux-hardened/releases/tag/5.13-hardened1-rc1

hardfalcon · 2021-08-18T20:25:40Z

I've built kernel 5.13.12 with your 5.13-hardened1-rc1 patch, but the system (a VM booting in BIOS mode) hangs without any error message immediately after booting. I'm unsure if this is expected/a known issue or not, or if I'm overlooking something, so I figured putting a comment about it into here wouldn't hurt. :)

I've built the kernel using archbuild from the devtools package with testing repos enabled, using the current linux-hardened PKGBUILD from Archlinux with the following additional changes:

patch line SUBLEVEL = 0 changed to SUBLEVEL = 12
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.13/mtd-cfi_cmdset_0002-fix-crash-when-erasing-writing-amd-cards.patch (applied prior to your 5.13-hardened1-rc1 patch)
export MAKEFLAGS="${MAKEFLAGS} -j16"
unchanged config compared to 5.12.17/5.12.19 (but the config gets obviously updated automatically during the build process)

anthraxx · 2021-08-19T17:58:12Z

@hardfalcon can you check with CONFIG_SLAB_CANARY disabled? If that works, can you check vanilla 5.13.12 with the slab canary patch cherry-picked?

karesmakro · 2021-08-20T11:16:22Z

on a debian 11 with gcc version 10.2.1 it is working fine!
Thank you

h4xor666 · 2021-08-21T00:03:03Z

FWIW, don't know if this will help @hardfalcon, but the INIT_ON_FREE_DEFAULT_ON option was causing my 5.13.12 kernel not to boot, though I can't say for certain that there wasn't something else possibly conflicting with it.

anthraxx · 2021-08-21T00:26:13Z

@h4xor666 both have the very same root cause. disabling init_on_free just doesn't overwrite the canary with zero. The latest rc2 addresses this issue and should work with SLAB_CANARY and INIT_ON_FREE_DEFAULT_ON
https://github.com/anthraxx/linux-hardened/releases/tag/5.13-hardened1-rc2

karesmakro · 2021-08-21T10:24:48Z

sorry to say, rc2 ist not working for me. I can't see any message, boot process fails after os welcome message

edit: forgot to say, that it's a kvm based virtual machine and os is Debian 11 (bullseye)

h4xor666 · 2021-08-21T18:19:40Z

Sadly, no luck with rc2. Only thing I changed was the init_on_free_default_on option, still won't boot. I'll try and find logs of some sort.

anthraxx · 2021-08-23T15:09:54Z

@karesmakro @h4xor666 please try rc3 🐈

karesmakro · 2021-08-23T17:38:35Z

my system was booting successfully! No problems so far.

beaglesnuf · 2021-08-25T14:36:08Z

Installed across several Debian PCs and notebooks. All bootable, syslogs for the past two days look good (no different than vanilla). 5.13.12.

anthraxx · 2021-08-26T20:53:48Z

5.13.13-hardened1 has been released and the 5.14 branch is based on v5.14-rc7 and ready for testing

beaglesnuf · 2021-08-31T04:25:52Z

Just to be clear, to test the 5.14 branch, we should downloaded the full tree as source to build? Or is there a Github specific way to generate a diff patch against upstream 5.14?

kernelOfTruth · 2021-09-04T04:51:39Z

Just to be clear, to test the 5.14 branch, we should downloaded the full tree as source to build? Or is there a Github specific way to generate a diff patch against upstream 5.14?

https://github.com/anthraxx/linux-hardened/compare/7aeadb5bb82ad21ffbcd54c81d77727b7a05e6c1..1779bf4e8af6df4bf587980370fcf61f4235a2cb.diff

as example of 5.13: this would be for 5.13.13-hardened1 , thus against linux 5.13.13

https://github.com/anthraxx/linux-hardened/compare/7aeadb5bb82ad21ffbcd54c81d77727b7a05e6c1..1779bf4e8af6df4bf587980370fcf61f4235a2cb

where 7aeadb5 is the base commit for Linux 5.13.13

and 1779bf4 is at Linux hardened 5.13.13-hardened1

edit:

for 5.14

it would be

https://github.com/anthraxx/linux-hardened/compare/7d2a07b769330c34b4deabeed939325c77a7ec2f..e3bb405d91431e286c9dac2ad3ca33505bd8269d.diff

https://github.com/anthraxx/linux-hardened/compare/7d2a07b769330c34b4deabeed939325c77a7ec2f..e3bb405d91431e286c9dac2ad3ca33505bd8269d

7d2a07b is base commit for Linux 5.14

e3bb405 the current (WIP ?) commit state of 5.14-hardened0

references:

https://www.codegrepper.com/code-examples/shell/compare+two+commits+github

[ Upstream commit 04d8066 ] Currently, with an unknown recv_type, mwifiex_usb_recv just return -1 without restoring the skb. Next time mwifiex_usb_rx_complete is invoked with the same skb, calling skb_put causes skb_over_panic. The bug is triggerable with a compromised/malfunctioning usb device. After applying the patch, skb_over_panic no longer shows up with the same input. Attached is the panic report from fuzzing. skbuff: skb_over_panic: text:000000003bf1b5fa len:2048 put:4 head:00000000dd6a115b data:000000000a9445d8 tail:0x844 end:0x840 dev:<NULL> kernel BUG at net/core/skbuff.c:109! invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 PID: 198 Comm: in:imklog Not tainted 5.6.0 #60 RIP: 0010:skb_panic+0x15f/0x161 Call Trace: <IRQ> ? mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb] skb_put.cold+0x24/0x24 mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb] __usb_hcd_giveback_urb+0x1e4/0x380 usb_giveback_urb_bh+0x241/0x4f0 ? __hrtimer_run_queues+0x316/0x740 ? __usb_hcd_giveback_urb+0x380/0x380 tasklet_action_common.isra.0+0x135/0x330 __do_softirq+0x18c/0x634 irq_exit+0x114/0x140 smp_apic_timer_interrupt+0xde/0x380 apic_timer_interrupt+0xf/0x20 </IRQ> Reported-by: Brendan Dolan-Gavitt <[email protected]> Signed-off-by: Zekun Shen <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>

commit 8b59b0a upstream. arm32 uses software to simulate the instruction replaced by kprobe. some instructions may be simulated by constructing assembly functions. therefore, before executing instruction simulation, it is necessary to construct assembly function execution environment in C language through binding registers. after kasan is enabled, the register binding relationship will be destroyed, resulting in instruction simulation errors and causing kernel panic. the kprobe emulate instruction function is distributed in three files: actions-common.c actions-arm.c actions-thumb.c, so disable KASAN when compiling these files. for example, use kprobe insert on cap_capable+20 after kasan enabled, the cap_capable assembly code is as follows: <cap_capable>: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e1a05000 mov r5, r0 e280006c add r0, r0, #108 ; 0x6c e1a04001 mov r4, r1 e1a06002 mov r6, r2 e59fa090 ldr sl, [pc, #144] ; ebfc7bf8 bl c03aa4b4 <__asan_load4> e595706c ldr r7, [r5, #108] ; 0x6c e2859014 add r9, r5, #20 ...... The emulate_ldr assembly code after enabling kasan is as follows: c06f1384 <emulate_ldr>: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e282803c add r8, r2, #60 ; 0x3c e1a05000 mov r5, r0 e7e37855 ubfx r7, r5, #16, #4 e1a00008 mov r0, r8 e1a09001 mov r9, r1 e1a04002 mov r4, r2 ebf35462 bl c03c6530 <__asan_load4> e357000f cmp r7, #15 e7e36655 ubfx r6, r5, #12, #4 e205a00f and sl, r5, #15 0a000001 beq c06f13bc <emulate_ldr+0x38> e0840107 add r0, r4, r7, lsl #2 ebf3545c bl c03c6530 <__asan_load4> e084010a add r0, r4, sl, lsl #2 ebf3545a bl c03c6530 <__asan_load4> e2890010 add r0, r9, #16 ebf35458 bl c03c6530 <__asan_load4> e5990010 ldr r0, [r9, #16] e12fff30 blx r0 e356000f cm r6, #15 1a000014 bne c06f1430 <emulate_ldr+0xac> e1a06000 mov r6, r0 e2840040 add r0, r4, #64 ; 0x40 ...... when running in emulate_ldr to simulate the ldr instruction, panic occurred, and the log is as follows: Unable to handle kernel NULL pointer dereference at virtual address 00000090 pgd = ecb46400 [00000090] *pgd=2e0fa003, *pmd=00000000 Internal error: Oops: 206 [#1] SMP ARM PC is at cap_capable+0x14/0xb0 LR is at emulate_ldr+0x50/0xc0 psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 32c5387d Table: 2d546400 DAC: 55555555 Process bash (pid: 1643, stack limit = 0xecd60190) (cap_capable) from (kprobe_handler+0x218/0x340) (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) (do_undefinstr) from (__und_svc_finish+0x0/0x30) (__und_svc_finish) from (cap_capable+0x18/0xb0) (cap_capable) from (cap_vm_enough_memory+0x38/0x48) (cap_vm_enough_memory) from (security_vm_enough_memory_mm+0x48/0x6c) (security_vm_enough_memory_mm) from (copy_process.constprop.5+0x16b4/0x25c8) (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) (_do_fork) from (SyS_clone+0x1c/0x24) (SyS_clone) from (__sys_trace_return+0x0/0x10) Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7) Fixes: 35aa1df ("ARM kprobes: instruction single-stepping support") Fixes: 4210157 ("ARM: 9017/2: Enable KASan for ARM") Signed-off-by: huangshaobo <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit 04d8066 ] Currently, with an unknown recv_type, mwifiex_usb_recv just return -1 without restoring the skb. Next time mwifiex_usb_rx_complete is invoked with the same skb, calling skb_put causes skb_over_panic. The bug is triggerable with a compromised/malfunctioning usb device. After applying the patch, skb_over_panic no longer shows up with the same input. Attached is the panic report from fuzzing. skbuff: skb_over_panic: text:000000003bf1b5fa len:2048 put:4 head:00000000dd6a115b data:000000000a9445d8 tail:0x844 end:0x840 dev:<NULL> kernel BUG at net/core/skbuff.c:109! invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 PID: 198 Comm: in:imklog Not tainted 5.6.0 #60 RIP: 0010:skb_panic+0x15f/0x161 Call Trace: <IRQ> ? mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb] skb_put.cold+0x24/0x24 mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb] __usb_hcd_giveback_urb+0x1e4/0x380 usb_giveback_urb_bh+0x241/0x4f0 ? __hrtimer_run_queues+0x316/0x740 ? __usb_hcd_giveback_urb+0x380/0x380 tasklet_action_common.isra.0+0x135/0x330 __do_softirq+0x18c/0x634 irq_exit+0x114/0x140 smp_apic_timer_interrupt+0xde/0x380 apic_timer_interrupt+0xf/0x20 </IRQ> Reported-by: Brendan Dolan-Gavitt <[email protected]> Signed-off-by: Zekun Shen <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>

commit 8b59b0a upstream. arm32 uses software to simulate the instruction replaced by kprobe. some instructions may be simulated by constructing assembly functions. therefore, before executing instruction simulation, it is necessary to construct assembly function execution environment in C language through binding registers. after kasan is enabled, the register binding relationship will be destroyed, resulting in instruction simulation errors and causing kernel panic. the kprobe emulate instruction function is distributed in three files: actions-common.c actions-arm.c actions-thumb.c, so disable KASAN when compiling these files. for example, use kprobe insert on cap_capable+20 after kasan enabled, the cap_capable assembly code is as follows: <cap_capable>: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e1a05000 mov r5, r0 e280006c add r0, r0, #108 ; 0x6c e1a04001 mov r4, r1 e1a06002 mov r6, r2 e59fa090 ldr sl, [pc, #144] ; ebfc7bf8 bl c03aa4b4 <__asan_load4> e595706c ldr r7, [r5, #108] ; 0x6c e2859014 add r9, r5, #20 ...... The emulate_ldr assembly code after enabling kasan is as follows: c06f1384 <emulate_ldr>: e92d47f0 push {r4, r5, r6, r7, r8, r9, sl, lr} e282803c add r8, r2, #60 ; 0x3c e1a05000 mov r5, r0 e7e37855 ubfx r7, r5, #16, #4 e1a00008 mov r0, r8 e1a09001 mov r9, r1 e1a04002 mov r4, r2 ebf35462 bl c03c6530 <__asan_load4> e357000f cmp r7, #15 e7e36655 ubfx r6, r5, #12, #4 e205a00f and sl, r5, #15 0a000001 beq c06f13bc <emulate_ldr+0x38> e0840107 add r0, r4, r7, lsl #2 ebf3545c bl c03c6530 <__asan_load4> e084010a add r0, r4, sl, lsl #2 ebf3545a bl c03c6530 <__asan_load4> e2890010 add r0, r9, #16 ebf35458 bl c03c6530 <__asan_load4> e5990010 ldr r0, [r9, #16] e12fff30 blx r0 e356000f cm r6, #15 1a000014 bne c06f1430 <emulate_ldr+0xac> e1a06000 mov r6, r0 e2840040 add r0, r4, #64 ; 0x40 ...... when running in emulate_ldr to simulate the ldr instruction, panic occurred, and the log is as follows: Unable to handle kernel NULL pointer dereference at virtual address 00000090 pgd = ecb46400 [00000090] *pgd=2e0fa003, *pmd=00000000 Internal error: Oops: 206 [#1] SMP ARM PC is at cap_capable+0x14/0xb0 LR is at emulate_ldr+0x50/0xc0 psr: 600d0293 sp : ecd63af8 ip : 00000004 fp : c0a7c30c r10: 00000000 r9 : c30897f4 r8 : ecd63cd4 r7 : 0000000f r6 : 0000000a r5 : e59fa090 r4 : ecd63c98 r3 : c06ae294 r2 : 00000000 r1 : b7611300 r0 : bf4ec008 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 32c5387d Table: 2d546400 DAC: 55555555 Process bash (pid: 1643, stack limit = 0xecd60190) (cap_capable) from (kprobe_handler+0x218/0x340) (kprobe_handler) from (kprobe_trap_handler+0x24/0x48) (kprobe_trap_handler) from (do_undefinstr+0x13c/0x364) (do_undefinstr) from (__und_svc_finish+0x0/0x30) (__und_svc_finish) from (cap_capable+0x18/0xb0) (cap_capable) from (cap_vm_enough_memory+0x38/0x48) (cap_vm_enough_memory) from (security_vm_enough_memory_mm+0x48/0x6c) (security_vm_enough_memory_mm) from (copy_process.constprop.5+0x16b4/0x25c8) (copy_process.constprop.5) from (_do_fork+0xe8/0x55c) (_do_fork) from (SyS_clone+0x1c/0x24) (SyS_clone) from (__sys_trace_return+0x0/0x10) Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7) Fixes: 35aa1df ("ARM kprobes: instruction single-stepping support") Fixes: 4210157 ("ARM: 9017/2: Enable KASan for ARM") Signed-off-by: huangshaobo <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

yardenac · 2022-03-25T18:10:19Z

FWIW, thank you very much for all your hard work, and for pushing that 5.16 port. It's much appreciated!

[ Upstream commit 0ee7828 ] Since priv->rx_mapping[i] is maped in moxart_mac_open(), we should unmap it from moxart_mac_stop(). Fixes 2 warnings. 1. During error unwinding in moxart_mac_probe(): "goto init_fail;", then moxart_mac_free_memory() calls dma_unmap_single() with priv->rx_mapping[i] pointers zeroed. WARNING: CPU: 0 PID: 1 at kernel/dma/debug.c:963 check_unmap+0x704/0x980 DMA-API: moxart-ethernet 92000000.mac: device driver tries to free DMA memory it has not allocated [device address=0x0000000000000000] [size=1600 bytes] CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0+ #60 Hardware name: Generic DT based system unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0xbc/0x1f0 __warn from warn_slowpath_fmt+0x94/0xc8 warn_slowpath_fmt from check_unmap+0x704/0x980 check_unmap from debug_dma_unmap_page+0x8c/0x9c debug_dma_unmap_page from moxart_mac_free_memory+0x3c/0xa8 moxart_mac_free_memory from moxart_mac_probe+0x190/0x218 moxart_mac_probe from platform_probe+0x48/0x88 platform_probe from really_probe+0xc0/0x2e4 2. After commands: ip link set dev eth0 down ip link set dev eth0 up WARNING: CPU: 0 PID: 55 at kernel/dma/debug.c:570 add_dma_entry+0x204/0x2ec DMA-API: moxart-ethernet 92000000.mac: cacheline tracking EEXIST, overlapping mappings aren't supported CPU: 0 PID: 55 Comm: ip Not tainted 5.19.0+ #57 Hardware name: Generic DT based system unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0xbc/0x1f0 __warn from warn_slowpath_fmt+0x94/0xc8 warn_slowpath_fmt from add_dma_entry+0x204/0x2ec add_dma_entry from dma_map_page_attrs+0x110/0x328 dma_map_page_attrs from moxart_mac_open+0x134/0x320 moxart_mac_open from __dev_open+0x11c/0x1ec __dev_open from __dev_change_flags+0x194/0x22c __dev_change_flags from dev_change_flags+0x14/0x44 dev_change_flags from devinet_ioctl+0x6d4/0x93c devinet_ioctl from inet_ioctl+0x1ac/0x25c v1 -> v2: Extraneous change removed. Fixes: 6c821bd ("net: Add MOXA ART SoCs ethernet driver") Signed-off-by: Sergei Antonov <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 90e5b34 ] When flushing, individual set elements are disabled in the next generation via the ->flush callback. Catchall elements are not disabled. This is incorrect and may lead to double-deactivations of catchall elements which then results in memory leaks: WARNING: CPU: 1 PID: 3300 at include/net/netfilter/nf_tables.h:1172 nft_map_deactivate+0x549/0x730 CPU: 1 PID: 3300 Comm: nft Not tainted 6.5.0-rc5+ #60 RIP: 0010:nft_map_deactivate+0x549/0x730 [..] ? nft_map_deactivate+0x549/0x730 nf_tables_delset+0xb66/0xeb0 (the warn is due to nft_use_dec() detecting underflow). Fixes: aaa3104 ("netfilter: nftables: add catch-all set element support") Reported-by: lonial con <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 60f07e2 ] We use uprobe in aarch64_be, which we found the tracee task would exit due to SIGILL when we enable the uprobe trace. We can see the replace inst from uprobe is not correct in aarch big-endian. As in Armv8-A, instruction fetches are always treated as little-endian, we should treat the UPROBE_SWBP_INSN as little-endian。 The test case is as following。 bash-4.4# ./mqueue_test_aarchbe 1 1 2 1 10 > /dev/null & bash-4.4# cd /sys/kernel/debug/tracing/ bash-4.4# echo 'p:test /mqueue_test_aarchbe:0xc30 %x0 %x1' > uprobe_events bash-4.4# echo 1 > events/uprobes/enable bash-4.4# bash-4.4# ps PID TTY TIME CMD 140 ? 00:00:01 bash 237 ? 00:00:00 ps [1]+ Illegal instruction ./mqueue_test_aarchbe 1 1 2 1 100 > /dev/null which we debug use gdb as following: bash-4.4# gdb attach 155 (gdb) disassemble send Dump of assembler code for function send: 0x0000000000400c30 <+0>: .inst 0xa00020d4 ; undefined 0x0000000000400c34 <+4>: mov x29, sp 0x0000000000400c38 <+8>: str w0, [sp, #28] 0x0000000000400c3c <+12>: strb w1, [sp, #27] 0x0000000000400c40 <+16>: str xzr, [sp, #40] 0x0000000000400c44 <+20>: str xzr, [sp, #48] 0x0000000000400c48 <+24>: add x0, sp, #0x1b 0x0000000000400c4c <+28>: mov w3, #0x0 // #0 0x0000000000400c50 <+32>: mov x2, #0x1 // #1 0x0000000000400c54 <+36>: mov x1, x0 0x0000000000400c58 <+40>: ldr w0, [sp, #28] 0x0000000000400c5c <+44>: bl 0x405e10 <mq_send> 0x0000000000400c60 <+48>: str w0, [sp, #60] 0x0000000000400c64 <+52>: ldr w0, [sp, #60] 0x0000000000400c68 <+56>: ldp x29, x30, [sp], #64 0x0000000000400c6c <+60>: ret End of assembler dump. (gdb) info b No breakpoints or watchpoints. (gdb) c Continuing. Program received signal SIGILL, Illegal instruction. 0x0000000000400c30 in send () (gdb) x/10x 0x400c30 0x400c30 <send>: 0xd42000a0 0xfd030091 0xe01f00b9 0xe16f0039 0x400c40 <send+16>: 0xff1700f9 0xff1b00f9 0xe06f0091 0x03008052 0x400c50 <send+32>: 0x220080d2 0xe10300aa (gdb) disassemble 0x400c30 Dump of assembler code for function send: => 0x0000000000400c30 <+0>: .inst 0xa00020d4 ; undefined 0x0000000000400c34 <+4>: mov x29, sp 0x0000000000400c38 <+8>: str w0, [sp, #28] 0x0000000000400c3c <+12>: strb w1, [sp, #27] 0x0000000000400c40 <+16>: str xzr, [sp, #40] Signed-off-by: junhua huang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Stable-dep-of: 13f8f1e ("arm64: probes: Fix uprobes for big-endian kernels") Signed-off-by: Sasha Levin <[email protected]>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

5.13 / 5.14 #60

5.13 / 5.14 #60

hyder365 commented Jul 26, 2021

anthraxx commented Jul 27, 2021

Bernhard40 commented Aug 12, 2021

hyder365 commented Aug 12, 2021

anthraxx commented Aug 12, 2021 •

edited

Loading

tsautereau-anssi commented Aug 12, 2021

anthraxx commented Aug 18, 2021

hardfalcon commented Aug 18, 2021 •

edited

Loading

anthraxx commented Aug 19, 2021

karesmakro commented Aug 20, 2021

h4xor666 commented Aug 21, 2021

anthraxx commented Aug 21, 2021 •

edited

Loading

karesmakro commented Aug 21, 2021 •

edited

Loading

h4xor666 commented Aug 21, 2021

anthraxx commented Aug 23, 2021

karesmakro commented Aug 23, 2021

beaglesnuf commented Aug 25, 2021 •

edited

Loading

anthraxx commented Aug 26, 2021

beaglesnuf commented Aug 31, 2021

kernelOfTruth commented Sep 4, 2021 •

edited

Loading

yardenac commented Mar 25, 2022

5.13 / 5.14 #60

5.13 / 5.14 #60

Comments

hyder365 commented Jul 26, 2021

anthraxx commented Jul 27, 2021

Bernhard40 commented Aug 12, 2021

hyder365 commented Aug 12, 2021

anthraxx commented Aug 12, 2021 • edited Loading

tsautereau-anssi commented Aug 12, 2021

anthraxx commented Aug 18, 2021

hardfalcon commented Aug 18, 2021 • edited Loading

anthraxx commented Aug 19, 2021

karesmakro commented Aug 20, 2021

h4xor666 commented Aug 21, 2021

anthraxx commented Aug 21, 2021 • edited Loading

karesmakro commented Aug 21, 2021 • edited Loading

h4xor666 commented Aug 21, 2021

anthraxx commented Aug 23, 2021

karesmakro commented Aug 23, 2021

beaglesnuf commented Aug 25, 2021 • edited Loading

anthraxx commented Aug 26, 2021

beaglesnuf commented Aug 31, 2021

kernelOfTruth commented Sep 4, 2021 • edited Loading

yardenac commented Mar 25, 2022

anthraxx commented Aug 12, 2021 •

edited

Loading

hardfalcon commented Aug 18, 2021 •

edited

Loading

anthraxx commented Aug 21, 2021 •

edited

Loading

karesmakro commented Aug 21, 2021 •

edited

Loading

beaglesnuf commented Aug 25, 2021 •

edited

Loading

kernelOfTruth commented Sep 4, 2021 •

edited

Loading