lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <e8b9ce41-57b9-b6e2-a46a-ff9c791cf0ba@gmail.com>
Date:   Tue, 21 Dec 2021 05:48:34 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
Cc:     netdev@...r.kernel.org, edumazet@...gle.com
Subject: [bridge] sane minimal values for
 multicast_query_interval/multicast_startup_query_interval

Hi Nikolay

I was looking at a syzbot report, crashing a host simply by creating

hundreds of bridge devices, with IFLA_BR_MCAST_QUERY_INTVL set to 0.


For each bridge device, br_multicast_send_query() is invoked 1000 times 
per second (on HZ=1000 build) and machine eventually crashes hard.


What would be a reasonable minimal value for 
multicast_query_interval/multicast_startup_query_interval,

and should we enforce some kind of global rate limit to avoid future 
syzbot reports ?

INFO: rcu detected stall in br_multicast_query_expired

rcu: INFO: rcu_preempt self-detected stall on CPU
rcu:    0-...!: (1 GPs behind) idle=6eb/1/0x4000000000000000 
softirq=14214/14215 fqs=16
         (t=10500 jiffies g=15505 q=102699)
rcu: rcu_preempt kthread starved for 9059 jiffies! g15505 f0x0 
RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=1
rcu:    Unless rcu_preempt kthread gets sufficient CPU time, OOM is now 
expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt     state:R  running task     stack:28688 pid: 14 
ppid:     2 flags:0x00004000


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ