Bugzilla – Bug 896015
VUL-0: CVE-2014-3535: kernel-source: netdevice.h: NULL pointer dereference over VxLAN
Last modified: 2014-09-12 09:40:06 UTC
via rh bugzilla A NULL pointer dereference flaw was found in the way the Linux kernel's networking implementation handled logging while processing certain invalid packets coming in via a VxLAN interface. A remote attacker could use this flaw to crash the system by sending a specially crafted packet to such an interface. References: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=256df2f3879efdb2e9808bdb1b54b16fbb11fa38 https://bugzilla.redhat.com/show_bug.cgi?id=1114540
Also an old fix from 2010, making SLES 11 SP2 or newer NOT affected.
SLE11-SP1* do not have a global netdev_printk. I assume the issue still might be there in a form of printk or dev_printk. The report doesn't say anything about the particular offender which doesn't make it easy to check whether we need a fix or not. I am not familiar with VxLAN at all. grep vxlan -ir drivers/net/ net/ doesn't yield to anything... Benjamin, could you help me out here, please?
Marcus, it would be great if we could get more information about the offender.
i mailed redhat for more details.
Maybe it's related to this commit, it touches netdevice.h, is related to vxlan and the timeframe between the commit and the RH report matches. 4b28252 net: Fix GSO constants to match NETIF flags (v3.16-rc1) However, I don't see how it leads to a null pointer dereference. drivers/net/vxlan.c has a few netdev_{dbg,info} messages but the original report leading up to that commit mentions no crashes, only that hardware offloads are not working as expected. http://thread.gmane.org/gmane.linux.network/319908 Moreover, I think that commit fixes a problem introduced just a few days earlier in 0f4f4ff. vxlan was introduced in d342894 vxlan: virtual extensible lan (v3.7-rc1) I don't think that "256df2f netdevice.h net/core/dev.c: Convert netdev_<level> logging macros to functions (v2.6.36-rc1)" is the fix for the problem, only that the stacktrace will point to a netdev_* function introduced by that commit.
bugbot adjusting priority
Thanks a lot Benjamin. That would suggest that none of our products are affected. If I understand you correctly then the whole CVE doesn't make much sense. Let's see whether Marcus gets any more information from RH.
netdev_printk() used to look up netdev->dev.parent unconditionally. After commit 256df2f, it checks for a null pointer: ... -#define netdev_printk(level, netdev, format, args...) \ - dev_printk(level, (netdev)->dev.parent, \ - "%s: " format, \ - netdev_name(netdev), ##args) ... +static int __netdev_printk(const char *level, const struct net_device *dev, + struct va_format *vaf) +{ + int r; + + if (dev && dev->dev.parent) + r = dev_printk(level, dev->dev.parent, "%s: %pV", + netdev_name(dev), vaf); ... and presumably vxlan sometimes passes a null net_device pointer. So I think this is only an issue for RHEL 6 because they backported vxlan and needed this change to make it safe.
Thanks a lot for confirmation Ben! This means that none of the SUSE products are affected. Getting back to suse-security and can be closed as invalid because it is RH only.
(In reply to comment #5) > I don't think that "256df2f netdevice.h net/core/dev.c: Convert netdev_<level> > logging macros to functions (v2.6.36-rc1)" is the fix for the problem, only > that the stacktrace will point to a netdev_* function introduced by that > commit. (In reply to comment #8) > netdev_printk() used to look up netdev->dev.parent unconditionally. After > commit 256df2f, it checks for a null pointer: Thank you for setting me straight.