UBUNTU: [Packaging] git-ubuntu-log -- fix order of tracking bug commit
The package tracking bug number is not inserted anymore on the changelog
by the link-to-tracker script. Instead, it creates/updates the
debian.<branch>/tracking-bug file and commits the change.
We want this commit to be added to the changelog in a similar fashion as
before, as the first entry. So change the git-ubuntu-log script to
detect that commit and insert it in the right place.
Ignore: yes
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
(cherry picked from commit 7f9d019c89d0ea59a55cda167bd247fe5c0c3daf xenial)
Signed-off-by: Stefan Bader <email address hidden>
tcp: detect malicious patterns in tcp_collapse_ofo_queue()
In case an attacker feeds tiny packets completely out of order,
tcp_collapse_ofo_queue() might scan the whole rb-tree, performing
expensive copies, but not changing socket memory usage at all.
1) Do not attempt to collapse tiny skbs.
2) Add logic to exit early when too many tiny skbs are detected.
We prefer not doing aggressive collapsing (which copies packets)
for pathological flows, and revert to tcp_prune_ofo_queue() which
will be less expensive.
In the future, we might add the possibility of terminating flows
that are proven to be malicious.
Signed-off-by: Eric Dumazet <email address hidden>
Acked-by: Soheil Hassas Yeganeh <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
CVE-2018-5390
(backported from commit 3d4bf93ac12003f9b8e1e2de37fe27983deebdcf)
Signed-off-by: Tyler Hicks <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
(cherry picked from commit d42da7c941b77be76986c995fb410e9c8abff4d4 xenial)
Signed-off-by: Stefan Bader <email address hidden>
tcp: avoid collapses in tcp_prune_queue() if possible
Right after a TCP flow is created, receiving tiny out of order
packets allways hit the condition :
if (atomic_read(&sk->sk_rmem_alloc) >= sk->sk_rcvbuf)
tcp_clamp_window(sk);
tcp_clamp_window() increases sk_rcvbuf to match sk_rmem_alloc
(guarded by tcp_rmem[2])
Calling tcp_collapse_ofo_queue() in this case is not useful,
and offers a O(N^2) surface attack to malicious peers.
Better not attempt anything before full queue capacity is reached,
forcing attacker to spend lots of resource and allow us to more
easily detect the abuse.
Signed-off-by: Eric Dumazet <email address hidden>
Acked-by: Soheil Hassas Yeganeh <email address hidden>
Acked-by: Yuchung Cheng <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
When limiting the argv/envp strings during exec to 1/4 of the stack limit,
the storage of the pointers to the strings was not included. This means
that an exec with huge numbers of tiny strings could eat 1/4 of the stack
limit in strings and then additional space would be later used by the
pointers to the strings.
For example, on 32-bit with a 8MB stack rlimit, an exec with 1677721
single-byte strings would consume less than 2MB of stack, the max (8MB /
4) amount allowed, but the pointers to the strings would consume the
remaining additional stack space (1677721 * 4 == 6710884).
The result (1677721 + 6710884 == 8388605) would exhaust stack space
entirely. Controlling this stack exhaustion could result in
pathological behavior in setuid binaries (CVE-2017-1000365).
Signed-off-by: Stefan Bader <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
(cherry picked from commit ab9e622da2103654d6b6e2a6afd37504b3d38abe xenial)
Signed-off-by: Stefan Bader <email address hidden>
4744d72...
by
Andrey Konovalov <email address hidden>
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
(cherry-picked from 5edabca9d4cff7f1f2b68f0bac55ef99d9798ba4 davem)
Signed-off-by: Stefan Bader <email address hidden>
(cherry picked from commit 4feb04ade2a559e0e76a0215d259c5673e5b1cbd xenial)
Signed-off-by: Stefan Bader <email address hidden>
timer_create() specifies via sigevent->sigev_notify the signal delivery for
the new timer. The valid modes are SIGEV_NONE, SIGEV_SIGNAL, SIGEV_THREAD
and (SIGEV_SIGNAL | SIGEV_THREAD_ID).
The sanity check in good_sigevent() is only checking the valid combination
for the SIGEV_THREAD_ID bit, i.e. SIGEV_SIGNAL, but if SIGEV_THREAD_ID is
not set it accepts any random value.
This has no real effects on the posix timer and signal delivery code, but
it affects show_timer() which handles the output of /proc/$PID/timers. That
function uses a string array to pretty print sigev_notify. The access to
that array has no bound checks, so random sigev_notify cause access beyond
the array bounds.
Add proper checks for the valid notify modes and remove the SIGEV_THREAD_ID
masking from various code pathes as SIGEV_NONE can never be set in
combination with SIGEV_THREAD_ID.
