~jdstrand/+git/linux:v4.15+-apparmor-backport-to-v4.14.72-presquash

Branch merges

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related charm recipes

dc4894e... by John Johansen on 2018-11-08

apparmor: 4.15 to 4.14 backport: Revert: treewide: Fix function prototypes

From 6f2c89c2deaf01e7febd0ac0e5038a60a1f035aa Mon Sep 17 00:00:00 2001
From: John Johansen <email address hidden>
Date: Thu, 15 Feb 2018 03:42:06 -0800
Subject: apparmor: 4.15 to 4.14 backport: Revert: treewide: Fix function
 prototypes

  Revert: e4dca7b7aa08 ("treewide: Fix function prototypes for module_param_call()")

Signed-off-by: John Johansen <email address hidden>
---
 security/apparmor/lsm.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

7e0db1e... by John Johansen on 2018-11-08

apparmor: af_unix mediation

From b81e4eb72c9bae291b2a8d800c8c77aca1b3b315 Mon Sep 17 00:00:00 2001
From: John Johansen <email address hidden>
Date: Tue, 18 Jul 2017 23:27:23 -0700
Subject: apparmor: af_unix mediation

af_socket mediation did not make it into 4.14 so add remaining out
of tree patch

Signed-off-by: John Johansen <email address hidden>
Signed-off-by: Seth Forshee <email address hidden>
---
 security/apparmor/Makefile | 3 +-
 security/apparmor/af_unix.c | 651 ++++++++++++++++++++++++++++++++++++
 security/apparmor/apparmorfs.c | 6 +
 security/apparmor/file.c | 4 +-
 security/apparmor/include/af_unix.h | 114 +++++++
 security/apparmor/include/net.h | 16 +-
 security/apparmor/include/path.h | 1 +
 security/apparmor/include/policy.h | 2 +-
 security/apparmor/lsm.c | 169 ++++++----
 security/apparmor/net.c | 174 +++++++++-
 10 files changed, 1072 insertions(+), 68 deletions(-)
 create mode 100644 security/apparmor/af_unix.c
 create mode 100644 security/apparmor/include/af_unix.h

144e316... by John Johansen on 2018-11-08

apparmor: add base infastructure for socket mediation

From e47e3faa8bbd33585f740536317eeb3ea371f45d Mon Sep 17 00:00:00 2001
From: John Johansen <email address hidden>
Date: Tue, 18 Jul 2017 23:18:33 -0700
Subject: apparmor: add base infastructure for socket mediation

Provide a basic mediation of sockets. This is not a full net mediation
but just whether a spcific family of socket can be used by an
application, along with setting up some basic infrastructure for
network mediation to follow.

the user space rule hav the basic form of
  NETWORK RULE = [ QUALIFIERS ] 'network' [ DOMAIN ]
                 [ TYPE | PROTOCOL ]

  DOMAIN = ( 'inet' | 'ax25' | 'ipx' | 'appletalk' | 'netrom' |
             'bridge' | 'atmpvc' | 'x25' | 'inet6' | 'rose' |
             'netbeui' | 'security' | 'key' | 'packet' | 'ash' |
             'econet' | 'atmsvc' | 'sna' | 'irda' | 'pppox' |
             'wanpipe' | 'bluetooth' | 'netlink' | 'unix' | 'rds' |
             'llc' | 'can' | 'tipc' | 'iucv' | 'rxrpc' | 'isdn' |
             'phonet' | 'ieee802154' | 'caif' | 'alg' | 'nfc' |
             'vsock' | 'mpls' | 'ib' | 'kcm' ) ','

  TYPE = ( 'stream' | 'dgram' | 'seqpacket' | 'rdm' | 'raw' |
           'packet' )

  PROTOCOL = ( 'tcp' | 'udp' | 'icmp' )

eg.
  network,
  network inet,

Signed-off-by: John Johansen <email address hidden>
Acked-by: Seth Arnold <email address hidden>
---
 security/apparmor/.gitignore | 1 +
 security/apparmor/Makefile | 43 ++++-
 security/apparmor/apparmorfs.c | 1 +
 security/apparmor/file.c | 30 +++
 security/apparmor/include/audit.h | 16 +-
 security/apparmor/include/net.h | 114 +++++++++++
 security/apparmor/include/perms.h | 5 +-
 security/apparmor/include/policy.h | 13 ++
 security/apparmor/lib.c | 5 +-
 security/apparmor/lsm.c | 387 +++++++++++++++++++++++++++++++++++++
 security/apparmor/net.c | 184 ++++++++++++++++++
 security/apparmor/policy_unpack.c | 51 ++++-
 12 files changed, 838 insertions(+), 12 deletions(-)
 create mode 100644 security/apparmor/include/net.h
 create mode 100644 security/apparmor/net.c

29c1de7... by John Johansen on 2018-11-08

apparmor: backport of apparmor from 4.15

From 7ba5bce6b65a4ed6e619018b29ef3ecc0b8c5c9f Mon Sep 17 00:00:00 2001
From: John Johansen <email address hidden>
Date: Thu, 15 Feb 2018 03:14:48 -0800
Subject: apparmor: backport of apparmor from 4.15

Signed-off-by: John Johansen <email address hidden>
---
 security/apparmor/apparmorfs.c | 24 +++++++-------
 security/apparmor/domain.c | 69 +++++++++++++++++++++++++++++----------
 security/apparmor/file.c | 8 +----
 security/apparmor/include/audit.h | 12 ++++---
 security/apparmor/include/lib.h | 13 +-------
 security/apparmor/include/perms.h | 3 ++
 security/apparmor/ipc.c | 53 ++++++++++++++++++------------
 security/apparmor/label.c | 10 +++---
 security/apparmor/lib.c | 16 +++------
 security/apparmor/lsm.c | 24 +++++++-------
 security/apparmor/mount.c | 25 +++++++++-----
 security/apparmor/policy.c | 11 ++++---
 security/apparmor/policy_ns.c | 8 ++---
 security/apparmor/policy_unpack.c | 2 +-
 security/apparmor/resource.c | 4 +--
 15 files changed, 159 insertions(+), 123 deletions(-)

dc87996... by Qian Lu <email address hidden> on 2018-11-08

Revert "<linux/stringhash.h>: fix end_name_hash() for 64bit long"

From 584ecccd70154ba14132e8ef3348bcbf0f986c02 Mon Sep 17 00:00:00 2001
From: Qian Lu <email address hidden>
Date: Thu, 20 Sep 2018 18:00:29 +0000
Subject: Revert "<linux/stringhash.h>: fix end_name_hash() for 64bit long"

This reverts commit 5cb0ba254fee3c3ef61a3c02892e010851bbf54f.

Commit 5cb0ba254fee ("<linux/stringhash.h>: fix end_name_hash() for 64bit
long") changes the order of the directory entries due to the usage of the
function in kernfs directory. So irqbalance builds its table in a different
way, which causes missing some IRQs.

Signed-off-by: Qian Lu <email address hidden>
Reviewed-by: Eduardo Valentin <email address hidden>
Reviewed-by: Balbir Singh <email address hidden>

CR: https://code.amazon.com/reviews/CR-3280524/
---
 include/linux/stringhash.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

96f0e72... by Alakesh Haloi <email address hidden> on 2018-11-08

iscsi target: Use hex2bin instead of a re-implementation

From 444751eba5b87a317ef0c6a556ce39ec722bfcff Mon Sep 17 00:00:00 2001
From: Alakesh Haloi <email address hidden>
Date: Tue, 11 Sep 2018 18:32:08 +0000
Subject: iscsi target: Use hex2bin instead of a re-implementation

This change has the following effects, in order of descreasing importance:
1) Prevent a stack buffer overflow.
2) Do not append an unnecessary NULL to an anyway binary buffer, which
   is writing one byte past client_digest when caller is:
     chap_string_to_hex(client_digest, chap_r, strlen(chap_r));

The latter was found by KASAN (see below) when input value hes expected
size (32 hex chars), and further analysis revealed a stack buffer overflow
can happen when network-received value is longer, allowing an
unauthenticated remote attacker to smash up to 17 bytes after destination
buffer (16 bytes attacker-controlled and one null).
As switching to hex2bin requires specifying destination buffer length, and
does not internally append any null, it solves both issues.

This addresses CVE-2018-14633.

Beyond this:
- Validate received value length and check hex2bin accepted the input, to
  log this rejection reason instead of just failing authentication.
- Only log received CHAP_R and CHAP_C values once they passed sanity
  checks.

==================================================================
BUG: KASAN: stack-out-of-bounds in chap_string_to_hex+0x32/0x60 [iscsi_target_mod]
Write of size 1 at addr ffff8801090ef7c8 by task kworker/0:0/1021

CPU: 0 PID: 1021 Comm: kworker/0:0 Tainted: G O 4.17.8kasan.sess.connops+ #2
Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 05/19/2014
Workqueue: events iscsi_target_do_login_rx [iscsi_target_mod]
Call Trace:
 dump_stack+0x71/0xac
 print_address_description+0x65/0x22e
 ? chap_string_to_hex+0x32/0x60 [iscsi_target_mod]
 kasan_report.cold.6+0x241/0x2fd
 chap_string_to_hex+0x32/0x60 [iscsi_target_mod]
 chap_server_compute_md5.isra.2+0x2cb/0x860 [iscsi_target_mod]
 ? chap_binaryhex_to_asciihex.constprop.5+0x50/0x50 [iscsi_target_mod]
 ? ftrace_caller_op_ptr+0xe/0xe
 ? __orc_find+0x6f/0xc0
 ? unwind_next_frame+0x231/0x850
 ? kthread+0x1a0/0x1c0
 ? ret_from_fork+0x35/0x40
 ? ret_from_fork+0x35/0x40
 ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]
 ? deref_stack_reg+0xd0/0xd0
 ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]
 ? is_module_text_address+0xa/0x11
 ? kernel_text_address+0x4c/0x110
 ? __save_stack_trace+0x82/0x100
 ? ret_from_fork+0x35/0x40
 ? save_stack+0x8c/0xb0
 ? 0xffffffffc1660000
 ? iscsi_target_do_login+0x155/0x8d0 [iscsi_target_mod]
 ? iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]
 ? process_one_work+0x35c/0x640
 ? worker_thread+0x66/0x5d0
 ? kthread+0x1a0/0x1c0
 ? ret_from_fork+0x35/0x40
 ? iscsi_update_param_value+0x80/0x80 [iscsi_target_mod]
 ? iscsit_release_cmd+0x170/0x170 [iscsi_target_mod]
 chap_main_loop+0x172/0x570 [iscsi_target_mod]
 ? chap_server_compute_md5.isra.2+0x860/0x860 [iscsi_target_mod]
 ? rx_data+0xd6/0x120 [iscsi_target_mod]
 ? iscsit_print_session_params+0xd0/0xd0 [iscsi_target_mod]
 ? cyc2ns_read_begin.part.2+0x90/0x90
 ? _raw_spin_lock_irqsave+0x25/0x50
 ? memcmp+0x45/0x70
 iscsi_target_do_login+0x875/0x8d0 [iscsi_target_mod]
 ? iscsi_target_check_first_request.isra.5+0x1a0/0x1a0 [iscsi_target_mod]
 ? del_timer+0xe0/0xe0
 ? memset+0x1f/0x40
 ? flush_sigqueue+0x29/0xd0
 iscsi_target_do_login_rx+0x3bc/0x4c0 [iscsi_target_mod]
 ? iscsi_target_nego_release+0x80/0x80 [iscsi_target_mod]
 ? iscsi_target_restore_sock_callbacks+0x130/0x130 [iscsi_target_mod]
 process_one_work+0x35c/0x640
 worker_thread+0x66/0x5d0
 ? flush_rcu_work+0x40/0x40
 kthread+0x1a0/0x1c0
 ? kthread_bind+0x30/0x30
 ret_from_fork+0x35/0x40

The buggy address belongs to the page:
page:ffffea0004243bc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
flags: 0x17fffc000000000()
raw: 017fffc000000000 0000000000000000 0000000000000000 00000000ffffffff
raw: ffffea0004243c20 ffffea0004243ba0 0000000000000000 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff8801090ef680: f2 f2 f2 f2 f2 f2 f2 01 f2 f2 f2 f2 f2 f2 f2 00
 ffff8801090ef700: f2 f2 f2 f2 f2 f2 f2 00 02 f2 f2 f2 f2 f2 f2 00
>ffff8801090ef780: 00 f2 f2 f2 f2 f2 f2 00 00 f2 f2 f2 f2 f2 f2 00
                                              ^
 ffff8801090ef800: 00 f2 f2 f2 f2 f2 f2 00 00 00 00 02 f2 f2 f2 f2
 ffff8801090ef880: f2 f2 f2 00 00 00 00 00 00 00 00 f2 f2 f2 f2 00
==================================================================

Signed-off-by: Vincent Pelletier <email address hidden>
Signed-off-by: Alakesh Haloi <email address hidden>
Reviewed-by: Vallish Vaidyeshwara <email address hidden>
Reviewed-by: Frank van der Linden <email address hidden>
---
 drivers/target/iscsi/iscsi_target_auth.c | 45 ++++++++++++--------------------
 1 file changed, 17 insertions(+), 28 deletions(-)

964e712... by Frank van der Linden <email address hidden> on 2018-11-08

net/ipv4: defensive cipso option parsing

From 8e1d4e84c029a3f8e05161be71a666b52c352652 Mon Sep 17 00:00:00 2001
From: Frank van der Linden <email address hidden>
Date: Fri, 31 Aug 2018 18:34:53 +0000
Subject: net/ipv4: defensive cipso option parsing

commit 40413955ee265a5e42f710940ec78f5450d49149 fixed a possible
infinite loop in the IP option parsing of CIPSO. The fix assumes
that ip_option_compile filtered out all zero length options and
that no other one-byte options beside IPOPT_END and IPOPT_NOOP
exist.
While this assumption currently holds true, add explicit checks
for zero length and invalid length options to be safe for the
future. Even though ip_options_compile should have validated the
options, the introduction of new one-byte options can still
confuse this code without the additional checks.

Signed-off-by: Stefan Nuernberger <email address hidden>
---
 net/ipv4/cipso_ipv4.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

c44434e... by Shrikrishna Khare on 2018-11-08

vmxnet3: increase default rx ring sizes

From 2f11337635acb8b0a19c2c2f26d905df6520e404 Mon Sep 17 00:00:00 2001
From: Shrikrishna Khare <email address hidden>
Date: Thu, 30 Nov 2017 10:29:51 -0800
Subject: vmxnet3: increase default rx ring sizes

There are several reasons for increasing the receive ring sizes:

1. The original ring size of 256 was chosen about 10 years ago when
vmxnet3 was first created. At that time, 10Gbps Ethernet was not prevalent
and servers were dominated by 1Gbps Ethernet. Now 10Gbps is common place,
and higher bandwidth links -- 25Gbps, 40Gbps, 50Gbps -- are starting
to appear. 256 Rx ring entries are simply not enough to keep up with
higher link speed when there is a burst of network frames coming from
these high speed links. Even with full MTU size frames, they are gone
in a short time. It is also more common to have a mix of frame sizes,
and more likely bi-modal distribution of frame sizes so the average frame
size is not close to full MTU. If we consider average frame size of 800B,
1024 frames that come in a burst takes ~0.65 ms to arrive at 10Gbps. With
256 entires, it takes ~0.16 ms to arrive at 10Gbps. At 25Gbps or 40Gbps,
this time is reduced accordingly.

2. On a hypervisor where there are many VMs and CPU is over committed,
i.e. the number of VCPUs is more than the number of VCPUs, each PCPU is
in effect time shared between multiple VMs/VCPUs. The time granularity at
which this multiplexing occurs is typically coarser than between processes
on a guest OS. Trying to time slice more finely is not efficient, for
example, if memory cache is barely warmed up when switching from one VM
to another occurs. This CPU overcommit adds delay to when the driver
in a VM can service incoming packets. Whether CPU is over committed
really depends on customer workloads. For certain situations, it is very
common. For example, workloads of desktop VMs and product testing setups.
Consolidation and sharing is what drives efficiency of a customer setup
for such workloads. In these situations, the raw network bandwidth may
not be very high, but the delays between when a VM is running or not

Signed-off-by: Shrikrishna Khare <email address hidden>
Acked-by: Jin Heo <email address hidden>
Acked-by: Guolin Yang <email address hidden>
Acked-by: Boon Ang <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Balbir Singh <email address hidden>
---
 drivers/net/vmxnet3/vmxnet3_int.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

c0de9ce... by Suravee Suthikulpanit on 2018-11-08

x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when available

From 237f7f2e9aad111ef9706009c9d4b4c057e40772 Mon Sep 17 00:00:00 2001
From: Suravee Suthikulpanit <email address hidden>
Date: Fri, 27 Apr 2018 16:48:01 -0500
Subject: x86/CPU/AMD: Derive CPU topology from CPUID function 0xB when
 available

[upstream 3986a0a805e668a63fac0ca2cdfa8db951f87c4b with changes
after 4.14.62 rebase and backport of 95f3d39ccf7aaea79d1ffdac1c887c2e100ec1b6
was broken for this patch series]

Derive topology information from Extended Topology Enumeration (CPUID
function 0xB) when the information is available.

Signed-off-by: Suravee Suthikulpanit <email address hidden>
Signed-off-by: Borislav Petkov <email address hidden>
Signed-off-by: Thomas Gleixner <email address hidden>
Link: http://lkml.kernel<email address hidden>

Signed-off-by: Balbir Singh <email address hidden>
---
 arch/x86/include/asm/processor.h | 1 -
 arch/x86/kernel/cpu/amd.c | 11 ++++++++++-
 arch/x86/kernel/cpu/cpu.h | 1 +
 arch/x86/kernel/cpu/topology.c | 5 +++--

d23c2d9... by Suravee Suthikulpanit on 2018-11-08

sched/topology: Introduce NUMA identity node sched domain

From 673e6d12fcc0a2a04e8d7c4434de58dd2bf5f598 Mon Sep 17 00:00:00 2001
From: Suravee Suthikulpanit <email address hidden>
Date: Thu, 7 Sep 2017 02:20:05 -0500
Subject: sched/topology: Introduce NUMA identity node sched domain

[upstream 051f3ca02e46432c0965e8948f00c07d8a2f09c0]

On AMD Family17h-based (EPYC) system, a logical NUMA node can contain
upto 8 cores (16 threads) with the following topology.

             ----------------------------
         C0 | T0 T1 | || | T0 T1 | C4
             --------| || |--------
         C1 | T0 T1 | L3 || L3 | T0 T1 | C5
             --------| || |--------
         C2 | T0 T1 | #0 || #1 | T0 T1 | C6
             --------| || |--------
         C3 | T0 T1 | || | T0 T1 | C7
             ----------------------------

Here, there are 2 last-level (L3) caches per logical NUMA node.
A socket can contain upto 4 NUMA nodes, and a system can support
upto 2 sockets. With full system configuration, current scheduler
creates 4 sched domains:

  domain0 SMT (span a core)
  domain1 MC (span a last-level-cache)
  domain2 NUMA (span a socket: 4 nodes)
  domain3 NUMA (span a system: 8 nodes)

Note that there is no domain to represent cpus spaning a logical
NUMA node. With this hierarchy of sched domains, the scheduler does
not balance properly in the following cases:

Case1:

 When running 8 tasks, a properly balanced system should
 schedule a task per logical NUMA node. This is not the case for
 the current scheduler.

Case2:

 In some cases, threads are scheduled on the same cpu, while other
 cpus are idle. This results in run-to-run inconsistency. For example:

  taskset -c 0-7 sysbench --num-threads=8 --test=cpu \
                          --cpu-max-prime=100000 run

Total execution time ranges from 25.1s to 33.5s depending on threads
placement, where 25.1s is when all 8 threads are balanced properly
on 8 cpus.

Introducing NUMA identity node sched domain, which is based on how
SRAT/SLIT table define a logical NUMA node. This results in the following
hierarchy of sched domains on the same system described above.

  domain0 SMT (span a core)
  domain1 MC (span a last-level-cache)
  domain2 NODE (span a logical NUMA node)
  domain3 NUMA (span a socket: 4 nodes)
  domain4 NUMA (span a system: 8 nodes)

This fixes the improper load balancing cases mentioned above.

Signed-off-by: Suravee Suthikulpanit <email address hidden>
Signed-off-by: Peter Zijlstra (Intel) <email address hidden>
Cc: Linus Torvalds <email address hidden>
Cc: Mike Galbraith <email address hidden>
Cc: Peter Zijlstra <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Cc: <email address hidden>
Link: http://lkml.kernel<email address hidden>
Signed-off-by: Ingo Molnar <email address hidden>
Signed-off-by: Balbir Singh <email address hidden>
---
 kernel/sched/topology.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)