UBUNTU: [debian] derive indep_hdrs_pkg_name from src_pkg_name
This long-standing oversight in our debian rules hardcodes the string "linux"
instead of using the $(src_pkg_name) for just one of the generated .deb package
names: linux-headers-x.x.x-x. Lets fix it in the generic branches
(T,X,Y,Z,unstable) so that we won't have to keep applying this patch to each of
the derivative/custom kernels.
-----8<-----
Ignore: yes
Signed-off-by: Kamal Mostafa <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Benjamin M Romer <email address hidden>
16b30ba...
by
pravin shelar <email address hidden>
UBUNTU: SAUCE: openvswitch: gre: filter gre packets
OVS can only process L2 packets. But OVS GRE receive handler
can accept IP-GRE packets. When such packet is processed by
OVS datapath it can trigger following assert failure due
to insufficient linear data in skb. Following patch filters
received packets to avoid this issue.
Fixes: aa310701e7 ("openvswitch: Add gre tunnel support.")
Reported-by: Uri Foox <email address hidden>
CC: Joe Stringer <email address hidden>
Signed-off-by: Pravin B Shelar <email address hidden>
Acked-by: Joe Stringer <email address hidden>
Signed-off-by: Tim Gardner <email address hidden>
Acked-by: Seth Forshee <email address hidden>
Acked-by: Brad Figg <email address hidden>
Signed-off-by: Benjamin M Romer <email address hidden>
34640b2...
by
Omar Sandoval <email address hidden>
block: fix use-after-free in sys_ioprio_get()
get_task_ioprio() accesses the task->io_context without holding the task
lock and thus can race with exit_io_context(), leading to a
use-after-free. The reproducer below hits this within a few seconds on
my 4-core QEMU VM:
int main(int argc, char **argv)
{
pid_t pid, child;
long nproc, i;
This problem can occur in the following situation:
open()
- pread()
- .seq_start()
- iter = kmalloc() // succeeds
- seqf->private = iter
- .seq_stop()
- kfree(seqf->private)
- pread()
- .seq_start()
- iter = kmalloc() // fails
- .seq_stop()
- class_dev_iter_exit(seqf->private) // boom! old pointer
As the comment in disk_seqf_stop() says, stop is called even if start
failed, so we need to reinitialise the private pointer to NULL when seq
iteration stops.
An alternative would be to set the private pointer to NULL when the
kmalloc() in disk_seqf_start() fails.
Cc: <email address hidden>
Signed-off-by: Vegard Nossum <email address hidden>
Acked-by: Tejun Heo <email address hidden>
Signed-off-by: Jens Axboe <email address hidden>
CVE-2016-7910
(cherry picked from commit 77da160530dd1dc94f6ae15a981f24e5f0021e84)
Acked-by: Colin Ian King <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>
Revert the main part of commit:
af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
That commit introduced reading the pci device's msi message data to see
if a pirq was previously configured for the device's msi/msix, and re-use
that pirq. At the time, that was the correct behavior. However, a
later change to Qemu caused it to call into the Xen hypervisor to unmap
all pirqs for a pci device, when the pci device disables its MSI/MSIX
vectors; specifically the Qemu commit:
c976437c7dba9c7444fb41df45468968aaa326ad
("qemu-xen: free all the pirqs for msi/msix when driver unload")
Once Qemu added this pirq unmapping, it was no longer correct for the
kernel to re-use the pirq number cached in the pci device msi message
data. All Qemu releases since 2.1.0 contain the patch that unmaps the
pirqs when the pci device disables its MSI/MSIX vectors.
This bug is causing failures to initialize multiple NVMe controllers
under Xen, because the NVMe driver sets up a single MSIX vector for
each controller (concurrently), and then after using that to talk to
the controller for some configuration data, it disables the single MSIX
vector and re-configures all the MSIX vectors it needs. So the MSIX
setup code tries to re-use the cached pirq from the first vector
for each controller, but the hypervisor has already given away that
pirq to another controller, and its initialization fails.
Fixes: af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
Signed-off-by: Dan Streetman <email address hidden>
(backported from X/Y/Z patch for context/function name changes only)
Acked-by: Tim Gardner <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>
Signed-off-by: John Donnelly <email address hidden>
fa1b1d9...
by
Marcelo Ricardo Leitner <email address hidden>
sctp: validate chunk len before actually using it
Andrey Konovalov reported that KASAN detected that SCTP was using a slab
beyond the boundaries. It was caused because when handling out of the
blue packets in function sctp_sf_ootb() it was checking the chunk len
only after already processing the first chunk, validating only for the
2nd and subsequent ones.
The fix is to just move the check upwards so it's also validated for the
1st chunk.
Reported-by: Andrey Konovalov <email address hidden>
Tested-by: Andrey Konovalov <email address hidden>
Signed-off-by: Marcelo Ricardo Leitner <email address hidden>
Reviewed-by: Xin Long <email address hidden>
Acked-by: Neil Horman <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(backported from commit bf911e985d6bbaa328c20c3e05f4eb03de11fdd6)
CVE-2016-9555
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Tim Gardner <email address hidden>
Signed-off-by: Luis Henriques <email address hidden>
