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  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]
Date:   Mon, 20 Jul 2020 17:01:09 +0000
From:   "Sriram Krishnan (srirakr2)" <>
To:     Willem de Bruijn <>,
        Stephen Hemminger <>
CC:     Andrew Morton <>,
        "xe-linux-external(mailer list)" <>,
        "David S. Miller" <>,
        Jakub Kicinski <>,
        Network Development <>,
        linux-kernel <>,
        "Malcolm Bumgardner (mbumgard)" <>,
        "Umesha G M (ugm)" <>,
        "Niranjan M M (nimm)" <>,
        "Daniel Walker (danielwa)" <>
Subject: Re: [PATCH v2] AF_PACKET doesnt strip VLAN information

I have moved the code to the driver and pushed a new patch due to the below highlighted issues.

Stephen H,
Please let me know if you have any concerns localising the changes to the netvsc driver.


´╗┐On 20/07/20, 7:23 PM, "Willem de Bruijn" <> wrote:

    On Mon, Jul 20, 2020 at 12:27 AM Sriram Krishnan (srirakr2)
    <> wrote:
    > +Stephen Hemminger
    > Hi Willem,
    > Thanks for looking into the code, I understand that this is more of a generic problem wherein many of the filtering functions assume the vlan tag to be in the skb rather than in the packet. Hence we moved the fix from the driver to the common AF packet that our solution uses.
    > I recall from the v1 of the patch you had mentioned other common areas where this fix might be relevant (such as tap/tun), but I'm afraid I cant comprehensively test those patches out. Please let me know your thoughts

    Please use plain text to respond. HTML replies do not reach the list.

    Can you be more precise in which other code besides the hyper-v driver
    is affected? Do you have an example?

    This is a resubmit of the original patch. My previous
    questions/concerns remain valid:

    - if the function can now fail, all callers must be updated to detect
    and handle that

    - any solution should probably address all inputs into the tx path:
    packet sockets, tuntap, virtio-net

    - this only addresses packet sockets with ETH_P_ALL/ETH_P_NONE. Not
    sockets that set ETH_P_8021Q

    - which code in the transmit stack requires the tag to be in the skb,
    and does this problem after this patch still persist for Q-in-Q?

Powered by blists - more mailing lists