- 16 May, 2018 24 commits
-
-
Kees Cook authored
CVE-2018-3639 (x86) One of the easiest ways to protect the kernel from attack is to reduce the internal attack surface exposed when a "write" flaw is available. By making as much of the kernel read-only as possible, we reduce the attack surface. Many things are written to only during __init, and never changed again. These cannot be made "const" since the compiler will do the wrong thing (we do actually need to write to them). Instead, move these items into a memory region that will be made read-only during mark_rodata_ro() which happens after all kernel __init code has finished. This introduces __ro_after_init as a way to mark such memory, and adds some documentation about the existing __read_mostly marking. This improves the security of the Linux kernel by marking formerly read-write memory regions as read-only on a fully booted up system. Based on work by PaX Team and Brad Spengler. Signed-off-by:
Kees Cook <keescook@chromium.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brad Spengler <spender@grsecurity.net> Cc: Brian Gerst <brgerst@gmail.com> Cc: David Brown <david.brown@linaro.org> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: Emese Revfy <re.emese@gmail.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mathias Krause <minipli@googlemail.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: PaX Team <pageexec@freemail.hu> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: kernel-hardening@lists.openwall.com Cc: linux-arch <linux-arch@vger.kernel.org> Link: http://lkml.kernel.org/r/1455748879-21872-5-git-send-email-keescook@chromium.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> (cherry picked from commit c74ba8b3) Signed-off-by:
Juerg Haefliger <juergh@canonical.com>
-
Konrad Rzeszutek Wilk authored
CVE-2018-3639 (x86) Those SysFS functions have a similar preamble, as such make common code to handle them. Suggested-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Reviewed-by:
-
Konrad Rzeszutek Wilk authored
CVE-2018-3639 (x86) Combine the various logic which goes through all those x86_cpu_id matching structures in one function. Suggested-by:
Tyler Hicks <tyhicks@canonical.com> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
-
Linus Torvalds authored
CVE-2018-3639 (x86) The macro is not type safe and I did look for why that "g" constraint for the asm doesn't work: it's because the asm is more fundamentally wrong. It does movl %[val], %%eax but "val" isn't a 32-bit value, so then gcc will pass it in a register, and generate code like movl %rsi, %eax and gas will complain about a nonsensical 'mov' instruction (it's moving a 64-bit register to a 32-bit one). Passing it through memory will just hide the real bug - gcc still thinks the memory location is 64-bit, but the "movl" will only load the first 32 bits and it all happens to work because x86 is little-endian. Convert it to a type safe inline function with a little trick which hands the feature into the ALTERNATIVE macro. Signed-off-by:Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Stefan Bader authored
CVE-2018-3639 (x86) This is a partial backport of dd84441a "x86/speculation: Use IBRS if available before calling into firmware" as later patches rely on the call. Signed-off-by:
-
Juerg Haefliger authored
CVE-2018-3639 (x86) Now that we have generic, vendor-agnostic support of IBPB/IBRS feature detection in common code, move the code to enable/disable it from the vendor-specifc init_<vendor> functions to the common code. Except for the AMD special case where we need to write an MSR on every CPU. Keep that in init_amd() which runs on every CPU, whereas the common code mentioned above only runs once when CPU 0 is being onlined. Signed-off-by: -
David Woodhouse authored
CVE-2018-3639 (x86) (cherry picked from commit 7fcae111) Despite the fact that all the other code there seems to be doing it, just using set_cpu_cap() in early_intel_init() doesn't actually work. For CPUs with PKU support, setup_pku() calls get_cpu_cap() after c->c_init() has set those feature bits. That resets those bits back to what was queried from the hardware. Turning the bits off for bad microcode is easy to fix. That can just use setup_clear_cpu_cap() to force them off for all CPUs. I was less keen on forcing the feature bits *on* that way, just in case of inconsistencies. I appreciate that the kernel is going to get this utterly wrong if CPU features are not consistent, because it has already applied alternatives by the time secondary CPUs are brought up. But at least if setup_force_cpu_cap() isn't being used, we might have a chance of *detecting* the lack of the corresponding bit and either panicking or refusing to bring the offending CPU online. So ensure that the appropriate feature bits are set within get_cpu_cap() regardless of how many extra times it's called. Fixes: 2961298e ("x86/cpufeatures: Clean up Spectre v2 related CPUID flags") Signed-off-by:
David Woodhouse <dwmw@amazon.co.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit cda6b607 linux-4.9.y) Signed-off-by:
-
David Woodhouse authored
CVE-2018-3639 (x86) (cherry picked from commit 2961298e) We want to expose the hardware features simply in /proc/cpuinfo as "ibrs", "ibpb" and "stibp". Since AMD has separate CPUID bits for those, use them as the user-visible bits. When the Intel SPEC_CTRL bit is set which indicates both IBRS and IBPB capability, set those (AMD) bits accordingly. Likewise if the Intel STIBP bit is set, set the AMD STIBP that's used for the generic hardware capability. Hide the rest from /proc/cpuinfo by putting "" in the comments. Including RETPOLINE and RETPOLINE_AMD which shouldn't be visible there. There are patches to make the sysfs vulnerabilities information non-readable by non-root, and the same should apply to all information about which mitigations are actually in use. Those *shouldn't* appear in /proc/cpuinfo. The feature bit for whether IBPB is actually used, which is needed for ALTERNATIVEs, is renamed to X86_FEATURE_USE_IBPB. Originally-by:
-
Peter Zijlstra authored
CVE-2018-3639 (x86) commit ea00f301 upstream. Joe Konno reported a compile failure resulting from using an MSR without inclusion of <asm/msr-index.h>, and while the current code builds fine (by accident) this needs fixing for future patches. Reported-by:
Joe Konno <joe.konno@linux.intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: arjan@linux.intel.com Cc: bp@alien8.de Cc: dan.j.williams@intel.com Cc: dave.hansen@linux.intel.com Cc: dwmw2@infradead.org Cc: dwmw@amazon.co.uk Cc: gregkh@linuxfoundation.org Cc: hpa@zytor.com Cc: jpoimboe@redhat.com Cc: linux-tip-commits@vger.kernel.org Cc: luto@kernel.org Fixes: 20ffa1ca ("x86/speculation: Add basic IBPB (Indirect Branch Prediction Barrier) support") Link: http://lkml.kernel.org/r/20180213132819.GJ25201@hirez.programming.kicks-ass.netSigned-off-by:
-
David Woodhouse authored
CVE-2018-3639 (x86) (cherry picked from commit 20ffa1ca) Expose indirect_branch_prediction_barrier() for use in subsequent patches. [ tglx: Add IBPB status to spectre_v2 sysfs file ] Co-developed-by:
KarimAllah Ahmed <karahmed@amazon.de> Signed-off-by:
-
David Woodhouse authored
CVE-2018-3639 (x86) (cherry picked from commit a5b29663) This doesn't refuse to load the affected microcodes; it just refuses to use the Spectre v2 mitigation features if they're detected, by clearing the appropriate feature bits. The AMD CPUID bits are handled here too, because hypervisors *may* have been exposing those bits even on Intel chips, for fine-grained control of what's available. It is non-trivial to use x86_match_cpu() for this table because that doesn't handle steppings. And the approach taken in commit bd9240a1 almost made me lose my lunch. Signed-off-by:
-
David Woodhouse authored
CVE-2018-3639 (x86) (cherry picked from commit fec9434a) Also, for CPUs which don't speculate at all, don't report that they're vulnerable to the Spectre variants either. Leave the cpu_no_meltdown[] match table with just X86_VENDOR_AMD in it for now, even though that could be done with a simple comparison, on the assumption that we'll have more to add. Based on suggestions from Dave Hansen and Alan Cox. Signed-off-by:
Dave Hansen <dave.hansen@intel.com> Cc: gnomes@lxorguk.ukuu.org.uk Cc: ak@linux.intel.com Cc: ashok.raj@intel.com Cc: karahmed@amazon.de Cc: arjan@linux.intel.com Cc: torvalds@linux-foundation.org Cc: peterz@infradead.org Cc: bp@alien8.de Cc: pbonzini@redhat.com Cc: tim.c.chen@linux.intel.com Cc: gregkh@linux-foundation.org Link: https://lkml.kernel.org/r/1516896855-7642-6-git-send-email-dwmw@amazon.co.ukSigned-off-by:
-
Juerg Haefliger authored
CVE-2018-3639 (x86) With the previous commit 50d36d375b89 ("x86/msr: Add definitions for new speculation control MSRs") the spec control bits from upstream were introduced, so rename the existing bits to match upstream: FEATURE_ENABLE_IBRS -> SPEC_CTRL_IBRS FEATURE_SET_IBPB -> PRED_CMD_IBPB Signed-off-by: -
David Woodhouse authored
CVE-2018-3639 (x86) Add MSR and bit definitions for SPEC_CTRL, PRED_CMD and ARCH_CAPABILITIES. See Intel's 336996-Speculative-Execution-Side-Channel-Mitigations.pdf Signed-off-by:
-
David Woodhouse authored
CVE-2018-3639 (x86) AMD exposes the PRED_CMD/SPEC_CTRL MSRs slightly differently to Intel. See http://lkml.kernel.org/r/2b3e25cc-286d-8bd0-aeaf-9ac4aae39de8@amd.comSigned-off-by:
-
Juerg Haefliger authored
CVE-2018-3639 (x86) The SPEC_CTRL featured moved from the scattered list to a leaf, so expose it to the guest from the leaf rather than the scattered list. Signed-off-by: -
David Woodhouse authored
CVE-2018-3639 (x86) Add three feature bits exposed by new microcode on Intel CPUs for speculation control. Signed-off-by:
-
David Woodhouse authored
CVE-2018-3639 (x86) This is a pure feature bits leaf. Three feature bits from this leaf are going to be added for speculation control features. Signed-off-by:
-
Andy Lutomirski authored
CVE-2018-3639 (x86) A typo (or mis-merge?) resulted in leaf 6 only being probed if cpuid_level >= 7. Fixes: 2ccd71f1 ("x86/cpufeature: Move some of the scattered feature bits to x86_capability") Signed-off-by:
Andy Lutomirski <luto@kernel.org> Acked-by:
Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Link: http://lkml.kernel.org/r/6ea30c0e9daec21e488b54761881a6dfcf3e04d0.1481825597.git.luto@kernel.orgSigned-off-by:
-
Borislav Petkov authored
CVE-2018-3639 (x86) Add an enum for the ->x86_capability array indices and cleanup get_cpu_cap() by killing some redundant local vars. Signed-off-by:
-
Borislav Petkov authored
CVE-2018-3639 (x86) Turn the CPUID leafs which are proper CPUID feature bit leafs into separate ->x86_capability words. Signed-off-by:
-
Juerg Haefliger authored
CVE-2018-3639 (x86) Internally, kernel 4.4 uses the term KAISER instead of PTI, so drop X86_FEATURE_PTI (since X86_FEATURE_KAISER exists) and also rename DISABLE_PTI. Fixes: b2f8503b ("x86/cpufeatures: Add X86_BUG_CPU_INSECURE") Signed-off-by:
-
Juerg Haefliger authored
CVE-2018-3639 (x86) There's no Documentation/admin-guide/ in 4.4 ... Fixes: df043b74 ("x86/spec_ctrl: Add sysctl knobs to enable/disable SPEC_CTRL feature") Signed-off-by:
-
Juerg Haefliger authored
CVE-2018-3639 (x86) Remove definitions of trivial functions that are not used externally. Introduce #defines for the bits for better readability. No functional changes. Signed-off-by:
-
- 15 May, 2018 1 commit
-
-
Juerg Haefliger authored
Ignore: yes Signed-off-by:
-
- 09 May, 2018 15 commits
-
-
Stefan Bader authored
Signed-off-by: -
Thadeu Lima de Souza Cascardo authored
Function bpf_fill_maxinsns11 is designed to not be able to be JITed on x86_64. So, it fails when CONFIG_BPF_JIT_ALWAYS_ON=y, and commit 09584b40 ("bpf: fix selftests/bpf test_kmod.sh failure when CONFIG_BPF_JIT_ALWAYS_ON=y") makes sure that failure is detected on that case. However, it does not fail on other architectures, which have a different JIT compiler design. So, test_bpf has started to fail to load on those. After this fix, test_bpf loads fine on both x86_64 and ppc64el. Fixes: 09584b40 ("bpf: fix selftests/bpf test_kmod.sh failure when CONFIG_BPF_JIT_ALWAYS_ON=y") Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Reviewed-by:
Yonghong Song <yhs@fb.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> BugLink: https://bugs.launchpad.net/bugs/1765698 (cherry-picked from commit 52fda36d) Signed-off-by:
Colin King <colin.king@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by:
-
Yonghong Song authored
With CONFIG_BPF_JIT_ALWAYS_ON is defined in the config file, tools/testing/selftests/bpf/test_kmod.sh failed like below: [root@localhost bpf]# ./test_kmod.sh sysctl: setting key "net.core.bpf_jit_enable": Invalid argument [ JIT enabled:0 hardened:0 ] [ 132.175681] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096 [ 132.458834] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed] [ JIT enabled:1 hardened:0 ] [ 133.456025] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096 [ 133.730935] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed] [ JIT enabled:1 hardened:1 ] [ 134.769730] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096 [ 135.050864] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed] [ JIT enabled:1 hardened:2 ] [ 136.442882] test_bpf: #297 BPF_MAXINSNS: Jump, gap, jump, ... FAIL to prog_create err=-524 len=4096 [ 136.821810] test_bpf: Summary: 348 PASSED, 1 FAILED, [340/340 JIT'ed] [root@localhost bpf]# The test_kmod.sh load/remove test_bpf.ko multiple times with different settings for sysctl net.core.bpf_jit_{enable,harden}. The failed test #297 of test_bpf.ko is designed such that JIT always fails. Commit 290af866 (bpf: introduce BPF_JIT_ALWAYS_ON config) introduced the following tightening logic: ... if (!bpf_prog_is_dev_bound(fp->aux)) { fp = bpf_int_jit_compile(fp); #ifdef CONFIG_BPF_JIT_ALWAYS_ON if (!fp->jited) { *err = -ENOTSUPP; return fp; } #endif ... With this logic, Test #297 always gets return value -ENOTSUPP when CONFIG_BPF_JIT_ALWAYS_ON is defined, causing the test failure. This patch fixed the failure by marking Test #297 as expected failure when CONFIG_BPF_JIT_ALWAYS_ON is defined. Fixes: 290af866 (bpf: introduce BPF_JIT_ALWAYS_ON config) Signed-off-by: -
Jay Vosburgh authored
BugLink: http://bugs.launchpad.net/bugs/1765241 A race condition exists in virtio_scsi between the completion of a request and the freeing of the target structure. The race is between (a) virtscsi_complete_cmd that, first, wakes up a task waiting for a completion, then, second, releases a reference in the target structure and (b) the woken up task freeing that target structure. The race appears to exist in all verisons of virtio_scsi, but most kernels are not impacted due to a coincidental RCU sync in the "(b)" path above that will effectively wait for the "(a)" path to complete. The Ubuntu Xenial 4.4 kernel since commit be2a2080 lacks any RCU sync in the "(b)" code path, thus opening the race window. The fix is to wait for any outstanding requests to release their references prior to freeing the target structure. Signed-off-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Acked-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1763454 At the time this commit was backported some of the code it modifies was not present. When the code was later introduced from upstream stable it did not get the changes from this commit. Backport those changes now. v2: Also remove errant marking of instruction as seen from the backport. CVE-2017-17862 Fixes: 68dd63b2 ("bpf: fix branch pruning logic") Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
Juerg Haefliger <juerg.haefliger@canonical.com> Signed-off-by:
-
Colin Ian King authored
BugLink: http://bugs.launchpad.net/bugs/1764810 An previous backport to bug LP: #1745130 overlooked adding in an error return that was introduced by commit 6124c53e. Fix this by adding in the missing return. Detected by CoverityScan, CID#1467925 ("Missing return statement) Fixes: b9a5fffb ("rfkill: Add rfkill-any LED trigger") Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
-
Jay Vosburgh authored
BugLink: https://bugs.launchpad.net/bugs/1761534 The operstate update logic will leave an interface in the default UNKNOWN operstate if the interface carrier state never changes from the default carrier up state set at creation. This includes the case of an explicit call to netif_carrier_on, as the carrier on to on transition has no effect on operstate. This affects virtio-net for the case that the virtio peer does not support VIRTIO_NET_F_STATUS (the feature that provides carrier state updates). Without this feature, the virtio specification states that "the link should be assumed active," so, logically, the operstate should be UP instead of UNKNOWN. This has impact on user space applications that use the operstate to make availability decisions for the interface. Resolve this by changing the virtio probe logic slightly to call netif_carrier_off for both the "with" and "without" VIRTIO_NET_F_STATUS cases, and then the existing call to netif_carrier_on for the "without" case will cause an operstate transition. Cc: "Michael S. Tsirkin" <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry-picked from commit bda7fab5) Signed-off-by:
Eric Desrochers <eric.desrochers@canonical.com> Acked-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1765010Signed-off-by:
-
Greg Hackmann authored
BugLink: http://bugs.launchpad.net/bugs/1765010 Pixel 2 field testers reported that when they tried to reboot their phones with some USB devices plugged in, the reboot would get wedged and eventually trigger watchdog reset. Once the Pixel kernel team found a reliable repro case, they narrowed it down to this commit's 4.4.y backport. Reverting the change made the issue go away. This reverts commit b07c1251. Signed-off-by:
Greg Hackmann <ghackmann@google.com> Signed-off-by:
-
David Ahern authored
BugLink: http://bugs.launchpad.net/bugs/1765010 commit 82dd0d2a upstream. Miguel reported an skb use after free / double free in vrf_finish_output when neigh_output returns an error. The vrf driver should return after the call to neigh_output as it takes over the skb on error path as well. Patch is a simplified version of Miguel's patch which was written for 4.9, and updated to top of tree. Fixes: 8f58336d ("net: Add ethernet header for pass through VRF device") Signed-off-by:
Miguel Fadon Perlines <mfadon@teldat.com> Signed-off-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Paolo Abeni authored
BugLink: http://bugs.launchpad.net/bugs/1765010 [ Upstream commit 10b8a3de ] While building ipv6 datagram we currently allow arbitrary large extheaders, even beyond pmtu size. The syzbot has found a way to exploit the above to trigger the following splat: kernel BUG at ./include/linux/skbuff.h:2073! invalid opcode: 0000 [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 1 PID: 4230 Comm: syzkaller672661 Not tainted 4.16.0-rc2+ #326 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__skb_pull include/linux/skbuff.h:2073 [inline] RIP: 0010:__ip6_make_skb+0x1ac8/0x2190 net/ipv6/ip6_output.c:1636 RSP: 0018:ffff8801bc18f0f0 EFLAGS: 00010293 RAX: ffff8801b17400c0 RBX: 0000000000000738 RCX: ffffffff84f01828 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8801b415ac18 RBP: ffff8801bc18f360 R08: ffff8801b4576844 R09: 0000000000000000 R10: ffff8801bc18f380 R11: ffffed00367aee4e R12: 00000000000000d6 R13: ffff8801b415a740 R14: dffffc0000000000 R15: ffff8801b45767c0 FS: 0000000001535880(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000b000 CR3: 00000001b4123001 CR4: 00000000001606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ip6_finish_skb include/net/ipv6.h:969 [inline] udp_v6_push_pending_frames+0x269/0x3b0 net/ipv6/udp.c:1073 udpv6_sendmsg+0x2a96/0x3400 net/ipv6/udp.c:1343 inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:764 sock_sendmsg_nosec net/socket.c:630 [inline] sock_sendmsg+0xca/0x110 net/socket.c:640 ___sys_sendmsg+0x320/0x8b0 net/socket.c:2046 __sys_sendmmsg+0x1ee/0x620 net/socket.c:2136 SYSC_sendmmsg net/socket.c:2167 [inline] SyS_sendmmsg+0x35/0x60 net/socket.c:2162 do_syscall_64+0x280/0x940 arch/x86/entry/common.c:287 entry_SYSCALL_64_after_hwframe+0x42/0xb7 RIP: 0033:0x4404c9 RSP: 002b:00007ffdce35f948 EFLAGS: 00000217 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004404c9 RDX: 0000000000000003 RSI: 0000000020001f00 RDI: 0000000000000003 RBP: 00000000006cb018 R08: 00000000004002c8 R09: 00000000004002c8 R10: 0000000020000080 R11: 0000000000000217 R12: 0000000000401df0 R13: 0000000000401e80 R14: 0000000000000000 R15: 0000000000000000 Code: ff e8 1d 5e b9 fc e9 15 e9 ff ff e8 13 5e b9 fc e9 44 e8 ff ff e8 29 5e b9 fc e9 c0 e6 ff ff e8 3f f3 80 fc 0f 0b e8 38 f3 80 fc <0f> 0b 49 8d 87 80 00 00 00 4d 8d 87 84 00 00 00 48 89 85 20 fe RIP: __skb_pull include/linux/skbuff.h:2073 [inline] RSP: ffff8801bc18f0f0 RIP: __ip6_make_skb+0x1ac8/0x2190 net/ipv6/ip6_output.c:1636 RSP: ffff8801bc18f0f0 As stated by RFC 7112 section 5: When a host fragments an IPv6 datagram, it MUST include the entire IPv6 Header Chain in the First Fragment. So this patch addresses the issue dropping datagrams with excessive extheader length. It also updates the error path to report to the calling socket nonnegative pmtu values. The issue apparently predates git history. v1 -> v2: cleanup error path, as per Eric's suggestion Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by: syzbot+91e6f9932ff122fa4410@syzkaller.appspotmail.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Jeff Barnhill authored
BugLink: http://bugs.launchpad.net/bugs/1765010 [ Upstream commit 71a1c915 ] At the end of ip6_forward(), IPSTATS_MIB_OUTFORWDATAGRAMS and IPSTATS_MIB_OUTOCTETS are incremented immediately before the NF_HOOK call for NFPROTO_IPV6 / NF_INET_FORWARD. As a result, these counters get incremented regardless of whether or not the netfilter hook allows the packet to continue being processed. This change increments the counters in ip6_forward_finish() so that it will not happen if the netfilter hook chooses to terminate the packet, which is similar to how IPv4 works. Signed-off-by:
Jeff Barnhill <0xeffeff@gmail.com> Signed-off-by:
-
Craig Dillabaugh authored
BugLink: http://bugs.launchpad.net/bugs/1765010 [ Upstream commit 734549eb ] Fixes a bug in the tcf_dump_walker function that can cause some actions to not be reported when dumping a large number of actions. This issue became more aggrevated when cookies feature was added. In particular this issue is manifest when large cookie values are assigned to the actions and when enough actions are created that the resulting table must be dumped in multiple batches. The number of actions returned in each batch is limited by the total number of actions and the memory buffer size. With small cookies the numeric limit is reached before the buffer size limit, which avoids the code path triggering this bug. When large cookies are used buffer fills before the numeric limit, and the erroneous code path is hit. For example after creating 32 csum actions with the cookie aaaabbbbccccdddd $ tc actions ls action csum total acts 26 action order 0: csum (tcp) action continue index 1 ref 1 bind 0 cookie aaaabbbbccccdddd ..... action order 25: csum (tcp) action continue index 26 ref 1 bind 0 cookie aaaabbbbccccdddd total acts 6 action order 0: csum (tcp) action continue index 28 ref 1 bind 0 cookie aaaabbbbccccdddd ...... action order 5: csum (tcp) action continue index 32 ref 1 bind 0 cookie aaaabbbbccccdddd Note that the action with index 27 is omitted from the report. Fixes: 4b3550ef ("[NET_SCHED]: Use nla_nest_start/nla_nest_end")" Signed-off-by:
Craig Dillabaugh <cdillaba@mojatatu.com> Acked-by:
Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by:
-
Heiner Kallweit authored
BugLink: http://bugs.launchpad.net/bugs/1765010 [ Upstream commit 19c9ea36 ] pci_set_drvdata() is called only after registering the net_device, therefore we could run into a NPE if one of the functions using driver_data is called before it's set. Fix this by calling pci_set_drvdata() before registering the net_device. This fix is a candidate for stable. As far as I can see the bug has been there in kernel version 3.2 already, therefore I can't provide a reference which commit is fixed by it. The fix may need small adjustments per kernel version because due to other changes the label which is jumped to if register_netdev() fails has changed over time. Reported-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1765010 [ Upstream commit 537b361f ] Use valid_name() to make sure user does not provide illegal device name. Fixes: ed1efb2a ("ipv6: Add support for IPsec virtual tunnel interfaces") Signed-off-by:
-
