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-next>] [day] [month] [year] [list]
Date:   Mon, 13 May 2019 15:05:28 +0000
From:   Maxim Mikityanskiy <maximmi@...lanox.com>
To:     "David S. Miller" <davem@...emloft.net>,
        Alexey Kuznetsov <kuznet@....inr.ac.ru>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Leon Romanovsky <leonro@...lanox.com>,
        Maxim Mikityanskiy <maximmi@...lanox.com>
Subject: [RFC] inet6_validate_link_af improvements

A recent bug in systemd [1] triggered the following kernel warning:

  A link change request failed with some changes committed already.
  Interface eth1 may have been left with an inconsistent configuration,
  please check.

do_setlink() performs multiple configuration updates, and if any of them
fails, do_setlink() has no way to revert the previous ones. It is also
not easy to validate everything in advance and perform a non-failing
update then. However, do_setlink() has some basic validation that can be
extended at least this case. IMO, it's better to fail before doing any
changes than to perform a partial configuration update.

This RFC contains two patches that move some checks to the validation
stage (inet6_validate_link_af() function). Only one of the patches (if
any) should be applied. Patch 1 only checks the presence of at least one
parameter, and patch 2 also moves the validation for addrgenmode that is
currently part of inet6_set_link_af(). Of course, there are still many
ways how do_setlink() can fail and perform a partial update, but IMO
it's better to prevent at least some cases that we can.

Please express your opinions on this fix: do we need it, do we want to
validate as much as possible (patch 2) or only basic stuff like the
presence of parameters (patch 1)? I'm looking forward to hearing the
feedback.

Thanks,
Max

[1]: https://github.com/systemd/systemd/issues/12504

-- 
2.19.1

Powered by blists - more mailing lists