kernel panic: audit: backlog limit exceeded
by syzbot
Hello,
syzbot found the following crash on:
HEAD commit: 36a44bcd Merge branch 'bnxt_en-shutdown-and-kexec-kdump-re..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=148bfdd9e00000
kernel config: https://syzkaller.appspot.com/x/.config?x=768cc3d3e277cc16
dashboard link: https://syzkaller.appspot.com/bug?extid=9a5e789e4725b9ef1316
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=151b1109e00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=128bfdd9e00000
The bug was bisected to:
commit 0c1b9970ddd4cc41002321c3877e7f91aacb896d
Author: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Fri Jul 28 14:42:27 2017 +0000
staging: lustre: lustre: Off by two in lmv_fid2path()
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17e6c3e9e00000
final crash: https://syzkaller.appspot.com/x/report.txt?x=1416c3e9e00000
console output: https://syzkaller.appspot.com/x/log.txt?x=1016c3e9e00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+9a5e789e4725b9ef1316(a)syzkaller.appspotmail.com
Fixes: 0c1b9970ddd4 ("staging: lustre: lustre: Off by two in lmv_fid2path()")
audit: audit_backlog=13 > audit_backlog_limit=7
audit: audit_lost=1 audit_rate_limit=0 audit_backlog_limit=7
Kernel panic - not syncing: audit: backlog limit exceeded
CPU: 1 PID: 9913 Comm: syz-executor024 Not tainted 5.6.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x197/0x210 lib/dump_stack.c:118
panic+0x2e3/0x75c kernel/panic.c:221
audit_panic.cold+0x32/0x32 kernel/audit.c:307
audit_log_lost kernel/audit.c:377 [inline]
audit_log_lost+0x8b/0x180 kernel/audit.c:349
audit_log_start kernel/audit.c:1788 [inline]
audit_log_start+0x70e/0x7c0 kernel/audit.c:1745
audit_log+0x95/0x120 kernel/audit.c:2345
xt_replace_table+0x61d/0x830 net/netfilter/x_tables.c:1413
__do_replace+0x1da/0x950 net/ipv6/netfilter/ip6_tables.c:1084
do_replace net/ipv6/netfilter/ip6_tables.c:1157 [inline]
do_ip6t_set_ctl+0x33a/0x4c8 net/ipv6/netfilter/ip6_tables.c:1681
nf_sockopt net/netfilter/nf_sockopt.c:106 [inline]
nf_setsockopt+0x77/0xd0 net/netfilter/nf_sockopt.c:115
ipv6_setsockopt net/ipv6/ipv6_sockglue.c:949 [inline]
ipv6_setsockopt+0x147/0x180 net/ipv6/ipv6_sockglue.c:933
tcp_setsockopt net/ipv4/tcp.c:3165 [inline]
tcp_setsockopt+0x8f/0xe0 net/ipv4/tcp.c:3159
sock_common_setsockopt+0x94/0xd0 net/core/sock.c:3149
__sys_setsockopt+0x261/0x4c0 net/socket.c:2130
__do_sys_setsockopt net/socket.c:2146 [inline]
__se_sys_setsockopt net/socket.c:2143 [inline]
__x64_sys_setsockopt+0xbe/0x150 net/socket.c:2143
do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x44720a
Code: 49 89 ca b8 37 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 1a e0 fb ff c3 66 0f 1f 84 00 00 00 00 00 49 89 ca b8 36 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 fa df fb ff c3 66 0f 1f 84 00 00 00 00 00
RSP: 002b:00007ffd032dec78 EFLAGS: 00000286 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 000000000044720a
RDX: 0000000000000040 RSI: 0000000000000029 RDI: 0000000000000003
RBP: 00007ffd032deda0 R08: 00000000000003b8 R09: 0000000000004000
R10: 00000000006d7b40 R11: 0000000000000286 R12: 00007ffd032deca0
R13: 00000000006d9d60 R14: 0000000000000029 R15: 00000000006d7ba0
Kernel Offset: disabled
Rebooting in 86400 seconds..
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller(a)googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
5 months, 2 weeks
[PATCH][next] batman-adv: Replace zero-length array with flexible-array member
by Gustavo A. R. Silva
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo(a)embeddedor.com>
---
net/batman-adv/distributed-arp-table.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/batman-adv/distributed-arp-table.c b/net/batman-adv/distributed-arp-table.c
index 3d21dd83f8cc..b85da4b7a77b 100644
--- a/net/batman-adv/distributed-arp-table.c
+++ b/net/batman-adv/distributed-arp-table.c
@@ -88,7 +88,7 @@ struct batadv_dhcp_packet {
__u8 sname[64];
__u8 file[128];
__be32 magic;
- __u8 options[0];
+ __u8 options[];
};
#define BATADV_DHCP_YIADDR_LEN sizeof(((struct batadv_dhcp_packet *)0)->yiaddr)
--
2.25.0
5 months, 2 weeks
Node AP's
by Zach Barnett
I looking for clarification about the following question
How can I connect non-mesh clients to my batman-adv network ?
Does this mean that for an existing batman node to allow non-mesh
clients to join (I.E. cell phone, wifi camera, etc..), then 2
interfaces are required?
For example, if I have a pi-zero W in a wooded area, and I want a
camera to connect to it, then do I need to add an additional usb
network adapter to the Pi. One Interface for the Bat0 Mesh and One
interface an an entry point for non-mesh clients.
any information is greatly appreciated.
Thanks
Zach
5 months, 2 weeks
KMSAN: uninit-value in batadv_get_vid
by syzbot
Hello,
syzbot found the following crash on:
HEAD commit: 8bbbc5cf kmsan: don't compile memmove
git tree: https://github.com/google/kmsan.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=15471109e00000
kernel config: https://syzkaller.appspot.com/x/.config?x=cd0e9a6b0e555cc3
dashboard link: https://syzkaller.appspot.com/bug?extid=0adb190024de0a0e265b
compiler: clang version 10.0.0 (https://github.com/llvm/llvm-project/ c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
userspace arch: i386
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1247c109e00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1349a779e00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+0adb190024de0a0e265b(a)syzkaller.appspotmail.com
=====================================================
BUG: KMSAN: uninit-value in batadv_get_vid+0x1fd/0x340 net/batman-adv/main.c:650
CPU: 0 PID: 12317 Comm: syz-executor026 Not tainted 5.6.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c9/0x220 lib/dump_stack.c:118
kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118
__msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
batadv_get_vid+0x1fd/0x340 net/batman-adv/main.c:650
batadv_interface_tx+0x30a/0x2450 net/batman-adv/soft-interface.c:212
__netdev_start_xmit include/linux/netdevice.h:4524 [inline]
netdev_start_xmit include/linux/netdevice.h:4538 [inline]
xmit_one net/core/dev.c:3470 [inline]
dev_hard_start_xmit+0x531/0xab0 net/core/dev.c:3486
__dev_queue_xmit+0x37de/0x4220 net/core/dev.c:4063
dev_queue_xmit+0x4b/0x60 net/core/dev.c:4096
__bpf_tx_skb net/core/filter.c:2061 [inline]
__bpf_redirect_common net/core/filter.c:2100 [inline]
__bpf_redirect+0x11d5/0x1440 net/core/filter.c:2107
____bpf_clone_redirect net/core/filter.c:2140 [inline]
bpf_clone_redirect+0x466/0x620 net/core/filter.c:2112
bpf_prog_bb15b996d00816f9+0x7a4/0x1000
bpf_dispatcher_nopfunc include/linux/bpf.h:521 [inline]
bpf_test_run+0x60c/0xe50 net/bpf/test_run.c:48
bpf_prog_test_run_skb+0xcab/0x24a0 net/bpf/test_run.c:388
bpf_prog_test_run kernel/bpf/syscall.c:2572 [inline]
__do_sys_bpf+0xa684/0x13510 kernel/bpf/syscall.c:3414
__se_sys_bpf kernel/bpf/syscall.c:3355 [inline]
__ia32_sys_bpf+0xdb/0x120 kernel/bpf/syscall.c:3355
do_syscall_32_irqs_on arch/x86/entry/common.c:339 [inline]
do_fast_syscall_32+0x3c7/0x6e0 arch/x86/entry/common.c:410
entry_SYSENTER_compat+0x68/0x77 arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7fc8d99
Code: 90 e8 0b 00 00 00 f3 90 0f ae e8 eb f9 8d 74 26 00 89 3c 24 c3 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:00000000ff9adc0c EFLAGS: 00000246 ORIG_RAX: 0000000000000165
RAX: ffffffffffffffda RBX: 000000000000000a RCX: 0000000020000280
RDX: 0000000000000040 RSI: 0000000000000000 RDI: 000000000000005b
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Uninit was created at:
kmsan_save_stack_with_flags mm/kmsan/kmsan.c:144 [inline]
kmsan_internal_poison_shadow+0x66/0xd0 mm/kmsan/kmsan.c:127
kmsan_slab_alloc+0x8a/0xe0 mm/kmsan/kmsan_hooks.c:82
slab_alloc_node mm/slub.c:2793 [inline]
__kmalloc_node_track_caller+0xb40/0x1200 mm/slub.c:4401
__kmalloc_reserve net/core/skbuff.c:142 [inline]
pskb_expand_head+0x20b/0x1b00 net/core/skbuff.c:1629
skb_ensure_writable+0x3ea/0x490 net/core/skbuff.c:5453
__bpf_try_make_writable net/core/filter.c:1635 [inline]
bpf_try_make_writable net/core/filter.c:1641 [inline]
bpf_try_make_head_writable net/core/filter.c:1649 [inline]
____bpf_clone_redirect net/core/filter.c:2134 [inline]
bpf_clone_redirect+0x251/0x620 net/core/filter.c:2112
bpf_prog_bb15b996d00816f9+0x7a4/0x1000
bpf_dispatcher_nopfunc include/linux/bpf.h:521 [inline]
bpf_test_run+0x60c/0xe50 net/bpf/test_run.c:48
bpf_prog_test_run_skb+0xcab/0x24a0 net/bpf/test_run.c:388
bpf_prog_test_run kernel/bpf/syscall.c:2572 [inline]
__do_sys_bpf+0xa684/0x13510 kernel/bpf/syscall.c:3414
__se_sys_bpf kernel/bpf/syscall.c:3355 [inline]
__ia32_sys_bpf+0xdb/0x120 kernel/bpf/syscall.c:3355
do_syscall_32_irqs_on arch/x86/entry/common.c:339 [inline]
do_fast_syscall_32+0x3c7/0x6e0 arch/x86/entry/common.c:410
entry_SYSENTER_compat+0x68/0x77 arch/x86/entry/entry_64_compat.S:139
=====================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller(a)googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
5 months, 3 weeks
Issue with bridging LAN and mesh network
by Emilie Meyer
Hi all
I have tried to set up a mesh network according to the following tutorial:
https://www.open-mesh.org/projects/batman-adv/wiki/Quick-start-guide
Everything goes well until the steps for creating a bridge between
eth0 and bat0.
When running the command as shown below, it fails.
root@OpenWrt:~# ip link set eth0 master mesh-bridge
ip: either "dev" is duplicate, or "master" is garbage
I suspect that the ip version (BusyBox v1.28.4) I got does not support bridging?
Sincerely hope that someone can please guide me to solve this issue.
This is my HW/SW:
HW: TP-Link TL-WR841N and Ubiquiti M2 Bullet
OpenWrt 18.06.4, r7808-ef686b7292
As you see I have not the newest HW so that's the reason why I have
initially tried to use OpenWrt version 18.06.4 and not the newest
version.
Anyone that have experience with Batman on these wifi devices, please share.
Many thanks in advance for your help.
--
Regards
Emilie
5 months, 3 weeks
Re: can't find logged information
by Steve Newcomb
On 2/7/20 9:51 AM, Simon Wunderlich wrote:
> On Friday, February 7, 2020 3:13:47 PM CET Steve Newcomb wrote:
>> @rpc152:/tmp/log# echo "$(logread)" | grep batman
>> Thu Feb 6 15:21:13 2020 kern.warn kernel: [174193.938445] batman_adv:
>> [Deprecated]: batctl (pid 22747) Use of debugfs file "nc_nodes".
>> @rpc152:/tmp/log#
>>
>>
>> What have I missed?
> Hi Steve,
>
> you can use "batctl log" to retrieve the log. It will not appear in your
> logread.
Alas, that doesn't work either, and I don't know why:
root@rpc152:~# batctl log
Error - no valid command or debug table specified: log
Usage: batctl [options] command|debug table [parameters]
options:
-h print this help (or 'batctl <command|debug table> -h' for
the parameter help)
-v print version
commands:
meshif <netdev> aggregation|ag [0|1] display or modify
aggregation setting
...
>
> When the problem happens, you can also check "iw wlan0 station dump"
> and other
> debug files (batctl n for neighbors) to find out if the WiFi layer is
> still
> working. It wouldn't be the first time that actually the WiFi chip or
> driver
> has a problem, not batman-adv.
I've seen that "batctl n" works, and "iw mesh0 station dump" works, too.
I am arranging for the nodes to send me such mail when things have gone
awry, but prior to rebooting. I've written a tiny mail queueing system
that optionally uses nonvolatile memory for the queue.
5 months, 3 weeks
Re: [PATCH maint] batman-adv: Don't schedule OGM for disabled interface
by Hillf Danton
On Mon, 17 Feb 2020 22:16:59 +0800 Sven Eckelmann wrote:
>
> A transmission scheduling for an interface which is currently dropped by
> batadv_iv_ogm_iface_disable could still be in progress. The B.A.T.M.A.N. V
> is simply cancelling the workqueue item in an synchronous way but this is
> not possible with B.A.T.M.A.N. IV because the OGM submissions are
> intertwined.
>
> Instead it has to stop submitting the OGM when it detect that the buffer
> pointer is set to NULL.
>
> Reported-by: syzbot+a98f2016f40b9cd3818a(a)syzkaller.appspotmail.com
> Reported-by: syzbot+ac36b6a33c28a491e929(a)syzkaller.appspotmail.com
> Fixes: c6c8fea29769 ("net: Add batman-adv meshing protocol")
> Signed-off-by: Sven Eckelmann <sven(a)narfation.org>
> ---
> Cc: Hillf Danton <hdanton(a)sina.com>
>
> I had this one in the pipeline but didn't find the time to correctly test
> it. You already send your one to syzkaller - do you want to rework your one
> (to also catch the broken submission on the same interface) and submit it?
> Or is this patch also ok for you? If it is, do you want to be mentioned in
Your work looks better, thanks :P
And a Cc is more than enough.
Hillf
> some way or form in this patch?
> ---
> net/batman-adv/bat_iv_ogm.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/batman-adv/bat_iv_ogm.c b/net/batman-adv/bat_iv_ogm.c
> index 5b0b20e6..bd514c36 100644
> --- a/net/batman-adv/bat_iv_ogm.c
> +++ b/net/batman-adv/bat_iv_ogm.c
> @@ -789,6 +789,10 @@ static void batadv_iv_ogm_schedule_buff(struct batadv_hard_iface *hard_iface)
>
> lockdep_assert_held(&hard_iface->bat_iv.ogm_buff_mutex);
>
> + /* interface already disabled in batadv_iv_ogm_iface_disable */
> + if (!*ogm_buff)
> + return;
> +
> /* the interface gets activated here to avoid race conditions between
> * the moment of activating the interface in
> * hardif_activate_interface() where the originator mac is set and
> --
> 2.20.1
5 months, 3 weeks
