~kamalmostafa/ubuntu/+source/linux/+git/yakkety:master

Branch merges

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related charm recipes

1b11947... by Stefan Bader on 2017-03-03

UBUNTU: Ubuntu-4.8.0-41.44

Signed-off-by: Stefan Bader <email address hidden>

fa8a09d... by Alexander Popov on 2017-03-01

tty: n_hdlc: get rid of racy n_hdlc.tbuf

Currently N_HDLC line discipline uses a self-made singly linked list for
data buffers and has n_hdlc.tbuf pointer for buffer retransmitting after
an error.

The commit be10eb7589337e5defbe214dae038a53dd21add8
("tty: n_hdlc add buffer flushing") introduced racy access to n_hdlc.tbuf.
After tx error concurrent flush_tx_queue() and n_hdlc_send_frames() can put
one data buffer to tx_free_buf_list twice. That causes double free in
n_hdlc_release().

Let's use standard kernel linked list and get rid of n_hdlc.tbuf:
in case of tx error put current data buffer after the head of tx_buf_list.

Signed-off-by: Alexander Popov <email address hidden>

CVE-2017-2636

Signed-off-by: Stefan Bader <email address hidden>

7adae75... by Stefan Bader on 2017-03-03

UBUNTU: Start new release

Ignore: yes
Signed-off-by: Stefan Bader <email address hidden>

f21ade0... by Stefan Bader on 2017-02-20

UBUNTU: Ubuntu-4.8.0-39.42

Signed-off-by: Stefan Bader <email address hidden>

205098b... by Andrey Konovalov <email address hidden> on 2017-02-16

dccp: fix freeing skb too early for IPV6_RECVPKTINFO

In the current DCCP implementation an skb for a DCCP_PKT_REQUEST packet
is forcibly freed via __kfree_skb in dccp_rcv_state_process if
dccp_v6_conn_request successfully returns.

However, if IPV6_RECVPKTINFO is set on a socket, the address of the skb
is saved to ireq->pktopts and the ref count for skb is incremented in
dccp_v6_conn_request, so skb is still in use. Nevertheless, it gets freed
in dccp_rcv_state_process.

Fix by calling consume_skb instead of doing goto discard and therefore
calling __kfree_skb.

Similar fixes for TCP:

fb7e2399ec17f1004c0e0ccfd17439f8759ede01 [TCP]: skb is unexpectedly freed.
0aea76d35c9651d55bbaf746e7914e5f9ae5a25d tcp: SYN packets are now
simply consumed

Signed-off-by: Andrey Konovalov <email address hidden>
Acked-by: Eric Dumazet <email address hidden>
Signed-off-by: David S. Miller <email address hidden>

CVE-2017-6074
BugLink: http://bugs.launchpad.net/bugs/1665935

(cherry-picked from 5edabca9d4cff7f1f2b68f0bac55ef99d9798ba4 davem)
Signed-off-by: Stefan Bader <email address hidden>

027797a... by Stefan Bader on 2017-02-20

UBUNTU: Start new release

Ignore: yes
Signed-off-by: Stefan Bader <email address hidden>

079ee03... by Thadeu Lima de Souza Cascardo on 2017-02-02

UBUNTU: Ubuntu-4.8.0-38.41

Signed-off-by: Benjamin M Romer <email address hidden>

6c9ad0e... by Ben Romer on 2017-02-07

UBUNTU: [Config] Drop irqbypas from PowerPC ABI

Signed-off-by: Benjamin M Romer <email address hidden>

ff1331f... by Thadeu Lima de Souza Cascardo on 2017-02-02

UBUNTU: [Config] Drop elants_i2c and pinctrl-cherryview from ABI

Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>

9e82a32... by Keno Fischer on 2017-01-27

UBUNTU: SAUCE: mm: Respect FOLL_FORCE/FOLL_COW for thp

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

In 19be0eaff ("mm: remove gup_flags FOLL_WRITE games from __get_user_pages()"),
the mm code was changed from unsetting FOLL_WRITE after a COW was resolved to
setting the (newly introduced) FOLL_COW instead. Simultaneously, the check in
gup.c was updated to still allow writes with FOLL_FORCE set if FOLL_COW had
also been set. However, a similar check in huge_memory.c was forgotten. As a
result, remote memory writes to ro regions of memory backed by transparent huge
pages cause an infinite loop in the kernel (handle_mm_fault sets FOLL_COW and
returns 0 causing a retry, but follow_trans_huge_pmd bails out immidiately
because `(flags & FOLL_WRITE) && !pmd_write(*pmd)` is true. While in this
state the process is stil SIGKILLable, but little else works (e.g. no ptrace
attach, no other signals). This is easily reproduced with the following
code (assuming thp are set to always):

    #include <assert.h>
    #include <fcntl.h>
    #include <stdint.h>
    #include <stdio.h>
    #include <string.h>
    #include <sys/mman.h>
    #include <sys/stat.h>
    #include <sys/types.h>
    #include <sys/wait.h>
    #include <unistd.h>

    #define TEST_SIZE 5 * 1024 * 1024

    int main(void) {
      int status;
      pid_t child;
      int fd = open("/proc/self/mem", O_RDWR);
      void *addr = mmap(NULL, TEST_SIZE, PROT_READ,
                        MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
      assert(addr != MAP_FAILED);
      pid_t parent_pid = getpid();
      if ((child = fork()) == 0) {
        void *addr2 = mmap(NULL, TEST_SIZE, PROT_READ | PROT_WRITE,
                           MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
        assert(addr2 != MAP_FAILED);
        memset(addr2, 'a', TEST_SIZE);
        pwrite(fd, addr2, TEST_SIZE, (uintptr_t)addr);
        return 0;
      }
      assert(child == waitpid(child, &status, 0));
      assert(WIFEXITED(status) && WEXITSTATUS(status) == 0);
      return 0;
    }

Fix this by updating follow_trans_huge_pmd in huge_memory.c analogously to
the update in gup.c in the original commit. The same pattern exists in
follow_devmap_pmd. However, we should not be able to reach that check
with FOLL_COW set, so add WARN_ONCE to make sure we notice if we ever
do.

Signed-off-by: Keno Fischer <email address hidden>
Acked-by: Kirill A. Shutemov <email address hidden>
Acked-by: Michal Hocko <email address hidden>
Tested-by: David Rientjes <email address hidden>
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>