Hi Ido,
> Do you differentiate between IPv4 and IPv6 in batman-adv?
For most things, yes: The querier state is kept separately for
IPv4 and IPv6. And we do have something like a "router node"
flag to signalize that a node needs all multicast traffic, which
is split into IPv4 and IPv6.
The "MDB"
Hi Nikolay
The man page says that the bridge forward_delay is in units of
seconds, and should be between 2 and 30.
I've tested on a couple of different kernel versions, and this appears
to be not working correctly:
ip link set br0 type bridge forward_delay 2
RTNETLINK answers: Numerical result
> Hi Andrew,
> The man page is wrong, these have been in USER_HZ scaled clock_t format from
> the beginning.
> TBH a lot of the time/delay bridge config options are messed up like that.
Hi Nikola
Yes, that is a mess.
arch/alpha/include/asm/param.h:# define USER_HZ
On 02/07/2019 23:47, Andrew Lunn wrote:
> Hi Nikolay
>
> The man page says that the bridge forward_delay is in units of
> seconds, and should be between 2 and 30.
>
> I've tested on a couple of different kernel versions, and this appears
> to be not working correctly:
>
> ip link set br0 type
From: Nikolay Aleksandrov
Date: Tue, 2 Jul 2019 15:00:17 +0300
> In the bridge driver we have a couple of places which call pskb_may_pull
> but we've cached skb pointers before that and use them after which can
> lead to out-of-bounds/stale pointer use. I've had these in my "to fix"
> list for
On Sun, Jun 30, 2019 at 06:56:01PM +0200, Linus Lüssing wrote:
> > On Sun, Jun 23, 2019 at 10:44:27AM +0300, Ido Schimmel wrote:
> > > See commit b00589af3b04 ("bridge: disable snooping if there is no
> > > querier"). I think that's unfortunate behavior that we need because
> > > multicast
On 30/06/2019 19:56, Linus Lüssing wrote:
> On Sat, Jun 29, 2019 at 07:29:45PM +0300, Ido Schimmel wrote:
>> I would like to avoid having drivers take the querier state into account
>> as it will only complicate things further.
>
> I absolutely share your pain. Initially in the early prototypes
Tested-by: Martin Weinelt
On 7/2/19 2:00 PM, Nikolay Aleksandrov wrote:
> We get a pointer to the ipv6 hdr in br_ip6_multicast_query but we may
> call pskb_may_pull afterwards and end up using a stale pointer.
> So use the header directly, it's just 1 place where it's needed.
>
> Fixes:
Tested-by: Martin Weinelt
On 7/2/19 2:00 PM, Nikolay Aleksandrov wrote:
> We take a pointer to grec prior to calling pskb_may_pull and use it
> afterwards to get nsrcs so record nsrcs before the pull when handling
> igmp3 and we get a pointer to nsrcs and call pskb_may_pull when handling
> mld2
We would cache ether dst pointer on input in br_handle_frame_finish but
after the neigh suppress code that could lead to a stale pointer since
both ipv4 and ipv6 suppress code do pskb_may_pull. This means we have to
always reload it after the suppress code so there's no point in having
it cached
Hi,
In the bridge driver we have a couple of places which call pskb_may_pull
but we've cached skb pointers before that and use them after which can
lead to out-of-bounds/stale pointer use. I've had these in my "to fix"
list for some time and now we got a report (patch 01) so here they are.
Patches
We get a pointer to the ipv6 hdr in br_ip6_multicast_query but we may
call pskb_may_pull afterwards and end up using a stale pointer.
So use the header directly, it's just 1 place where it's needed.
Fixes: 08b202b67264 ("bridge br_multicast: IPv6 MLD support.")
Signed-off-by: Nikolay Aleksandrov
We take a pointer to grec prior to calling pskb_may_pull and use it
afterwards to get nsrcs so record nsrcs before the pull when handling
igmp3 and we get a pointer to nsrcs and call pskb_may_pull when handling
mld2 which again could lead to reading 2 bytes out-of-bounds.
Don't cache eth dest pointer before calling pskb_may_pull.
Fixes: cf0f02d04a83 ("[BRIDGE]: use llc for receiving STP packets")
Signed-off-by: Nikolay Aleksandrov
---
net/bridge/br_stp_bpdu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/bridge/br_stp_bpdu.c
On 2019/06/28 20:02, Johannes Berg wrote:
On Mon, 2019-06-17 at 20:15 +0900, Toshiaki Makita wrote:
I'll try to explain the problem I see, which cannot be fixed by option 1...
The bug is in tcf_vlan_act(), and mainly in skb->data, not in mac_len.
Consider about vlan packets from NIC, but
Hi Nik,
On 7/2/19 12:37 AM, Nikolay Aleksandrov wrote:
> On 7/2/19 1:17 AM, Martin Weinelt wrote:
>> Hi again,
>>
>> On 7/1/19 7:37 PM, Nikolay Aleksandrov wrote:
>>> I see, thanks for clarifying this. So on the KASAN could you please try the
>>> attached patch ?
>>> Also could you please run
16 matches
Mail list logo
