Would it be possible for you to test the latest upstream stable kernel?
Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the
latest v4.4 stable kernel[0].

If this bug is fixed in the mainline kernel, please add the following
tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag:
'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, 
please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as 
"Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.4.145


** Changed in: linux (Ubuntu)
   Importance: Undecided => High

** Information type changed from Public to Private Security

** Tags added: kernel-key

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1784684

Title:
  Waste padding after PPPoE payload

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After a new Kernel e.g. 4.4.0-131 is installed on our Ubuntu 16.04 LTS
  clients, unneeded (waste) 14 bytes paddings are unexpectedly present
  after PPPoE payload in client's Ethernet frames which are sent towards
  a NAS access router. The content of such a waste padding is not all
  zero filled bytes, but rather parts of memory, sometimes with readable
  text. Thus it is also a security issue. Sometimes the waste padding is
  more than 14 bytes. For example, a PPPoED PADI frame (single tagged
  VLAN) with text "amf/application/12" (18 bytes) at the end of the
  frame shown as padding in Wireshark:

  0000   ff ff ff ff ff ff 00 0a cd 2a ea 9f 81 00 00 07   ÿÿÿÿÿÿ..Í*ê.....
  0010   88 63 11 09 00 00 00 0c 01 01 00 00 01 03 00 04   .c..............
  0020   d9 1f 00 00 61 6d 66 2f 61 70 70 6c 69 63 61 74   Ù...amf/applicat
  0030   69 6f 6e 2f 31 32                                 ion/12

  It is a critical bug of Kernel 4.4.0-131.

  Some affected client Ethernet frames are large enough (>64 bytes), and
  thus they do not need to be padded for Ethernet. Padding should be
  included and is required in Ethernet frames only to achieve the
  minimum 64 byte size of an Ethernet frame sent on wire. For a packet
  larger than e.g. 100 bytes no padding is needed in Ethernet frame.
  However we can see such 14 Byte paddings also in large client Ethernet
  frames (in PPPoE/PPP/IP session packets), with payload size of several
  hundred bytes (200, 300, 400 bytes and more).

  Our Ubuntu 16.04 LTS Clients are always updated via apt update / apt
  upgrade early enough, after a new Ubuntu update is released in
  Internet.

  Our statistics after analyzing the collected archived pcap traces of
  our clients with Ubuntu 16.04 LTS and the latest Kernel installed can
  help to identify the date and the version when the kernel bug first
  appeared:

  From 15.06.2018 to 29.06.2018 - still no waste padding on all clients (OK)
  02.07.2018 - OK, still no waste padding on all clients (OK)
  03.07.2018 - OK, still no waste padding on all clients (OK)
  04.07.2018 - OK, still no waste padding on all clients (OK)
  05.07.2018 - OK, still no waste padding on all clients (OK)
  06.07.2018 - OK, still no waste padding on all clients (OK)

  !!! Kernel Update to 4.4.0-131 on 09-Jul-2018 !!!

  09.07.2018 - 14 byte padding (PADI, PADR, etc) on all updated clients - a 
kernel BUG !
  10.07.2018 - 14 byte padding (PADI, PADR, etc) on all updated clients - a 
kernel BUG !
  12.07.2018 - 14 byte padding (PADI, PADR, etc) on all updated clients - a 
kernel BUG !
  13.07.2018 - 14 byte padding (PADI, PADR, etc) on all updated clients - a 
kernel BUG !
  19.07.2018 - 14 byte padding (PADI, PADR, etc) on all updated clients - a 
kernel BUG !
  ...

  So the padding issue occurred on our Ubuntu 16.04 LTS clients for the
  first time on 09-Jul-2018, after the Linux Kernel was updated to
  4.4.0-131. Since then, the issue is present on all the updated
  clients. The kernel bug disappeared and the padding behavior is OK
  again (without bug), after clients were downgraded to and booted with
  an older kernel version like e.g. 4.4.0-116 (older than 4.4.0-131).

  Information about the Ubuntu clients and the kernel version affected
  with this BUG:

  @client:~$ uname -a
  Linux client 4.4.0-131-generic #157-Ubuntu SMP Thu Jul 12 15:51:36 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  @client:~$ cat /proc/version_signature
  Ubuntu 4.4.0-131.157-generic 4.4.134

  @client:~$ lsb_release -rd
  Description:    Ubuntu 16.04.5 LTS
  Release:        16.04

  @client:~$ lsb_release -ci
  Distributor ID: Ubuntu
  Codename:       xenial

  The kernel bug does not occur and waste paddings (14 byte on single-
  stacked VLAN, 18 byte on double-stacked VLAN) are not present in
  client frames, if an old Kernel e.g. 4.4.0-116 (of 12-Feb-2018) is
  installed on the client and activated at boot time.

  This old kernel 4.4.0-116 is still without the padding bug:
  @client:~$ uname -a
  Linux client 4.4.0-116-generic #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  A PADI packet with unneeded padding is included as attachment. It was
  captured via tcpdump directly on the Ubuntu Client. It is a padding
  inserted by Ubuntu, not by the HW or driver. If it were a padding
  included by Ethernet adapter or driver to reach the minimum 64 byte
  frame size, we could not capture such real padding on the WAN
  interface of the same host and could not see such real padding of this
  client frame in Wireshark.

  The issue affects PPPoED client packets (PADI, PADR), PPP control
  client packets (e.g. LCP) and PPP session client packets (IPv4 /
  IPv6). We expect no padding is included after PPPoE payload in
  Ethernet frames if the packets are not small (>64 byte) and thus are
  not required to be padded for Ethernet. Such correct behavior (without
  waste paddings) can be observed on Ubuntu 16.04 LTS with old Kernel
  versions (like e.g. 4.4.0-116) released before July 2018.

  Please implement the fix in the next Kernel update.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784684/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to