- 03 Apr, 2018 13 commits
-
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1758856Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Juerg Haefliger <juergh@canonical.com>
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1758856Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1758856 These are always safe because there is no way rip can be an unknown. Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1758856Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1758856Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1758856 Use the upstream retpoline safe hinting support to clear out known safe retpoline sequences from those detected. At the same time switch to extracting the indirect sequences and associated hints to .o generation time. This allows it to be run on the cache hot data and to be run in parallel on the builders. Signed-off-by:
-
Andy Lutomirski authored
BugLink: http://bugs.launchpad.net/bugs/1758856 alternative.h pulls in ptrace.h, which means that alternatives can't be used in anything referenced from ptrace.h, which is a mess. Break the dependency by pulling text patching helpers into their own header. Signed-off-by:
Andy Lutomirski <luto@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/99b93b13f2c9eb671f5c98bba4c2cbdc061293a2.1461698311.git.luto@kernel.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> (backported from commit 35de5b06) Signed-off-by:
-
Peter Zijlstra authored
BugLink: http://bugs.launchpad.net/bugs/1758856 Paravirt emits indirect calls which get flagged by objtool retpoline checks, annotate it away because all these indirect calls will be patched out before we start userspace. This patching happens through alternative_instructions() -> apply_paravirt() -> pv_init_ops.patch() which will eventually end up in paravirt_patch_default(). This function _will_ write direct alternatives. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
David Woodhouse <dwmw@amazon.co.uk> Acked-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Arjan van de Ven <arjan@linux.intel.com> Cc: Borislav Petkov <bp@alien8.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1758856 In 9e0e3c51 ("x86/speculation, objtool: Annotate indirect calls/jumps for objtool") we added annotations for CALL_NOSPEC/JMP_NOSPEC on x86 64bit. We did not annotate the 32bit path. Annotate it similarly. [apw@canonical.com: backported to xenial.] Signed-off-by:
-
Peter Zijlstra authored
BugLink: http://bugs.launchpad.net/bugs/1758856 Annotate the indirect calls/jumps in the CALL_NOSPEC/JUMP_NOSPEC alternatives. Signed-off-by:
-
Steve Beattie authored
BugLink: http://bugs.launchpad.net/bugs/1758856 Catch indirect jmps and calls of the form 'jmp *0xNNNN(%reg)'. Signed-off-by:
Steve Beattie <steve.beattie@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1752655Signed-off-by:
-
Juerg Haefliger authored
Ignore: yes Signed-off-by:
-
- 31 Mar, 2018 4 commits
-
-
Khalid Elmously authored
Signed-off-by:Khalid Elmously <khalid.elmously@canonical.com>
-
Khalid Elmously authored
Retpoline files for i386 are empty for the previous ABIs. It has been fixed by commit "UBUNTU: [Packaging] retpoline-extract -- instantiate retpoline files for i386". So ignore the check from the previous ABI files. Ignore: yes Signed-off-by: -
Kai-Heng Feng authored
BugLink: http://bugs.launchpad.net/bugs/1759821 This reverts commit fd865802. This commit causes a regression on some QCA ROME chips. The USB device reset happens in btusb_open(), hence firmware loading gets interrupted. Furthermore, this commit stops working after commit ("a0085f25 Bluetooth: btusb: driver to enable the usb-wakeup feature"). Reset-resume quirk only gets enabled in btusb_suspend() when it's not a wakeup source. If we really want to reset the USB device, we need to do it before btusb_open(). Let's handle it in drivers/usb/core/quirks.c. Cc: stable@vger.kernel.org Cc: Leif Liddy <leif.linux@gmail.com> Cc: Matthias Kaehlcke <mka@chromium.org> Cc: Brian Norris <briannorris@chromium.org> Cc: Daniel Drake <drake@endlessm.com> Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by:
Brian Norris <briannorris@chromium.org> Tested-by:
Marcel Holtmann <marcel@holtmann.org> (cherry picked from commit 7d06d589) Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Acked-by:
-
Khalid Elmously authored
Ignore: yes Signed-off-by:
-
- 28 Mar, 2018 5 commits
-
-
Khalid Elmously authored
Signed-off-by: -
Khalid Elmously authored
Retpoline files for i386 are empty for the previous ABIs. It has been fixed by commit "UBUNTU: [Packaging] retpoline-extract -- instantiate retpoline files for i386". So ignore the check from the previous ABI files. Ignore: yes Signed-off-by: -
Borislav Petkov authored
BugLink: http://bugs.launchpad.net/bugs/1758869 commit a15a7535 upstream with minor adjustments. Doing so is completely void of sense for multiple reasons so prevent it. Set dis_ucode_ldr to true and thus disable the microcode loader by default to address xen pv guests which execute the AP path but not the BSP path. By having it turned off by default, the APs won't run into the loader either. Also, check CPUID(1).ECX[31] which hypervisors set. Well almost, not the xen pv one. That one gets the aforementioned "fix". Also, improve the detection method by caching the final decision whether to continue loading in dis_ucode_ldr and do it once on the BSP. The APs then simply test that value. Signed-off-by:
Borislav Petkov <bp@suse.de> Tested-by:
Juergen Gross <jgross@suse.com> Tested-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by:
Rolf Neugebauer <rolf.neugebauer@docker.com> (back-ported from commit a15a7535) Reference: https://lkml.org/lkml/2018/2/8/455Acked-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Wei Yongjun authored
CVE-2018-8043 platform_get_resource() may fail and return NULL, so we should better check it's return value to avoid a NULL pointer dereference a bit later in the code. This is detected by Coccinelle semantic patch. @@ expression pdev, res, n, t, e, e1, e2; @@ res = platform_get_resource(pdev, t, n); + if (!res) + return -EINVAL; ... when != res == NULL e = devm_ioremap(e1, res->start, e2); Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 297a6961) Signed-off-by:
Po-Hsu Lin <po-hsu.lin@canonical.com> Acked-by:
-
Stefan Bader authored
Ignore: yes Signed-off-by:
-
- 13 Mar, 2018 18 commits
-
-
Kleber Sacilotto de Souza authored
Signed-off-by:Kleber Sacilotto de Souza <kleber.souza@canonical.com>
-
Kleber Sacilotto de Souza authored
Retpoline files for i386 are empty for the previous ABIs. It has been fixed by commit "UBUNTU: [Packaging] retpoline-extract -- instantiate retpoline files for i386". So ignore the check from the previous ABI files. Ignore: yes Signed-off-by: -
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1754592Signed-off-by:
-
Ben Hutchings authored
BugLink: http://bugs.launchpad.net/bugs/1754592 commit 19952667 upstream. Commit bdcf0a42 ("kernel: make groups_sort calling a responsibility group_info allocators") appears to break nfsd rootsquash in a pretty major way. It adds a call to groups_sort() inside the loop that copies/squashes gids, which means the valid gids are sorted along with the following garbage. The net result is that the highest numbered valid gids are replaced with any lower-valued garbage gids, possibly including 0. We should sort only once, after filling in all the gids. Fixes: bdcf0a42 ("kernel: make groups_sort calling a responsibility ...") Signed-off-by:
Ben Hutchings <ben.hutchings@codethink.co.uk> Acked-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Cc: Wolfgang Walter <linux@stwm.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Dan Streetman authored
BugLink: http://bugs.launchpad.net/bugs/1754592 [ Upstream commit 4ee806d5 ] When a tcp socket is closed, if it detects that its net namespace is exiting, close immediately and do not wait for FIN sequence. For normal sockets, a reference is taken to their net namespace, so it will never exit while the socket is open. However, kernel sockets do not take a reference to their net namespace, so it may begin exiting while the kernel socket is still open. In this case if the kernel socket is a tcp socket, it will stay open trying to complete its close sequence. The sock's dst(s) hold a reference to their interface, which are all transferred to the namespace's loopback interface when the real interfaces are taken down. When the namespace tries to take down its loopback interface, it hangs waiting for all references to the loopback interface to release, which results in messages like: unregister_netdevice: waiting for lo to become free. Usage count = 1 These messages continue until the socket finally times out and closes. Since the net namespace cleanup holds the net_mutex while calling its registered pernet callbacks, any new net namespace initialization is blocked until the current net namespace finishes exiting. After this change, the tcp socket notices the exiting net namespace, and closes immediately, releasing its dst(s) and their reference to the loopback interface, which lets the net namespace continue exiting. Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1711407 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=97811Signed-off-by:
Dan Streetman <ddstreet@canonical.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1754592 [ Upstream commit d0c081b4 ] syzbot reported yet another crash [1] that is caused by insufficient validation of DODGY packets. Two bugs are happening here to trigger the crash. 1) Flow dissection leaves with incorrect thoff field. 2) skb_probe_transport_header() sets transport header to this invalid thoff, even if pointing after skb valid data. 3) qdisc_pkt_len_init() reads out-of-bound data because it trusts tcp_hdrlen(skb) Possible fixes : - Full flow dissector validation before injecting bad DODGY packets in the stack. This approach was attempted here : https://patchwork.ozlabs.org/patch/ 861874/ - Have more robust functions in the core. This might be needed anyway for stable versions. This patch fixes the flow dissection issue. [1] CPU: 1 PID: 3144 Comm: syzkaller271204 Not tainted 4.15.0-rc4-mm1+ #49 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:17 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:53 print_address_description+0x73/0x250 mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:355 [inline] kasan_report+0x23b/0x360 mm/kasan/report.c:413 __asan_report_load2_noabort+0x14/0x20 mm/kasan/report.c:432 __tcp_hdrlen include/linux/tcp.h:35 [inline] tcp_hdrlen include/linux/tcp.h:40 [inline] qdisc_pkt_len_init net/core/dev.c:3160 [inline] __dev_queue_xmit+0x20d3/0x2200 net/core/dev.c:3465 dev_queue_xmit+0x17/0x20 net/core/dev.c:3554 packet_snd net/packet/af_packet.c:2943 [inline] packet_sendmsg+0x3ad5/0x60a0 net/packet/af_packet.c:2968 sock_sendmsg_nosec net/socket.c:628 [inline] sock_sendmsg+0xca/0x110 net/socket.c:638 sock_write_iter+0x31a/0x5d0 net/socket.c:907 call_write_iter include/linux/fs.h:1776 [inline] new_sync_write fs/read_write.c:469 [inline] __vfs_write+0x684/0x970 fs/read_write.c:482 vfs_write+0x189/0x510 fs/read_write.c:544 SYSC_write fs/read_write.c:589 [inline] SyS_write+0xef/0x220 fs/read_write.c:581 entry_SYSCALL_64_fastpath+0x1f/0x96 Fixes: 34fad54c ("net: __skb_flow_dissect() must cap its return value") Fixes: a6e544b0 ("flow_dissector: Jump to exit code in __skb_flow_dissect") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Willem de Bruijn <willemb@google.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
-
Jim Westfall authored
BugLink: http://bugs.launchpad.net/bugs/1754592 [ Upstream commit cd9ff4de ] Map all lookup neigh keys to INADDR_ANY for loopback/point-to-point devices to avoid making an entry for every remote ip the device needs to talk to. This used the be the old behavior but became broken in a263b309 (ipv4: Make neigh lookups directly in output packet path) and later removed in 0bb4087c (ipv4: Fix neigh lookup keying over loopback/point-to-point devices) because it was broken. Signed-off-by:
Jim Westfall <jwestfall@surrealistic.net> Signed-off-by:
-
Jim Westfall authored
BugLink: http://bugs.launchpad.net/bugs/1754592 [ Upstream commit 096b9854 ] Use n->primary_key instead of pkey to account for the possibility that a neigh constructor function may have modified the primary_key value. Signed-off-by:
-
Neil Horman authored
BugLink: http://bugs.launchpad.net/bugs/1754592 [ Upstream commit 848b1598 ] with the introduction of commit b0eb57cb, it appears that rq->buf_info is improperly handled. While it is heap allocated when an rx queue is setup, and freed when torn down, an old line of code in vmxnet3_rq_destroy was not properly removed, leading to rq->buf_info[0] being set to NULL prior to its being freed, causing a memory leak, which eventually exhausts the system on repeated create/destroy operations (for example, when the mtu of a vmxnet3 interface is changed frequently. Fix is pretty straight forward, just move the NULL set to after the free. Tested by myself with successful results Applies to net, and should likely be queued for stable, please Signed-off-by:
Neil Horman <nhorman@tuxdriver.com> Reported-By: boyang@redhat.com CC: boyang@redhat.com CC: Shrikrishna Khare <skhare@vmware.com> CC: "VMware, Inc." <pv-drivers@vmware.com> CC: David S. Miller <davem@davemloft.net> Acked-by:
Shrikrishna Khare <skhare@vmware.com> Signed-off-by:
-
Xin Long authored
BugLink: http://bugs.launchpad.net/bugs/1754592 [ Upstream commit a0ff6600 ] After commit cea0cc80 ("sctp: use the right sk after waking up from wait_buf sleep"), it may change to lock another sk if the asoc has been peeled off in sctp_wait_for_sndbuf. However, the asoc's new sk could be already closed elsewhere, as it's in the sendmsg context of the old sk that can't avoid the new sk's closing. If the sk's last one refcnt is held by this asoc, later on after putting this asoc, the new sk will be freed, while under it's own lock. This patch is to revert that commit, but fix the old issue by returning error under the old sk's lock. Fixes: cea0cc80 ("sctp: use the right sk after waking up from wait_buf sleep") Reported-by: syzbot+ac6ea7baa4432811eb50@syzkaller.appspotmail.com Signed-off-by:
Xin Long <lucien.xin@gmail.com> Acked-by:
-
Xin Long authored
BugLink: http://bugs.launchpad.net/bugs/1754592 [ Upstream commit c5006b8a ] The check in sctp_sockaddr_af is not robust enough to forbid binding a v4mapped v6 addr on a v4 socket. The worse thing is that v4 socket's bind_verify would not convert this v4mapped v6 addr to a v4 addr. syzbot even reported a crash as the v4 socket bound a v6 addr. This patch is to fix it by doing the common sa.sa_family check first, then AF_INET check for v4mapped v6 addrs. Fixes: 7dab83de ("sctp: Support ipv6only AF_INET6 sockets.") Reported-by: syzbot+7b7b518b1228d2743963@syzkaller.appspotmail.com Acked-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
-
Francois Romieu authored
BugLink: http://bugs.launchpad.net/bugs/1754592 [ Upstream commit a78e9366 ] Hardware statistics retrieval hurts in tight invocation loops. Avoid extraneous write and enforce strict ordering of writes targeted to the tally counters dump area address registers. Signed-off-by:
Francois Romieu <romieu@fr.zoreil.com> Tested-by:
Oliver Freyermuth <o.freyermuth@googlemail.com> Signed-off-by:
-
Guillaume Nault authored
BugLink: http://bugs.launchpad.net/bugs/1754592 [ Upstream commit 02612bb0 ] In pppoe_sendmsg(), reserving dev->hard_header_len bytes of headroom was probably fine before the introduction of ->needed_headroom in commit f5184d26 ("net: Allow netdevices to specify needed head/tailroom"). But now, virtual devices typically advertise the size of their overhead in dev->needed_headroom, so we must also take it into account in skb_reserve(). Allocation size of skb is also updated to take dev->needed_tailroom into account and replace the arbitrary 32 bytes with the real size of a PPPoE header. This issue was discovered by syzbot, who connected a pppoe socket to a gre device which had dev->header_ops->create == ipgre_header and dev->hard_header_len == 0. Therefore, PPPoE didn't reserve any headroom, and dev_hard_header() crashed when ipgre_header() tried to prepend its header to skb->data. skbuff: skb_under_panic: text:000000001d390b3a len:31 put:24 head:00000000d8ed776f data:000000008150e823 tail:0x7 end:0xc0 dev:gre0 ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:104! invalid opcode: 0000 [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 1 PID: 3670 Comm: syzkaller801466 Not tainted 4.15.0-rc7-next-20180115+ #97 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:skb_panic+0x162/0x1f0 net/core/skbuff.c:100 RSP: 0018:ffff8801d9bd7840 EFLAGS: 00010282 RAX: 0000000000000083 RBX: ffff8801d4f083c0 RCX: 0000000000000000 RDX: 0000000000000083 RSI: 1ffff1003b37ae92 RDI: ffffed003b37aefc RBP: ffff8801d9bd78a8 R08: 1ffff1003b37ae8a R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: ffffffff86200de0 R13: ffffffff84a981ad R14: 0000000000000018 R15: ffff8801d2d34180 FS: 00000000019c4880(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000208bc000 CR3: 00000001d9111001 CR4: 00000000001606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_under_panic net/core/skbuff.c:114 [inline] skb_push+0xce/0xf0 net/core/skbuff.c:1714 ipgre_header+0x6d/0x4e0 net/ipv4/ip_gre.c:879 dev_hard_header include/linux/netdevice.h:2723 [inline] pppoe_sendmsg+0x58e/0x8b0 drivers/net/ppp/pppoe.c:890 sock_sendmsg_nosec net/socket.c:630 [inline] sock_sendmsg+0xca/0x110 net/socket.c:640 sock_write_iter+0x31a/0x5d0 net/socket.c:909 call_write_iter include/linux/fs.h:1775 [inline] do_iter_readv_writev+0x525/0x7f0 fs/read_write.c:653 do_iter_write+0x154/0x540 fs/read_write.c:932 vfs_writev+0x18a/0x340 fs/read_write.c:977 do_writev+0xfc/0x2a0 fs/read_write.c:1012 SYSC_writev fs/read_write.c:1085 [inline] SyS_writev+0x27/0x30 fs/read_write.c:1082 entry_SYSCALL_64_fastpath+0x29/0xa0 Admittedly PPPoE shouldn't be allowed to run on non Ethernet-like interfaces, but reserving space for ->needed_headroom is a more fundamental issue that needs to be addressed first. Same problem exists for __pppoe_xmit(), which also needs to take dev->needed_headroom into account in skb_cow_head(). Fixes: f5184d26 ("net: Allow netdevices to specify needed head/tailroom") Reported-by: syzbot+ed0838d0fa4c4f2b528e20286e6dc63effc7c14d@syzkaller.appspotmail.com Signed-off-by:
Guillaume Nault <g.nault@alphalink.fr> Reviewed-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1754592 [ Upstream commit 7c68d1a6 ] Without proper validation of DODGY packets, we might very well feed qdisc_pkt_len_init() with invalid GSO packets. tcp_hdrlen() might access out-of-bound data, so let's use skb_header_pointer() and proper checks. Whole story is described in commit d0c081b4 ("flow_dissector: properly cap thoff field") We have the goal of validating DODGY packets earlier in the stack, so we might very well revert this fix in the future. Signed-off-by:
-
Craig Gallek authored
BugLink: http://bugs.launchpad.net/bugs/1754592 commit d9b3fca2 upstream. tcp_hdrlen is wasteful if you already have a pointer to struct tcphdr. This splits the size calculation into a helper function that can be used if a struct tcphdr is already available. Signed-off-by:
Craig Gallek <kraig@google.com> Signed-off-by:
-
Felix Fietkau authored
BugLink: http://bugs.launchpad.net/bugs/1754592 [ Upstream commit ad23b750 ] Commit "net: igmp: Use correct source address on IGMPv3 reports" introduced a check to validate the source address of locally generated IGMPv3 packets. Instead of checking the local interface address directly, it uses inet_ifa_match(fl4->saddr, ifa), which checks if the address is on the local subnet (or equal to the point-to-point address if used). This breaks for point-to-point interfaces, so check against ifa->ifa_local directly. Cc: Kevin Cernekee <cernekee@chromium.org> Fixes: a46182b0 ("net: igmp: Use correct source address on IGMPv3 reports") Reported-by:
Sebastian Gottschall <s.gottschall@dd-wrt.com> Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
Florian Wolters <florian@florian-wolters.de> Signed-off-by:
-
Yuiko Oshino authored
BugLink: http://bugs.launchpad.net/bugs/1754592 [ Upstream commit a5b1379a ] Fix initialize the uninitialized tx_qlen to an appropriate value when USB Full Speed is used. Fixes: 55d7de9d ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by:
Yuiko Oshino <yuiko.oshino@microchip.com> Signed-off-by:
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1754592 [ Upstream commit 95ef498d ] In my last patch, I missed fact that cork.base.dst was not initialized in ip6_make_skb() : If ip6_setup_cork() returns an error, we might attempt a dst_release() on some random pointer. Fixes: 862c03ee ("ipv6: fix possible mem leaks in ipv6_make_skb()") Signed-off-by:
-
