Hello Sona, Please see the inline feedback from NXP SDK team.
Best Regards, Zhenhua From: Sona Sarmadi [mailto:[email protected]] Sent: Thursday, August 18, 2016 2:14 AM To: [email protected] Cc: Ting Liu <[email protected]>; 'Luo Zhenhua' <[email protected]>; 'Liu Ting' <[email protected]>; Jennifer Mir <[email protected]>; Thomas Lundström <[email protected]> Subject: Etherleak detected from NESSUS security scan Hi guys, Nessus scan reports a vulnerability in the FSL/NXP DPAA Linux Ethernet driver (on P2041, linux-qoriq-sdk/3.8-r11.1): [Luo Zhenhua] May I know which SDK is used? There have been more than one SDK based on 3.8? Has this scanner been run against a system running SDK 2.0? Can it be? Which MAC type (dtsec or tgec) was this seen with? Is there any information about specific packet data it saw? Scan report: 11197 - Multiple Ethernet Driver Frame Padding Information Disclosure (Etherleak) Synopsis The remote host appears to leak memory in network packets. Description The remote host uses a network device driver that pads ethernet frames with data which vary from one packet to another, likely taken from kernel memory, system memory allocated to the device driver, or a hardware buffer on its network interface card. Known as 'Etherleak', this information disclosure vulnerability may allow an attacker to collect sensitive information from the affected host provided he is on the same physical subnet as that host. See Also http://www.nessus.org/u?719c90b4 Solution Contact the network device driver's vendor for a fix. Risk Factor Low CVSS Base Score 3.3 (CVSS2#AV:A/AC:L/Au:N/C:P/I:N/A:N) CVSS Temporal Score 2.9 (CVSS2#E:ND/RL:OF/RC:C) References BID 6535 CVE CVE-2003-0001 According to NVD this vulnerability affects Linux kernel 2.4.1 - 2.4.9 (cpe:/o:linux:linux_kernel:2.4.9) but it seems that this vulnerability exist in the 3.8 kernel (according to Nessus scan). References: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2003-0001) Example of ethernet driver patch can be found at: https://www.cs.helsinki.fi/linux/linux-kernel/2003-06/1091.html The "etherleak_fix" is fixed in drivers/net/net_init.c: void ether_setup /* New-style flags. */ dev->flags = IFF_BROADCAST|IFF_MULTICAST; + + /* TBD: xmit_hook should ideally be part of "net_device" struct */ + netif_xmit_hook = etherleak_fix; <<<<<<<<<<<<<<<<< + [Luo Zhenhua] No, it's not. That was a proposed fix but what was actually done was to fix individual drivers. https://www.cs.helsinki.fi/linux/linux-kernel/2003-06/1091.html https://www.cs.helsinki.fi/linux/linux-kernel/2003-06/1153.html I need to confirm that the FSL driver is handling padding properly, could you please help me with this? There seems to be no software padding, instead I assume the HW is doing the padding. Is this correct? [Luo Zhenhua] Yes Is this where the HW is configured to do the padding? linux-qoriq-sdk/3.8-r11.1/git# vim drivers/net/ethernet/freescale/dpa/mac-api.c .. if (macdev2enetinterface(mac_dev) != e_ENET_MODE_XGMII_10000) { /* 10G always works with pad and CRC */ _errno = fm_mac_config_pad_and_crc(priv->fm_mac, true); [Luo Zhenhua] Unless things were different in "3.8-r11.1" compared to SDK 2.0, this call has no effect because all three MAC types default to having this enabled. For DTSEC padding is enabled by MACCFG2[PAD/CRC] which is set in fman_dtsec_init(). For TGEC the source code claims that it always pads, though from a quick search I couldn't find an explicit statement of that in the hardware documentation. linux-qoriq-sdk/3.8-r11.1/git# vim drivers/net/ethernet/freescale/fman/src/wrapper/lnxwrp_fm.c ... int fm_mac_config_pad_and_crc(struct fm_mac_dev *fm_mac_dev, bool enable) { int err; int _errno; err = FM_MAC_ConfigPadAndCrc(fm_mac_dev, enable); _errno = -GET_ERROR_TYPE(err); if (unlikely(_errno < 0)) pr_err("FM_MAC_ConfigPadAndCrc() = 0x%08x\n", err); return _errno; } Thanks //Sona
-- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
