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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <573B0676.30500@mojatatu.com>
Date:	Tue, 17 May 2016 07:54:30 -0400
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Daniel Borkmann <daniel@...earbox.net>, stephen@...workplumber.org
Cc:	tgraf@...g.ch, netdev@...r.kernel.org
Subject: Re: [PATCH iproute2 -next] ingress, clsact: don't add TCA_OPTIONS to
 nl msg

On 16-05-15 12:36 PM, Daniel Borkmann wrote:
> In ingress and clsact qdisc TCA_OPTIONS are ignored, since it's
> parameterless. In tc, we add an empty addattr_l(... TCA_OPTIONS,
> NULL, 0) to the netlink message nevertheless. This has the
> side effect that when someone tries a 'tc qdisc replace' and
> already an existing such qdisc is present, tc fails with
> EINVAL here.
>
> Reason is that in the kernel, this invokes qdisc_change() when
> such requested qdisc is already present. When TCA_OPTIONS are
> passed to modify parameters, it looks whether qdisc implements
> .change() callback, and if not present (like in both cases here)
> it returns with error. Rather than adding an empty stub to the
> kernel that ignores TCA_OPTIONS again, just don't add TCA_OPTIONS
> to the netlink message in the first place.
>
> Before:
>
>    # tc qdisc replace dev foo clsact    # first try
>    # tc qdisc replace dev foo clsact    # second one
>    RTNETLINK answers: Invalid argument
>
> After:
>
>    # tc qdisc replace dev foo clsact
>    # tc qdisc replace dev foo clsact
>    # tc qdisc replace dev foo clsact
>
> Signed-off-by: Daniel Borkmann <daniel@...earbox.net>

Acked-by: Jamal Hadi Salim <jhs@...atatu.com>

I see need for correctness but was curious of use case
that made you even look at this ;->

cheers,
jamal


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ