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

-Wunneeded-internal-declaration in arch/arm/crypto/aes-ce-glue.c #56

Closed
agners opened this issue Sep 13, 2018 · 5 comments
Closed

-Wunneeded-internal-declaration in arch/arm/crypto/aes-ce-glue.c #56

agners opened this issue Sep 13, 2018 · 5 comments
Labels
-Wunneeded-internal-declaration [ARCH] arm32 This bug impacts ARCH=arm [BUG] linux A bug that should be fixed in the mainline kernel. [FIXED][LINUX] 4.20 This bug was fixed in Linux 4.20

Comments

@agners
Copy link

agners commented Sep 13, 2018 •
edited by nathanchance

v4.19-rc1 shows a new warning:

arch/arm/crypto/aes-ce-glue.c:450:1: warning: variable 'cpu_feature_match_AES' is not needed and will not be emitted [-Wunneeded-internal-declaration]                                                             
module_cpu_feature_match(AES, aes_init);                                                                                                                                                                           
^                                                                                                                                                                                                                  
./include/linux/cpufeature.h:48:33: note: expanded from macro 'module_cpu_feature_match'                                                                                                                           
static struct cpu_feature const cpu_feature_match_ ## x[] =     \                                                                                                                                                  
                                ^
<scratch space>:83:1: note: expanded from here
cpu_feature_match_AES
^

Also raised with the offending commit: https://lore.kernel.org/r/CAKv+Gu_J0s4gcdVQOQ96dD7kpNj=po83wT0BRiiiYR9pu=e0aw@mail.gmail.com/
@agners agners added [BUG] linux A bug that should be fixed in the mainline kernel. low priority This bug is not critical and not a priority [ARCH] arm32 This bug impacts ARCH=arm labels Sep 13, 2018
@nickdesaulniers
Copy link
Member

I feel like I've backported @mkaehlcke 's patches for this kind of warning before...

@nathanchance
Copy link
Member

nathanchance commented Sep 15, 2018 •
edited

Ard's follow up: https://lore.kernel.org/r/CAKv+Gu-Ej0HAanaN3KLrbfVz4VMpR-vhh958tUszgBR+BFg0Gg@mail.gmail.com/

@nathanchance
Copy link
Member

Patches currently in -next

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c785896b21dd8e156326ff660050b0074d3431df

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=cd560235d8f9ddd94aa51e1c4dabdf3212b9b241

@nathanchance nathanchance added the [PATCH] Accepted A submitted patch has been accepted upstream label Sep 26, 2018
@tpimh
Copy link

tpimh commented Oct 27, 2018

Both are in 4.20: c785896 cd56023

@tpimh tpimh closed this as completed Oct 27, 2018
@tpimh tpimh added [FIXED][LINUX] 4.20 This bug was fixed in Linux 4.20 and removed [PATCH] Accepted A submitted patch has been accepted upstream low priority This bug is not critical and not a priority labels Oct 27, 2018
@nickdesaulniers
Copy link
Member

possibly also fixed on the llvm side by #232

nathanchance pushed a commit that referenced this issue May 8, 2019
@dsahern @davem330
ipv6: Initialize fib6_result in bpf_ipv6_fib_lookup
e55449e 
fib6_result is not initialized in bpf_ipv6_fib_lookup and potentially
passses garbage to the fib lookup which triggers a KASAN warning:

[  262.055450] ==================================================================
[  262.057640] BUG: KASAN: user-memory-access in fib6_rule_suppress+0x4b/0xce
[  262.059488] Read of size 8 at addr 00000a20000000b0 by task swapper/1/0
[  262.061238]
[  262.061673] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.1.0-rc5+ #56
[  262.063493] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.1-1 04/01/2014
[  262.065593] Call Trace:
[  262.066277]  <IRQ>
[  262.066848]  dump_stack+0x7e/0xbb
[  262.067764]  kasan_report+0x18b/0x1b5
[  262.069921]  __asan_load8+0x7f/0x81
[  262.070879]  fib6_rule_suppress+0x4b/0xce
[  262.071980]  fib_rules_lookup+0x275/0x2cd
[  262.073090]  fib6_lookup+0x119/0x218
[  262.076457]  bpf_ipv6_fib_lookup+0x39d/0x664
...

Initialize fib6_result to 0.

Fixes: b1d4099 ("ipv6: Rename fib6_multipath_select and pass fib6_result")
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
nathanchance pushed a commit that referenced this issue Dec 22, 2019
@stefano-garzarella @davem330
vsock/virtio: fix null-pointer dereference in virtio_transport_recv_l…
df18fa1 
…isten()

With multi-transport support, listener sockets are not bound to any
transport. So, calling virtio_transport_reset(), when an error
occurs, on a listener socket produces the following null-pointer
dereference:

  BUG: kernel NULL pointer dereference, address: 00000000000000e8
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 0 P4D 0
  Oops: 0000 [#1] SMP PTI
  CPU: 0 PID: 20 Comm: kworker/0:1 Not tainted 5.5.0-rc1-ste-00003-gb4be21f316ac-dirty #56
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
  Workqueue: virtio_vsock virtio_transport_rx_work [vmw_vsock_virtio_transport]
  RIP: 0010:virtio_transport_send_pkt_info+0x20/0x130 [vmw_vsock_virtio_transport_common]
  Code: 1f 84 00 00 00 00 00 0f 1f 00 55 48 89 e5 41 57 41 56 41 55 49 89 f5 41 54 49 89 fc 53 48 83 ec 10 44 8b 76 20 e8 c0 ba fe ff <48> 8b 80 e8 00 00 00 e8 64 e3 7d c1 45 8b 45 00 41 8b 8c 24 d4 02
  RSP: 0018:ffffc900000b7d08 EFLAGS: 00010282
  RAX: 0000000000000000 RBX: ffff88807bf12728 RCX: 0000000000000000
  RDX: ffff88807bf12700 RSI: ffffc900000b7d50 RDI: ffff888035c84000
  RBP: ffffc900000b7d40 R08: ffff888035c84000 R09: ffffc900000b7d08
  R10: ffff8880781de800 R11: 0000000000000018 R12: ffff888035c84000
  R13: ffffc900000b7d50 R14: 0000000000000000 R15: ffff88807bf12724
  FS:  0000000000000000(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00000000000000e8 CR3: 00000000790f4004 CR4: 0000000000160ef0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   virtio_transport_reset+0x59/0x70 [vmw_vsock_virtio_transport_common]
   virtio_transport_recv_pkt+0x5bb/0xe50 [vmw_vsock_virtio_transport_common]
   ? detach_buf_split+0xf1/0x130
   virtio_transport_rx_work+0xba/0x130 [vmw_vsock_virtio_transport]
   process_one_work+0x1c0/0x300
   worker_thread+0x45/0x3c0
   kthread+0xfc/0x130
   ? current_work+0x40/0x40
   ? kthread_park+0x90/0x90
   ret_from_fork+0x35/0x40
  Modules linked in: sunrpc kvm_intel kvm vmw_vsock_virtio_transport vmw_vsock_virtio_transport_common irqbypass vsock virtio_rng rng_core
  CR2: 00000000000000e8
  ---[ end trace e75400e2ea2fa824 ]---

This happens because virtio_transport_reset() calls
virtio_transport_send_pkt_info() that can be used only on
connecting/connected sockets.

This patch fixes the issue, using virtio_transport_reset_no_sock()
instead of virtio_transport_reset() when we are handling a listener
socket.

Fixes: c0cfa2d ("vsock: add multi-transports support")
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
-Wunneeded-internal-declaration [ARCH] arm32 This bug impacts ARCH=arm [BUG] linux A bug that should be fixed in the mainline kernel. [FIXED][LINUX] 4.20 This bug was fixed in Linux 4.20
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@agners @tpimh @nickdesaulniers @nathanchance