~kmously/ubuntu/+source/linux/+git/artful:ml

Branch merges

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related charm recipes

66e83fd... by David Daney on 2018-05-10

PCI: Mark Cavium CN8xxx to avoid bus reset

Root ports of cn8xxx do not function after bus reset when used with some
e1000e and LSI HBA devices. Add a quirk to prevent bus reset on these root
ports.

BugLink: https://launchpad.net/bugs/1770254

Signed-off-by: David Daney <email address hidden>
[<email address hidden>: fixed typo and whitespaces]
Signed-off-by: Jan Glauber <email address hidden>
Signed-off-by: Bjorn Helgaas <email address hidden>
Reviewed-by: Alex Williamson <email address hidden>
(cherry picked from commit 822155100e589f2a4891b3b2db2f901824d47e69)
Signed-off-by: Manoj Iyer <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Kleber Souza <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>

b671775... by "Rafael J. Wysocki" <email address hidden> on 2018-05-11

PCI / PM: Check device_may_wakeup() in pci_enable_wake()

BugLink: http://bugs.launchpad.net/bugs/1745646

Commit 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code)
went too far and dropped the device_may_wakeup() check from
pci_enable_wake() which causes wakeup to be enabled during system
suspend, hibernation or shutdown for some PCI devices that are not
allowed by user space to wake up the system from sleep (or power off).

As a result of this excessive power is drawn by some of the affected
systems while in sleep states or off.

Restore the device_may_wakeup() check in pci_enable_wake(), but make
sure that the PCI bus type's runtime suspend callback will not call
device_may_wakeup() which is about system wakeup from sleep and not
about device wakeup from runtime suspend.

Fixes: 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code)
Reported-by: Joseph Salisbury <email address hidden>
Cc: 4.13+ <email address hidden> # 4.13+
Signed-off-by: Rafael J. Wysocki <email address hidden>
Acked-by: Bjorn Helgaas <email address hidden>
(cherry-picked from cfcadfaad7251d8b640713724b388164d75465b2)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Kleber Souza <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>

a73498b... by Arnaldo Carvalho de Melo on 2018-05-11

perf cgroup: Fix refcount usage

BugLink: http://bugs.launchpad.net/bugs/1769027

When converting from atomic_t to refcount_t we didn't follow the usual
step of initializing it to one before taking any new reference, which
trips over checking if taking a reference for a freed refcount_t, fix
it.

Brendan's report:

 ---
It's 4.12-rc7, with node v4.4.1. I'm building 4.13-rc1 now, as I hit
what I think is another unrelated perf bug and I'm starting to wonder
what else is broken on that version:

(root) /mnt/src/linux-4.12-rc7/tools/perf # ./perf record -F 99 -a -e
cpu-clock --cgroup=docker/f9e9d5df065b14646e8a11edc837a13877fd90c171137b2ba3feb67a0201cb65
-g
perf: /mnt/src/linux-4.12-rc7/tools/include/linux/refcount.h:108:
refcount_inc: Assertion `!(!refcount_inc_not_zero(r))' failed.
Aborted

that used to work...
 ---

Testing it:

Before:

  # perf stat -e cycles -C 0 --cgroup /
  perf: /home/acme/git/linux/tools/include/linux/refcount.h:108: refcount_inc: Assertion `!(!refcount_inc_not_zero(r))' failed.
  Aborted (core dumped)
  #

After:

  # perf stat -e cycles -C 0 --cgroup /
^C
  Performance counter stats for 'CPU(s) 0':

       132,081,393 cycles /

       2.492942763 seconds time elapsed

  #

Reported-by: Brendan Gregg <email address hidden>
Acked-by: Elena Reshetova <email address hidden>
Cc: Alexander Shishkin <email address hidden>
Cc: David Ahern <email address hidden>
Cc: David Carrillo-Cisneros <email address hidden>
Cc: Kees Kook <email address hidden>
Cc: Krister Johansen <email address hidden>
Cc: Paul Turner <email address hidden>
Cc: Peter Zijlstra <email address hidden>
Cc: Stephane Eranian <email address hidden>
Cc: Sudeep Holla <email address hidden>
Cc: Thomas-Mich Richter <email address hidden>
Cc: Wang Nan <email address hidden>
Fixes: 79c5fe6db8c7 ("perf cgroup: Convert cgroup_sel.refcnt from atomic_t to refcount_t")
Link: http://<email address hidden>
Signed-off-by: Arnaldo Carvalho de Melo <email address hidden>
(cherry picked from commit cd8dd032f61abeb08d2c03bab4968a9de231a1be)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Kleber Souza <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>

3658be5... by Jin Yao <email address hidden> on 2018-05-11

perf xyarray: Fix wrong processing when closing evsel fd

BugLink: http://bugs.launchpad.net/bugs/1769027

In current xyarray code, xyarray__max_x() returns max_y, and xyarray__max_y()
returns max_x.

It's confusing and for code logic it looks not correct.

Error happens when closing evsel fd. Let's see this scenario:

1. Allocate an fd (pseudo-code)

  perf_evsel__alloc_fd(struct perf_evsel *evsel, int ncpus, int nthreads)
  {
 evsel->fd = xyarray__new(ncpus, nthreads, sizeof(int));
  }

  xyarray__new(int xlen, int ylen, size_t entry_size)
  {
 size_t row_size = ylen * entry_size;
 struct xyarray *xy = zalloc(sizeof(*xy) + xlen * row_size);

 xy->entry_size = entry_size;
 xy->row_size = row_size;
 xy->entries = xlen * ylen;
 xy->max_x = xlen;
 xy->max_y = ylen;
 ......
  }

So max_x is ncpus, max_y is nthreads and row_size = nthreads * 4.

2. Use perf syscall and get the fd

  int perf_evsel__open(struct perf_evsel *evsel, struct cpu_map *cpus,
       struct thread_map *threads)
  {
 for (cpu = 0; cpu < cpus->nr; cpu++) {

  for (thread = 0; thread < nthreads; thread++) {
   int fd, group_fd;

   fd = sys_perf_event_open(&evsel->attr, pid, cpus->map[cpu],
       group_fd, flags);

   FD(evsel, cpu, thread) = fd;
 }
  }

  static inline void *xyarray__entry(struct xyarray *xy, int x, int y)
  {
 return &xy->contents[x * xy->row_size + y * xy->entry_size];
  }

These codes don't have issues. The issue happens in the closing of fd.

3. Close fd.

  void perf_evsel__close_fd(struct perf_evsel *evsel)
  {
 int cpu, thread;

 for (cpu = 0; cpu < xyarray__max_x(evsel->fd); cpu++)
  for (thread = 0; thread < xyarray__max_y(evsel->fd); ++thread) {
   close(FD(evsel, cpu, thread));
   FD(evsel, cpu, thread) = -1;
  }
  }

  Since xyarray__max_x() returns max_y (nthreads) and xyarry__max_y()
  returns max_x (ncpus), so above code is actually to be:

        for (cpu = 0; cpu < nthreads; cpu++)
                for (thread = 0; thread < ncpus; ++thread) {
                        close(FD(evsel, cpu, thread));
                        FD(evsel, cpu, thread) = -1;
                }

  It's not correct!

This change is introduced by "475fb533fb7d" ("perf evsel: Fix buffer overflow
while freeing events")

This fix is to let xyarray__max_x() return max_x (ncpus) and
let xyarry__max_y() return max_y (nthreads)

Committer note:

This was also fixed by Ravi Bangoria, who provided the same patch,
noticing the problem with 'perf record':

<quote Ravi>
I see 'perf record -p <pid>' crashes with following log:

   *** Error in `./perf': free(): invalid next size (normal): 0x000000000298b340 ***
   ======= Backtrace: =========
   /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f7fd85c87e5]
   /lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7f7fd85d137a]
   /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f7fd85d553c]
   ./perf(perf_evsel__close+0xb4)[0x4b7614]
   ./perf(perf_evlist__delete+0x100)[0x4ab180]
   ./perf(cmd_record+0x1d9)[0x43a5a9]
   ./perf[0x49aa2f]
   ./perf(main+0x631)[0x427841]
   /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f7fd8571830]
   ./perf(_start+0x29)[0x427a59]
</>

Signed-off-by: Jin Yao <email address hidden>
Acked-by: Jiri Olsa <email address hidden>
Cc: Alexander Shishkin <email address hidden>
Cc: Andi Kleen <email address hidden>
Cc: Kan Liang <email address hidden>
Cc: Peter Zijlstra <email address hidden>
Cc: Ravi Bangoria <email address hidden>
Fixes: d74be4767367 ("perf xyarray: Save max_x, max_y")
Link: http://<email address hidden>
Link: http://lkml<email address hidden>
Signed-off-by: Arnaldo Carvalho de Melo <email address hidden>
(cherry picked from commit 3d8bba9535ac6e79453c769dd0c8ea852a51ad60)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Kleber Souza <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>

77afdf1... by Jani Nikula <email address hidden> on 2018-05-11

drm/i915/bios: filter out invalid DDC pins from VBT child devices

BugLink: http://bugs.launchpad.net/bugs/1764194

The VBT contains the DDC pin to use for specific ports. Alas, sometimes
the field appears to contain bogus data, and while we check for it later
on in intel_gmbus_get_adapter() we fail to check the returned NULL on
errors. Oops results.

The simplest approach seems to be to catch and ignore the bogus DDC pins
already at the VBT parsing phase, reverting to fixed per port default
pins. This doesn't guarantee display working, but at least it prevents
the oops. And we continue to be fuzzed by VBT.

One affected machine is Dell Latitude 5590 where a BIOS upgrade added
invalid DDC pins.

Typical backtrace:

[ 35.461411] WARN_ON(!intel_gmbus_is_valid_pin(dev_priv, pin))
[ 35.461432] WARNING: CPU: 6 PID: 411 at
drivers/gpu/drm/i915/intel_i2c.c:844 intel_gmbus_get_adapter+0x32/0x37
[i915]
[ 35.461437] Modules linked in: i915 ahci libahci dm_snapshot dm_bufio
dm_raid raid456 async_raid6_recov async_pq raid6_pq async_xor xor
async_memcpy async_tx
[ 35.461445] CPU: 6 PID: 411 Comm: kworker/u16:2 Not tainted
4.16.0-rc7.x64-g1cda370ffded #1
[ 35.461447] Hardware name: Dell Inc. Latitude 5590/0MM81M, BIOS 1.1.9
03/13/2018
[ 35.461450] Workqueue: events_unbound async_run_entry_fn
[ 35.461465] RIP: 0010:intel_gmbus_get_adapter+0x32/0x37 [i915]
[ 35.461467] RSP: 0018:ffff9b4e43d47c40 EFLAGS: 00010286
[ 35.461469] RAX: 0000000000000000 RBX: ffff98f90639f800 RCX:
ffffffffae051960
[ 35.461471] RDX: 0000000000000001 RSI: 0000000000000092 RDI:
0000000000000246
[ 35.461472] RBP: ffff98f905410000 R08: 0000004d062a83f6 R09:
00000000000003bd
[ 35.461474] R10: 0000000000000031 R11: ffffffffad4eda58 R12:
ffff98f905410000
[ 35.461475] R13: ffff98f9064c1000 R14: ffff9b4e43d47cf0 R15:
ffff98f905410000
[ 35.461477] FS: 0000000000000000(0000) GS:ffff98f92e580000(0000)
knlGS:0000000000000000
[ 35.461479] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 35.461481] CR2: 00007f5682359008 CR3: 00000001b700c005 CR4:
00000000003606e0
[ 35.461483] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 35.461484] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[ 35.461486] Call Trace:
[ 35.461501] intel_hdmi_set_edid+0x37/0x27f [i915]
[ 35.461515] intel_hdmi_detect+0x7c/0x97 [i915]
[ 35.461518] drm_helper_probe_single_connector_modes+0xe1/0x6c0
[ 35.461521] drm_setup_crtcs+0x129/0xa6a
[ 35.461523] ? __switch_to_asm+0x34/0x70
[ 35.461527] ? __switch_to_asm+0x40/0x70
[ 35.461528] ? __switch_to_asm+0x34/0x70
[ 35.461529] ? __switch_to_asm+0x40/0x70
[ 35.461531] ? __switch_to_asm+0x34/0x70
[ 35.461532] ? __switch_to_asm+0x40/0x70
[ 35.461534] ? __switch_to_asm+0x34/0x70
[ 35.461536] __drm_fb_helper_initial_config_and_unlock+0x34/0x46f
[ 35.461538] ? __switch_to_asm+0x40/0x70
[ 35.461541] ? _cond_resched+0x10/0x33
[ 35.461557] intel_fbdev_initial_config+0xf/0x1c [i915]
[ 35.461560] async_run_entry_fn+0x2e/0xf5
[ 35.461563] process_one_work+0x15b/0x364
[ 35.461565] worker_thread+0x2c/0x3a0
[ 35.461567] ? process_one_work+0x364/0x364
[ 35.461568] kthread+0x10c/0x122
[ 35.461570] ? _kthread_create_on_node+0x5d/0x5d
[ 35.461572] ret_from_fork+0x35/0x40
[ 35.461574] Code: 74 16 89 f6 48 8d 04 b6 48 c1 e0 05 48 29 f0 48 8d
84 c7 e8 11 00 00 c3 48 c7 c6 b0 19 1e c0 48 c7 c7 64 8a 1c c0 e8 47 88
ed ec <0f> 0b 31 c0 c3 8b 87 a4 04 00 00 80 e4 fc 09 c6 89 b7 a4 04 00
[ 35.461604] WARNING: CPU: 6 PID: 411 at
drivers/gpu/drm/i915/intel_i2c.c:844 intel_gmbus_get_adapter+0x32/0x37
[i915]
[ 35.461606] ---[ end trace 4fe1e63e2dd93373 ]---
[ 35.461609] BUG: unable to handle kernel NULL pointer dereference at
0000000000000010
[ 35.461613] IP: i2c_transfer+0x4/0x86
[ 35.461614] PGD 0 P4D 0
[ 35.461616] Oops: 0000 [#1] SMP PTI
[ 35.461618] Modules linked in: i915 ahci libahci dm_snapshot dm_bufio
dm_raid raid456 async_raid6_recov async_pq raid6_pq async_xor xor
async_memcpy async_tx
[ 35.461624] CPU: 6 PID: 411 Comm: kworker/u16:2 Tainted: G W
4.16.0-rc7.x64-g1cda370ffded #1
[ 35.461625] Hardware name: Dell Inc. Latitude 5590/0MM81M, BIOS 1.1.9
03/13/2018
[ 35.461628] Workqueue: events_unbound async_run_entry_fn
[ 35.461630] RIP: 0010:i2c_transfer+0x4/0x86
[ 35.461631] RSP: 0018:ffff9b4e43d47b30 EFLAGS: 00010246
[ 35.461633] RAX: ffff9b4e43d47b6e RBX: 0000000000000005 RCX:
0000000000000001
[ 35.461635] RDX: 0000000000000002 RSI: ffff9b4e43d47b80 RDI:
0000000000000000
[ 35.461636] RBP: ffff9b4e43d47bd8 R08: 0000004d062a83f6 R09:
00000000000003bd
[ 35.461638] R10: 0000000000000031 R11: ffffffffad4eda58 R12:
0000000000000002
[ 35.461639] R13: 0000000000000001 R14: ffff9b4e43d47b6f R15:
ffff9b4e43d47c07
[ 35.461641] FS: 0000000000000000(0000) GS:ffff98f92e580000(0000)
knlGS:0000000000000000
[ 35.461643] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 35.461645] CR2: 0000000000000010 CR3: 00000001b700c005 CR4:
00000000003606e0
[ 35.461646] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 35.461647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
0000000000000400
[ 35.461649] Call Trace:
[ 35.461652] drm_do_probe_ddc_edid+0xb3/0x128
[ 35.461654] drm_get_edid+0xe5/0x38d
[ 35.461669] intel_hdmi_set_edid+0x45/0x27f [i915]
[ 35.461684] intel_hdmi_detect+0x7c/0x97 [i915]
[ 35.461687] drm_helper_probe_single_connector_modes+0xe1/0x6c0
[ 35.461689] drm_setup_crtcs+0x129/0xa6a
[ 35.461691] ? __switch_to_asm+0x34/0x70
[ 35.461693] ? __switch_to_asm+0x34/0x70
[ 35.461694] ? __switch_to_asm+0x40/0x70
[ 35.461696] ? __switch_to_asm+0x34/0x70
[ 35.461697] ? __switch_to_asm+0x40/0x70
[ 35.461698] ? __switch_to_asm+0x34/0x70
[ 35.461700] ? __switch_to_asm+0x40/0x70
[ 35.461701] ? __switch_to_asm+0x34/0x70
[ 35.461703] __drm_fb_helper_initial_config_and_unlock+0x34/0x46f
[ 35.461705] ? __switch_to_asm+0x40/0x70
[ 35.461707] ? _cond_resched+0x10/0x33
[ 35.461724] intel_fbdev_initial_config+0xf/0x1c [i915]
[ 35.461727] async_run_entry_fn+0x2e/0xf5
[ 35.461729] process_one_work+0x15b/0x364
[ 35.461731] worker_thread+0x2c/0x3a0
[ 35.461733] ? process_one_work+0x364/0x364
[ 35.461734] kthread+0x10c/0x122
[ 35.461736] ? _kthread_create_on_node+0x5d/0x5d
[ 35.461738] ret_from_fork+0x35/0x40
[ 35.461739] Code: 5c fa e1 ad 48 89 df e8 ea fb ff ff e9 2a ff ff ff
0f 1f 44 00 00 31 c0 e9 43 fd ff ff 31 c0 45 31 e4 e9 c5 fd ff ff 41 54
55 53 <48> 8b 47 10 48 83 78 10 00 74 70 41 89 d4 48 89 f5 48 89 fb 65
[ 35.461756] RIP: i2c_transfer+0x4/0x86 RSP: ffff9b4e43d47b30
[ 35.461757] CR2: 0000000000000010
[ 35.461759] ---[ end trace 4fe1e63e2dd93374 ]---

Based on a patch by Fei Li.

v2: s/reverting/sticking/ (Chris)

Cc: <email address hidden>
Cc: Fei Li <email address hidden>
Co-developed-by: Fei Li <email address hidden>
Reported-by: Pavel Nakonechnyi <email address hidden>
Reported-and-tested-by: Seweryn Kokot <email address hidden>
Reported-and-tested-by: Laszlo Valko <email address hidden>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105549
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105961
Reviewed-by: Chris Wilson <email address hidden>
Signed-off-by: Jani Nikula <email address hidden>
Link:
https://patchwork<email address hidden>
(cherry picked from commit f212bf9abe5de9f938fecea7df07046e74052dde)
Signed-off-by: Joonas Lahtinen <email address hidden>
(back ported from commit a3520b8992e57bc94ab6ec9f95f09c6c932555fd)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Kleber Souza <email address hidden>
Signed-off-by: Khalid Elmously <email address hidden>

2ac47e6... by Kai-Heng Feng on 2018-05-14

PCI / PM: Always check PME wakeup capability for runtime wakeup support

BugLink: https://bugs.launchpad.net/bugs/1764684

USB controller ASM1042 stops working after commit de3ef1eb1cd0 (PM /
core: Drop run_wake flag from struct dev_pm_info).

The device in question is not power managed by platform firmware,
furthermore, it only supports PME# from D3cold:
Capabilities: [78] Power Management version 3
       Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot-,D3cold+)
       Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-

Before commit de3ef1eb1cd0, the device never gets runtime suspended.
After that commit, the device gets runtime suspended to D3hot, which can
not generate any PME#.

usb_hcd_pci_probe() unconditionally calls device_wakeup_enable(), hence
device_can_wakeup() in pci_dev_run_wake() always returns true.

So pci_dev_run_wake() needs to check PME wakeup capability as its first
condition.

In addition, change wakeup flag passed to pci_target_state() from false
to true, because we want to find the deepest state different from D3cold
that the device can still generate PME#. In this case, it's D0 for the
device in question.

Fixes: de3ef1eb1cd0 (PM / core: Drop run_wake flag from struct dev_pm_info)
Signed-off-by: Kai-Heng Feng <email address hidden>
Cc: 4.13+ <email address hidden> # 4.13+
Acked-by: Bjorn Helgaas <email address hidden>
Signed-off-by: Rafael J. Wysocki <email address hidden>
(cherry picked from commit 8feaec33b9868582654cd3d5355225dcb79aeca6)
Signed-off-by: Kai-Heng Feng <email address hidden>
Acked-by: Po-Hsu Lin <email address hidden>
Acked-by: AceLan Kao <email address hidden>
Acked-by: Andy Whitcroft <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>

e4ccc59... by Jeffrey Hugo on 2018-05-15

init: fix false positives in W+X checking

load_module() creates W+X mappings via __vmalloc_node_range() (from
layout_and_allocate()->move_module()->module_alloc()) by using
PAGE_KERNEL_EXEC. These mappings are later cleaned up via
"call_rcu_sched(&freeinit->rcu, do_free_init)" from do_init_module().

This is a problem because call_rcu_sched() queues work, which can be run
after debug_checkwx() is run, resulting in a race condition. If hit,
the race results in a nasty splat about insecure W+X mappings, which
results in a poor user experience as these are not the mappings that
debug_checkwx() is intended to catch.

This issue is observed on multiple arm64 platforms, and has been
artificially triggered on an x86 platform.

Address the race by flushing the queued work before running the
arch-defined mark_rodata_ro() which then calls debug_checkwx().

Link: http://<email address hidden>
Fixes: e1a58320a38d ("x86/mm: Warn on W^X mappings")

BugLink: https://launchpad.net/bugs/1769696

Signed-off-by: Jeffrey Hugo <email address hidden>
Reported-by: Timur Tabi <email address hidden>
Reported-by: Jan Glauber <email address hidden>
Acked-by: Kees Cook <email address hidden>
Acked-by: Ingo Molnar <email address hidden>
Acked-by: Will Deacon <email address hidden>
Acked-by: Laura Abbott <email address hidden>
Cc: Mark Rutland <email address hidden>
Cc: Ard Biesheuvel <email address hidden>
Cc: Catalin Marinas <email address hidden>
Cc: Stephen Smalley <email address hidden>
Cc: Thomas Gleixner <email address hidden>
Cc: Peter Zijlstra <email address hidden>
Signed-off-by: Andrew Morton <email address hidden>
Signed-off-by: Linus Torvalds <email address hidden>
(cherry picked from commit ae646f0b9ca135b87bc73ff606ef996c3029780a)
Signed-off-by: Manoj Iyer <email address hidden>
Acked-by: Joseph Salisbury <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>

cef5b7a... by Florian Westphal <email address hidden> on 2018-05-14

netfilter: ebtables: CONFIG_COMPAT: don't trust userland offsets

CVE-2018-1068

We need to make sure the offsets are not out of range of the
total size.
Also check that they are in ascending order.

The WARN_ON triggered by syzkaller (it sets panic_on_warn) is
changed to also bail out, no point in continuing parsing.

Briefly tested with simple ruleset of
-A INPUT --limit 1/s' --log
plus jump to custom chains using 32bit ebtables binary.

Reported-by: <email address hidden>
Signed-off-by: Florian Westphal <email address hidden>
Signed-off-by: Pablo Neira Ayuso <email address hidden>
(cherry-picked from b71812168571fa55e44cdd0254471331b9c4c4c6)
Signed-off-by: Khalid Elmously <email address hidden>
Acked-by: Andy Whitcroft <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>

0ed8fd4... by "weiyongjun (A)" <email address hidden> on 2018-05-14

mac80211_hwsim: fix possible memory leak in hwsim_new_radio_nl()

CVE-2018-8087

'hwname' is malloced in hwsim_new_radio_nl() and should be freed
before leaving from the error handling cases, otherwise it will cause
memory leak.

Fixes: ff4dd73dd2b4 ("mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length")
Signed-off-by: Wei Yongjun <email address hidden>
Reviewed-by: Ben Hutchings <email address hidden>
Signed-off-by: Johannes Berg <email address hidden>
(cherry-picked from 0ddcff49b672239dda94d70d0fcf50317a9f4b51)
Signed-off-by: Khalid Elmously <email address hidden>
Acked-by: Po-Hsu Lin <email address hidden>
Acked-by: Andy Whitcroft <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>

0fce3ba... by ming_qian <email address hidden> on 2018-05-14

UBUNTU: SAUCE: media: uvcvideo: Support realtek's UVC 1.5 device

BugLink: https://bugs.launchpad.net/bugs/1763748

The length of UVC 1.5 video control is 48, and it id 34 for UVC 1.1.
Change it to 48 for UVC 1.5 device,
and the UVC 1.5 device can be recognized.

More changes to the driver are needed for full UVC 1.5 compatibility.
However, at least the UVC 1.5 Realtek RTS5847/RTS5852 cameras have
been reported to work well.

Signed-off-by: ming_qian <email address hidden>
Signed-off-by: Kai-Heng Feng <email address hidden>
Acked-by: AceLan Kao <email address hidden>
Acked-by: Andy Whitcroft <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>