Re: [PATCH] rtnetlink: fix data overflow in rtnl_calcit()

> On Fri, Oct 16, 2020 at 10:02:38AM +0800, zhudi wrote: > > "ip addr show" command execute error when we have a physical network > > card with number of VFs larger than 247. > > > > The return value of if_nlmsg_size() in rtnl_calcit() will exceed range > > of u16 data type when any network cards

答复: [PATCH] rtnetlink: fix data overflow in rtnl_calcit()

> > "ip addr show" command execute error when we have a physical network > > card with number of VFs larger than 247. > > Oh man, this bug has been hurting us forever and I've tried to fix it several > times without much luck, so thanks for working on it! > > CC: David Ahern > > As he's mention

Re: [PATCH] rtnetlink: fix data overflow in rtnl_calcit()

> On Sat, 17 Oct 2020 14:34:11 +0200 Michal Kubecek wrote: > > On Fri, Oct 16, 2020 at 10:02:38AM +0800, zhudi wrote: > > > "ip addr show" command execute error when we have a physical > network > > > card with number of VFs larger than 247. > > > > > > The return value of if_nlmsg_size() in rtnl_c

Re: [PATCH] net: fix a data race when get vlan device

> On 2021/4/17 20:33, zhudi (J) wrote: > >> On 2021/4/16 11:27, zhudi (J) wrote: > >>>> dependencyOn 2021/4/15 11:35, zhudi wrote: > >>>>> From: Di Zhu > >>>>> > >>>>> We encountered a crash: in the packet rece

Re: [PATCH] net: fix a data race when get vlan device

> dependencyOn 2021/4/15 11:35, zhudi wrote: > > From: Di Zhu > > > > We encountered a crash: in the packet receiving process, we got an > > illegal VLAN device address, but the VLAN device address saved in > > vmcore is correct. After checking the code, we found a possible data > > competition: >

Re: [PATCH] net: fix a data race when get vlan device

> On 2021/4/16 11:27, zhudi (J) wrote: > >> dependencyOn 2021/4/15 11:35, zhudi wrote: > >>> From: Di Zhu > >>> > >>> We encountered a crash: in the packet receiving process, we got an > >>> illegal VLAN device address, but the VLAN dev

Re: [PATCH] bonding: 3ad: fix a use-after-free in bond_3ad_state_machine_handle

> >From: Di Zhu > > > >I use the similar test method described in link below with KASAN enabled: > >https://lore.kernel.org/netdev/4c5e467e07fb410ab4135b391d663ec1@hua > wei. > >com/ > >soon after, KASAN reports: > >[ 9041.977110] > >= >

答复: [PATCH] net/sched: act_pedit: fix a NULL pointer deref in tcf_pedit_init

> > hello, thanks for the patch! > > On Tue, 2021-03-09 at 11:47 +0800, zhudi wrote: > > From: Di Zhu > > > > when we use syzkaller to fuzz-test our kernel, one NULL pointer > dereference > > BUG happened: > > > > Write of size 96 at addr 0010 by task syz-executor.0/22376 > > > =