Since commit 92a0f81d8957 ("x86/cpu_entry_area: Move it out of the
fixmap"), i386's CPU_ENTRY_AREA has been mapped to the memory area just
below FIXADDR_START. But already immediately before FIXADDR_START is the
FIX_BTMAP area, which means that early_ioremap can collide with the entry
area.
It's especially bad on PAE where FIX_BTMAP_BEGIN gets aligned to exactly
match CPU_ENTRY_AREA_BASE, so the first early_ioremap slot clobbers the
IDT and causes interrupts during early boot to reset the system.
The overlap wasn't a problem before the CPU entry area was introduced,
as the fixmap has classically been preceded by the pkmap or vmalloc
areas, neither of which is used until early_ioremap is out of the
picture.
Relocate CPU_ENTRY_AREA to below FIX_BTMAP, not just below the permanent
fixmap area.
Fixes: commit 92a0f81d8957 ("x86/cpu_entry_area: Move it out of the fixmap")
Signed-off-by: William Grant <email address hidden>
Signed-off-by: Thomas Gleixner <email address hidden>
Cc: <email address hidden>
Link: https://<email address hidden>
(cherry picked from commit 55f49fcb879fbeebf2a8c1ac7c9e6d90df55f798 git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git)
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Acked-by: Thadeu Lima de Souza Cascardo <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
ipgre tap driver calls ether_setup(), after commit 61e84623ace3
("net: centralize net_device min/max MTU checking"), the range
of mtu is [min_mtu, max_mtu], which is [68, 1500] by default.
It causes the dev mtu of the ipgre tap device to not be greater
than 1500, this limit value is not correct for ipgre tap device.
Besides, it's .change_mtu already does the right check. So this
patch is just to set max_mtu as 0, and leave the check to it's
.change_mtu.
Fixes: 61e84623ace3 ("net: centralize net_device min/max MTU checking")
Reported-by: Jianlin Shi <email address hidden>
Signed-off-by: Xin Long <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
(cherry picked from commit cfddd4c33c254954927942599d299b3865743146)
Signed-off-by: Joseph Salisbury <email address hidden>
Acked-by: Seth Forshee <email address hidden>
Acked-by: Kleber Sacilotto de Souza <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
b128290...
by
Mohamed Ghannam <email address hidden>
net: ipv4: fix for a race condition in raw_sendmsg
inet->hdrincl is racy, and could lead to uninitialized stack pointer
usage, so its value should be read only once.
Fixes: c008ba5bdc9f ("ipv4: Avoid reading user iov twice after raw_probe_proto_opt")
Signed-off-by: Mohamed Ghannam <email address hidden>
Reviewed-by: Eric Dumazet <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
CVE-2017-17712
(cherry picked from commit 8f659a03a0ba9289b9aeb9b4470e6fb263d6f483)
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Khalid Elmously <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
sctp: do not peel off an assoc from one netns to another one
Now when peeling off an association to the sock in another netns, all
transports in this assoc are not to be rehashed and keep use the old
key in hashtable.
As a transport uses sk->net as the hash key to insert into hashtable,
it would miss removing these transports from hashtable due to the new
netns when closing the sock and all transports are being freeed, then
later an use-after-free issue could be caused when looking up an asoc
and dereferencing those transports.
This is a very old issue since very beginning, ChunYu found it with
syzkaller fuzz testing with this series:
This patch is to block this call when peeling one assoc off from one
netns to another one, so that the netns of all transport would not
go out-sync with the key in hashtable.
Note that this patch didn't fix it by rehashing transports, as it's
difficult to handle the situation when the tuple is already in use
in the new netns. Besides, no one would like to peel off one assoc
to another netns, considering ipaddrs, ifaces, etc. are usually
different.
Reported-by: ChunYu Wang <email address hidden>
Signed-off-by: Xin Long <email address hidden>
Acked-by: Marcelo Ricardo Leitner <email address hidden>
Acked-by: Neil Horman <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
CVE-2017-15115
(cherry picked from commit df80cd9b28b9ebaa284a41df611dbf3a2d05ca74)
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Acked-by: Stefan Bader <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
4723038...
by
Mohamed Ghannam <email address hidden>
dccp: CVE-2017-8824: use-after-free in DCCP code
Whenever the sock object is in DCCP_CLOSED state,
dccp_disconnect() must free dccps_hc_tx_ccid and
dccps_hc_rx_ccid and set to NULL.
Signed-off-by: Mohamed Ghannam <email address hidden>
Reviewed-by: Eric Dumazet <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
CVE-2017-8824
(cherry picked from commit 69c64866ce072dea1d1e59a0d61e0f66c0dffb76 linux-next)
Signed-off-by: Kleber Sacilotto de Souza <email address hidden>
Acked-by: Seth Forshee <email address hidden>
Acked-by: Colin Ian King <email address hidden>
Signed-off-by: Thadeu Lima de Souza Cascardo <email address hidden>
UBUNTU: SAUCE: x86/entry: Fix up retpoline assembler labels
The extant assembler labels in entry_SYSCALL_64_fastpath
result in the error path incorrectly entering the retpoline logic.
This results in that logic jumping to whatever address is in %r10,
which is the fourth system call argument.
This enables a trivial means to instruct the kernel to jump
to any arbitrary address. Non-malicious executables making invalid
system calls may also cause the system to crash.
Resolve this by renumbering the assembler labels as is found
in other kernels.
CVE-2017-5753
CVE-2017-5715
Fixes: d2e0236 ("x86/entry: Use retpoline for syscall's indirect calls")
Signed-off-by: Jay Vosburgh <email address hidden>
Signed-off-by: Stefan Bader <email address hidden>
