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
| ||
|
Date: Mon, 13 Jan 2014 15:18:55 -0800 (PST) From: David Miller <davem@...emloft.net> To: vfalico@...hat.com Cc: netdev@...r.kernel.org, jiri@...nulli.us, edumazet@...gle.com, alexander.h.duyck@...el.com, nicolas.dichtel@...nd.com Subject: Re: [PATCH net-next] net: make dev_set_mtu() honor notification return code From: Veaceslav Falico <vfalico@...hat.com> Date: Fri, 10 Jan 2014 13:48:17 +0100 > Currently, after changing the MTU for a device, dev_set_mtu() calls > NETDEV_CHANGEMTU notification, however doesn't verify it's return code - > which can be NOTIFY_BAD - i.e. some of the net notifier blocks refused this > change, and continues nevertheless. > > To fix this, verify the return code, and if it's an error - then revert the > MTU to the original one, and pass the error code. > > Signed-off-by: Veaceslav Falico <vfalico@...hat.com> This is really a precariously designed code path. If one of the notifiers says NOTIFY_BAD, well we've already changed dev->mtu, therefore what if a packet got sent during this time? Whoever the NOTIFY_BAD signaller is, obviously cannot handle an MTU setting which we've already set in the netdev. So allowing it's a terribly idea to allow visibility of the new MTU value until we can be sure everyone can handle it. The problem is that we really need a transaction of some sort to fix this properly. First, we'd need to ask all the notifiers if they can handle the new MTU, then we somehow atomically set netdev->mtu and have the notifiers commit their own state changes. Then we'll have the stick issue of what to do if a notifier is unregistered between the check and the commit. :-) Your patch is an improvement so I will apply it, this stuff really is full of holes still. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists