- Linux-stable-mirror - lists.linaro.org

[Linux-stable-mirror] Patch "bonding: discard lowest hash bit for 802.3ad layer3+4" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bonding: discard lowest hash bit for 802.3ad layer3+4 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bonding-discard-lowest-hash-bit-for-802.3ad-layer3-4.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:08:13 CET 2017 From: Hangbin Liu <liuhangbin(a)gmail.com> Date: Mon, 6 Nov 2017 09:01:57 +0800 Subject: bonding: discard lowest hash bit for 802.3ad layer3+4 From: Hangbin Liu <liuhangbin(a)gmail.com> [ Upstream commit b5f862180d7011d9575d0499fa37f0f25b423b12 ] After commit 07f4c90062f8 ("tcp/dccp: try to not exhaust ip_local_port_range in connect()"), we will try to use even ports for connect(). Then if an application (seen clearly with iperf) opens multiple streams to the same destination IP and port, each stream will be given an even source port. So the bonding driver's simple xmit_hash_policy based on layer3+4 addressing will always hash all these streams to the same interface. And the total throughput will limited to a single slave. Change the tcp code will impact the whole tcp behavior, only for bonding usage. Paolo Abeni suggested fix this by changing the bonding code only, which should be more reasonable, and less impact. Fix this by discarding the lowest hash bit because it contains little entropy. After the fix we can re-balance between slaves. Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/bonding/bond_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -3217,7 +3217,7 @@ u32 bond_xmit_hash(struct bonding *bond, hash ^= (hash >> 16); hash ^= (hash >> 8); - return hash; + return hash >> 1; } /*-------------------------- Device entry points ----------------------------*/ Patches currently in stable-queue which might be from liuhangbin(a)gmail.com are queue-4.9/bonding-discard-lowest-hash-bit-for-802.3ad-layer3-4.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "af_netlink: ensure that NLMSG_DONE never fails in dumps" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled af_netlink: ensure that NLMSG_DONE never fails in dumps to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: af_netlink-ensure-that-nlmsg_done-never-fails-in-dumps.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:08:13 CET 2017 From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> Date: Thu, 9 Nov 2017 13:04:44 +0900 Subject: af_netlink: ensure that NLMSG_DONE never fails in dumps From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> [ Upstream commit 0642840b8bb008528dbdf929cec9f65ac4231ad0 ] The way people generally use netlink_dump is that they fill in the skb as much as possible, breaking when nla_put returns an error. Then, they get called again and start filling out the next skb, and again, and so forth. The mechanism at work here is the ability for the iterative dumping function to detect when the skb is filled up and not fill it past the brim, waiting for a fresh skb for the rest of the data. However, if the attributes are small and nicely packed, it is possible that a dump callback function successfully fills in attributes until the skb is of size 4080 (libmnl's default page-sized receive buffer size). The dump function completes, satisfied, and then, if it happens to be that this is actually the last skb, and no further ones are to be sent, then netlink_dump will add on the NLMSG_DONE part: nlh = nlmsg_put_answer(skb, cb, NLMSG_DONE, sizeof(len), NLM_F_MULTI); It is very important that netlink_dump does this, of course. However, in this example, that call to nlmsg_put_answer will fail, because the previous filling by the dump function did not leave it enough room. And how could it possibly have done so? All of the nla_put variety of functions simply check to see if the skb has enough tailroom, independent of the context it is in. In order to keep the important assumptions of all netlink dump users, it is therefore important to give them an skb that has this end part of the tail already reserved, so that the call to nlmsg_put_answer does not fail. Otherwise, library authors are forced to find some bizarre sized receive buffer that has a large modulo relative to the common sizes of messages received, which is ugly and buggy. This patch thus saves the NLMSG_DONE for an additional message, for the case that things are dangerously close to the brim. This requires keeping track of the errno from ->dump() across calls. Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netlink/af_netlink.c | 17 +++++++++++------ net/netlink/af_netlink.h | 1 + 2 files changed, 12 insertions(+), 6 deletions(-) --- a/net/netlink/af_netlink.c +++ b/net/netlink/af_netlink.c @@ -2077,7 +2077,7 @@ static int netlink_dump(struct sock *sk) struct sk_buff *skb = NULL; struct nlmsghdr *nlh; struct module *module; - int len, err = -ENOBUFS; + int err = -ENOBUFS; int alloc_min_size; int alloc_size; @@ -2124,9 +2124,11 @@ static int netlink_dump(struct sock *sk) skb_reserve(skb, skb_tailroom(skb) - alloc_size); netlink_skb_set_owner_r(skb, sk); - len = cb->dump(skb, cb); + if (nlk->dump_done_errno > 0) + nlk->dump_done_errno = cb->dump(skb, cb); - if (len > 0) { + if (nlk->dump_done_errno > 0 || + skb_tailroom(skb) < nlmsg_total_size(sizeof(nlk->dump_done_errno))) { mutex_unlock(nlk->cb_mutex); if (sk_filter(sk, skb)) @@ -2136,13 +2138,15 @@ static int netlink_dump(struct sock *sk) return 0; } - nlh = nlmsg_put_answer(skb, cb, NLMSG_DONE, sizeof(len), NLM_F_MULTI); - if (!nlh) + nlh = nlmsg_put_answer(skb, cb, NLMSG_DONE, + sizeof(nlk->dump_done_errno), NLM_F_MULTI); + if (WARN_ON(!nlh)) goto errout_skb; nl_dump_check_consistent(cb, nlh); - memcpy(nlmsg_data(nlh), &len, sizeof(len)); + memcpy(nlmsg_data(nlh), &nlk->dump_done_errno, + sizeof(nlk->dump_done_errno)); if (sk_filter(sk, skb)) kfree_skb(skb); @@ -2214,6 +2218,7 @@ int __netlink_dump_start(struct sock *ss } nlk->cb_running = true; + nlk->dump_done_errno = INT_MAX; mutex_unlock(nlk->cb_mutex); --- a/net/netlink/af_netlink.h +++ b/net/netlink/af_netlink.h @@ -24,6 +24,7 @@ struct netlink_sock { wait_queue_head_t wait; bool bound; bool cb_running; + int dump_done_errno; struct netlink_callback cb; struct mutex *cb_mutex; struct mutex cb_def_mutex; Patches currently in stable-queue which might be from Jason(a)zx2c4.com are queue-4.9/af_netlink-ensure-that-nlmsg_done-never-fails-in-dumps.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "vxlan: fix the issue that neigh proxy blocks all icmpv6 packets" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vxlan: fix the issue that neigh proxy blocks all icmpv6 packets to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vxlan-fix-the-issue-that-neigh-proxy-blocks-all-icmpv6-packets.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:02 CET 2017 From: Xin Long <lucien.xin(a)gmail.com> Date: Sat, 11 Nov 2017 19:58:50 +0800 Subject: vxlan: fix the issue that neigh proxy blocks all icmpv6 packets From: Xin Long <lucien.xin(a)gmail.com> [ Upstream commit 8bff3685a4bbf175a96bc6a528f13455d8d38244 ] Commit f1fb08f6337c ("vxlan: fix ND proxy when skb doesn't have transport header offset") removed icmp6_code and icmp6_type check before calling neigh_reduce when doing neigh proxy. It means all icmpv6 packets would be blocked by this, not only ns packet. In Jianlin's env, even ping6 couldn't work through it. This patch is to bring the icmp6_code and icmp6_type check back and also removed the same check from neigh_reduce(). Fixes: f1fb08f6337c ("vxlan: fix ND proxy when skb doesn't have transport header offset") Reported-by: Jianlin Shi <jishi(a)redhat.com> Signed-off-by: Xin Long <lucien.xin(a)gmail.com> Reviewed-by: Vincent Bernat <vincent(a)bernat.im> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/vxlan.c | 31 +++++++++++++------------------ 1 file changed, 13 insertions(+), 18 deletions(-) --- a/drivers/net/vxlan.c +++ b/drivers/net/vxlan.c @@ -1623,26 +1623,19 @@ static struct sk_buff *vxlan_na_create(s static int neigh_reduce(struct net_device *dev, struct sk_buff *skb, __be32 vni) { struct vxlan_dev *vxlan = netdev_priv(dev); - struct nd_msg *msg; - const struct ipv6hdr *iphdr; const struct in6_addr *daddr; - struct neighbour *n; + const struct ipv6hdr *iphdr; struct inet6_dev *in6_dev; + struct neighbour *n; + struct nd_msg *msg; in6_dev = __in6_dev_get(dev); if (!in6_dev) goto out; - if (!pskb_may_pull(skb, sizeof(struct ipv6hdr) + sizeof(struct nd_msg))) - goto out; - iphdr = ipv6_hdr(skb); daddr = &iphdr->daddr; - msg = (struct nd_msg *)(iphdr + 1); - if (msg->icmph.icmp6_code != 0 || - msg->icmph.icmp6_type != NDISC_NEIGHBOUR_SOLICITATION) - goto out; if (ipv6_addr_loopback(daddr) || ipv6_addr_is_multicast(&msg->target)) @@ -2240,11 +2233,11 @@ tx_error: static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev) { struct vxlan_dev *vxlan = netdev_priv(dev); + struct vxlan_rdst *rdst, *fdst = NULL; const struct ip_tunnel_info *info; - struct ethhdr *eth; bool did_rsc = false; - struct vxlan_rdst *rdst, *fdst = NULL; struct vxlan_fdb *f; + struct ethhdr *eth; __be32 vni = 0; info = skb_tunnel_info(skb); @@ -2269,12 +2262,14 @@ static netdev_tx_t vxlan_xmit(struct sk_ if (ntohs(eth->h_proto) == ETH_P_ARP) return arp_reduce(dev, skb, vni); #if IS_ENABLED(CONFIG_IPV6) - else if (ntohs(eth->h_proto) == ETH_P_IPV6) { - struct ipv6hdr *hdr, _hdr; - if ((hdr = skb_header_pointer(skb, - skb_network_offset(skb), - sizeof(_hdr), &_hdr)) && - hdr->nexthdr == IPPROTO_ICMPV6) + else if (ntohs(eth->h_proto) == ETH_P_IPV6 && + pskb_may_pull(skb, sizeof(struct ipv6hdr) + + sizeof(struct nd_msg)) && + ipv6_hdr(skb)->nexthdr == IPPROTO_ICMPV6) { + struct nd_msg *m = (struct nd_msg *)(ipv6_hdr(skb) + 1); + + if (m->icmph.icmp6_code == 0 && + m->icmph.icmp6_type == NDISC_NEIGHBOUR_SOLICITATION) return neigh_reduce(dev, skb, vni); } #endif Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are queue-4.14/vxlan-fix-the-issue-that-neigh-proxy-blocks-all-icmpv6-packets.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "net/sctp: Always set scope_id in sctp_inet6_skb_msgname" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net/sctp: Always set scope_id in sctp_inet6_skb_msgname to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-sctp-always-set-scope_id-in-sctp_inet6_skb_msgname.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:02 CET 2017 From: "Eric W. Biederman" <ebiederm(a)xmission.com> Date: Wed, 15 Nov 2017 22:17:48 -0600 Subject: net/sctp: Always set scope_id in sctp_inet6_skb_msgname From: "Eric W. Biederman" <ebiederm(a)xmission.com> [ Upstream commit 7c8a61d9ee1df0fb4747879fa67a99614eb62fec ] Alexandar Potapenko while testing the kernel with KMSAN and syzkaller discovered that in some configurations sctp would leak 4 bytes of kernel stack. Working with his reproducer I discovered that those 4 bytes that are leaked is the scope id of an ipv6 address returned by recvmsg. With a little code inspection and a shrewd guess I discovered that sctp_inet6_skb_msgname only initializes the scope_id field for link local ipv6 addresses to the interface index the link local address pertains to instead of initializing the scope_id field for all ipv6 addresses. That is almost reasonable as scope_id's are meaniningful only for link local addresses. Set the scope_id in all other cases to 0 which is not a valid interface index to make it clear there is nothing useful in the scope_id field. There should be no danger of breaking userspace as the stack leak guaranteed that previously meaningless random data was being returned. Fixes: 372f525b495c ("SCTP: Resync with LKSCTP tree.") History-tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Reported-by: Alexander Potapenko <glider(a)google.com> Tested-by: Alexander Potapenko <glider(a)google.com> Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sctp/ipv6.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/net/sctp/ipv6.c +++ b/net/sctp/ipv6.c @@ -807,9 +807,10 @@ static void sctp_inet6_skb_msgname(struc addr->v6.sin6_flowinfo = 0; addr->v6.sin6_port = sh->source; addr->v6.sin6_addr = ipv6_hdr(skb)->saddr; - if (ipv6_addr_type(&addr->v6.sin6_addr) & IPV6_ADDR_LINKLOCAL) { + if (ipv6_addr_type(&addr->v6.sin6_addr) & IPV6_ADDR_LINKLOCAL) addr->v6.sin6_scope_id = sctp_v6_skb_iif(skb); - } + else + addr->v6.sin6_scope_id = 0; } *addr_len = sctp_v6_addr_to_user(sctp_sk(skb->sk), addr); Patches currently in stable-queue which might be from ebiederm(a)xmission.com are queue-4.14/net-sctp-always-set-scope_id-in-sctp_inet6_skb_msgname.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "net: cdc_ncm: GetNtbFormat endian fix" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: cdc_ncm: GetNtbFormat endian fix to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-cdc_ncm-getntbformat-endian-fix.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:02 CET 2017 From: Bjørn Mork <bjorn(a)mork.no> Date: Wed, 15 Nov 2017 09:35:02 +0100 Subject: net: cdc_ncm: GetNtbFormat endian fix From: Bjørn Mork <bjorn(a)mork.no> [ Upstream commit 6314dab4b8fb8493d810e175cb340376052c69b6 ] The GetNtbFormat and SetNtbFormat requests operate on 16 bit little endian values. We get away with ignoring this most of the time, because we only care about USB_CDC_NCM_NTB16_FORMAT which is 0x0000. This fails for USB_CDC_NCM_NTB32_FORMAT. Fix comparison between LE value from device and constant by converting the constant to LE. Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk> Fixes: 2b02c20ce0c2 ("cdc_ncm: Set NTB format again after altsetting switch for Huawei devices") Cc: Enrico Mioso <mrkiko.rs(a)gmail.com> Cc: Christian Panton <christian(a)panton.org> Signed-off-by: BjÃ¸rn Mork <bjorn(a)mork.no> Acked-By: Enrico Mioso <mrkiko.rs(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/cdc_ncm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/net/usb/cdc_ncm.c +++ b/drivers/net/usb/cdc_ncm.c @@ -771,7 +771,7 @@ int cdc_ncm_bind_common(struct usbnet *d int err; u8 iface_no; struct usb_cdc_parsed_header hdr; - u16 curr_ntb_format; + __le16 curr_ntb_format; ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); if (!ctx) @@ -889,7 +889,7 @@ int cdc_ncm_bind_common(struct usbnet *d goto error2; } - if (curr_ntb_format == USB_CDC_NCM_NTB32_FORMAT) { + if (curr_ntb_format == cpu_to_le16(USB_CDC_NCM_NTB32_FORMAT)) { dev_info(&intf->dev, "resetting NTB format to 16-bit"); err = usbnet_write_cmd(dev, USB_CDC_SET_NTB_FORMAT, USB_TYPE_CLASS | USB_DIR_OUT Patches currently in stable-queue which might be from bjorn(a)mork.no are queue-4.14/net-cdc_ncm-getntbformat-endian-fix.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "fealnx: Fix building error on MIPS" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fealnx: Fix building error on MIPS to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fealnx-fix-building-error-on-mips.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:02 CET 2017 From: Huacai Chen <chenhc(a)lemote.com> Date: Thu, 16 Nov 2017 11:07:15 +0800 Subject: fealnx: Fix building error on MIPS From: Huacai Chen <chenhc(a)lemote.com> [ Upstream commit cc54c1d32e6a4bb3f116721abf900513173e4d02 ] This patch try to fix the building error on MIPS. The reason is MIPS has already defined the LONG macro, which conflicts with the LONG enum in drivers/net/ethernet/fealnx.c. Signed-off-by: Huacai Chen <chenhc(a)lemote.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/fealnx.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/fealnx.c +++ b/drivers/net/ethernet/fealnx.c @@ -257,8 +257,8 @@ enum rx_desc_status_bits { RXFSD = 0x00000800, /* first descriptor */ RXLSD = 0x00000400, /* last descriptor */ ErrorSummary = 0x80, /* error summary */ - RUNT = 0x40, /* runt packet received */ - LONG = 0x20, /* long packet received */ + RUNTPKT = 0x40, /* runt packet received */ + LONGPKT = 0x20, /* long packet received */ FAE = 0x10, /* frame align error */ CRC = 0x08, /* crc error */ RXER = 0x04, /* receive error */ @@ -1632,7 +1632,7 @@ static int netdev_rx(struct net_device * dev->name, rx_status); dev->stats.rx_errors++; /* end of a packet. */ - if (rx_status & (LONG | RUNT)) + if (rx_status & (LONGPKT | RUNTPKT)) dev->stats.rx_length_errors++; if (rx_status & RXER) dev->stats.rx_frame_errors++; Patches currently in stable-queue which might be from chenhc(a)lemote.com are queue-4.14/fealnx-fix-building-error-on-mips.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "bio: ensure __bio_clone_fast copies bi_partno" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bio: ensure __bio_clone_fast copies bi_partno to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bio-ensure-__bio_clone_fast-copies-bi_partno.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 62530ed8b1d07a45dec94d46e521c0c6c2d476e6 Mon Sep 17 00:00:00 2001 From: Michael Lyle <mlyle(a)lyle.org> Date: Thu, 16 Nov 2017 23:47:25 -0800 Subject: bio: ensure __bio_clone_fast copies bi_partno From: Michael Lyle <mlyle(a)lyle.org> commit 62530ed8b1d07a45dec94d46e521c0c6c2d476e6 upstream. A new field was introduced in 74d46992e0d9, bi_partno, instead of using bdev->bd_contains and encoding the partition information in the bi_bdev field. __bio_clone_fast was changed to copy the disk information, but not the partition information. At minimum, this regressed bcache and caused data corruption. Signed-off-by: Michael Lyle <mlyle(a)lyle.org> Fixes: 74d46992e0d9 ("block: replace bi_bdev with a gendisk pointer and partitions index") Reported-by: Pavel Goran <via-bcache(a)pvgoran.name> Reported-by: Campbell Steven <casteven(a)gmail.com> Reviewed-by: Coly Li <colyli(a)suse.de> Reviewed-by: Ming Lei <ming.lei(a)redhat.com> Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- block/bio.c | 1 + 1 file changed, 1 insertion(+) --- a/block/bio.c +++ b/block/bio.c @@ -597,6 +597,7 @@ void __bio_clone_fast(struct bio *bio, s * so we don't set nor calculate new physical/hw segment counts here */ bio->bi_disk = bio_src->bi_disk; + bio->bi_partno = bio_src->bi_partno; bio_set_flag(bio, BIO_CLONED); bio->bi_opf = bio_src->bi_opf; bio->bi_write_hint = bio_src->bi_write_hint; Patches currently in stable-queue which might be from mlyle(a)lyle.org are queue-4.14/bio-ensure-__bio_clone_fast-copies-bi_partno.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "af_netlink: ensure that NLMSG_DONE never fails in dumps" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled af_netlink: ensure that NLMSG_DONE never fails in dumps to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: af_netlink-ensure-that-nlmsg_done-never-fails-in-dumps.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:02 CET 2017 From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> Date: Thu, 9 Nov 2017 13:04:44 +0900 Subject: af_netlink: ensure that NLMSG_DONE never fails in dumps From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> [ Upstream commit 0642840b8bb008528dbdf929cec9f65ac4231ad0 ] The way people generally use netlink_dump is that they fill in the skb as much as possible, breaking when nla_put returns an error. Then, they get called again and start filling out the next skb, and again, and so forth. The mechanism at work here is the ability for the iterative dumping function to detect when the skb is filled up and not fill it past the brim, waiting for a fresh skb for the rest of the data. However, if the attributes are small and nicely packed, it is possible that a dump callback function successfully fills in attributes until the skb is of size 4080 (libmnl's default page-sized receive buffer size). The dump function completes, satisfied, and then, if it happens to be that this is actually the last skb, and no further ones are to be sent, then netlink_dump will add on the NLMSG_DONE part: nlh = nlmsg_put_answer(skb, cb, NLMSG_DONE, sizeof(len), NLM_F_MULTI); It is very important that netlink_dump does this, of course. However, in this example, that call to nlmsg_put_answer will fail, because the previous filling by the dump function did not leave it enough room. And how could it possibly have done so? All of the nla_put variety of functions simply check to see if the skb has enough tailroom, independent of the context it is in. In order to keep the important assumptions of all netlink dump users, it is therefore important to give them an skb that has this end part of the tail already reserved, so that the call to nlmsg_put_answer does not fail. Otherwise, library authors are forced to find some bizarre sized receive buffer that has a large modulo relative to the common sizes of messages received, which is ugly and buggy. This patch thus saves the NLMSG_DONE for an additional message, for the case that things are dangerously close to the brim. This requires keeping track of the errno from ->dump() across calls. Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netlink/af_netlink.c | 17 +++++++++++------ net/netlink/af_netlink.h | 1 + 2 files changed, 12 insertions(+), 6 deletions(-) --- a/net/netlink/af_netlink.c +++ b/net/netlink/af_netlink.c @@ -2136,7 +2136,7 @@ static int netlink_dump(struct sock *sk) struct sk_buff *skb = NULL; struct nlmsghdr *nlh; struct module *module; - int len, err = -ENOBUFS; + int err = -ENOBUFS; int alloc_min_size; int alloc_size; @@ -2183,9 +2183,11 @@ static int netlink_dump(struct sock *sk) skb_reserve(skb, skb_tailroom(skb) - alloc_size); netlink_skb_set_owner_r(skb, sk); - len = cb->dump(skb, cb); + if (nlk->dump_done_errno > 0) + nlk->dump_done_errno = cb->dump(skb, cb); - if (len > 0) { + if (nlk->dump_done_errno > 0 || + skb_tailroom(skb) < nlmsg_total_size(sizeof(nlk->dump_done_errno))) { mutex_unlock(nlk->cb_mutex); if (sk_filter(sk, skb)) @@ -2195,13 +2197,15 @@ static int netlink_dump(struct sock *sk) return 0; } - nlh = nlmsg_put_answer(skb, cb, NLMSG_DONE, sizeof(len), NLM_F_MULTI); - if (!nlh) + nlh = nlmsg_put_answer(skb, cb, NLMSG_DONE, + sizeof(nlk->dump_done_errno), NLM_F_MULTI); + if (WARN_ON(!nlh)) goto errout_skb; nl_dump_check_consistent(cb, nlh); - memcpy(nlmsg_data(nlh), &len, sizeof(len)); + memcpy(nlmsg_data(nlh), &nlk->dump_done_errno, + sizeof(nlk->dump_done_errno)); if (sk_filter(sk, skb)) kfree_skb(skb); @@ -2273,6 +2277,7 @@ int __netlink_dump_start(struct sock *ss } nlk->cb_running = true; + nlk->dump_done_errno = INT_MAX; mutex_unlock(nlk->cb_mutex); --- a/net/netlink/af_netlink.h +++ b/net/netlink/af_netlink.h @@ -34,6 +34,7 @@ struct netlink_sock { wait_queue_head_t wait; bool bound; bool cb_running; + int dump_done_errno; struct netlink_callback cb; struct mutex *cb_mutex; struct mutex cb_def_mutex; Patches currently in stable-queue which might be from Jason(a)zx2c4.com are queue-4.14/af_netlink-ensure-that-nlmsg_done-never-fails-in-dumps.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "vxlan: fix the issue that neigh proxy blocks all icmpv6 packets" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vxlan: fix the issue that neigh proxy blocks all icmpv6 packets to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vxlan-fix-the-issue-that-neigh-proxy-blocks-all-icmpv6-packets.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Xin Long <lucien.xin(a)gmail.com> Date: Sat, 11 Nov 2017 19:58:50 +0800 Subject: vxlan: fix the issue that neigh proxy blocks all icmpv6 packets From: Xin Long <lucien.xin(a)gmail.com> [ Upstream commit 8bff3685a4bbf175a96bc6a528f13455d8d38244 ] Commit f1fb08f6337c ("vxlan: fix ND proxy when skb doesn't have transport header offset") removed icmp6_code and icmp6_type check before calling neigh_reduce when doing neigh proxy. It means all icmpv6 packets would be blocked by this, not only ns packet. In Jianlin's env, even ping6 couldn't work through it. This patch is to bring the icmp6_code and icmp6_type check back and also removed the same check from neigh_reduce(). Fixes: f1fb08f6337c ("vxlan: fix ND proxy when skb doesn't have transport header offset") Reported-by: Jianlin Shi <jishi(a)redhat.com> Signed-off-by: Xin Long <lucien.xin(a)gmail.com> Reviewed-by: Vincent Bernat <vincent(a)bernat.im> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/vxlan.c | 31 +++++++++++++------------------ 1 file changed, 13 insertions(+), 18 deletions(-) --- a/drivers/net/vxlan.c +++ b/drivers/net/vxlan.c @@ -1632,26 +1632,19 @@ static struct sk_buff *vxlan_na_create(s static int neigh_reduce(struct net_device *dev, struct sk_buff *skb, __be32 vni) { struct vxlan_dev *vxlan = netdev_priv(dev); - struct nd_msg *msg; - const struct ipv6hdr *iphdr; const struct in6_addr *daddr; - struct neighbour *n; + const struct ipv6hdr *iphdr; struct inet6_dev *in6_dev; + struct neighbour *n; + struct nd_msg *msg; in6_dev = __in6_dev_get(dev); if (!in6_dev) goto out; - if (!pskb_may_pull(skb, sizeof(struct ipv6hdr) + sizeof(struct nd_msg))) - goto out; - iphdr = ipv6_hdr(skb); daddr = &iphdr->daddr; - msg = (struct nd_msg *)(iphdr + 1); - if (msg->icmph.icmp6_code != 0 || - msg->icmph.icmp6_type != NDISC_NEIGHBOUR_SOLICITATION) - goto out; if (ipv6_addr_loopback(daddr) || ipv6_addr_is_multicast(&msg->target)) @@ -2258,11 +2251,11 @@ tx_error: static netdev_tx_t vxlan_xmit(struct sk_buff *skb, struct net_device *dev) { struct vxlan_dev *vxlan = netdev_priv(dev); + struct vxlan_rdst *rdst, *fdst = NULL; const struct ip_tunnel_info *info; - struct ethhdr *eth; bool did_rsc = false; - struct vxlan_rdst *rdst, *fdst = NULL; struct vxlan_fdb *f; + struct ethhdr *eth; __be32 vni = 0; info = skb_tunnel_info(skb); @@ -2287,12 +2280,14 @@ static netdev_tx_t vxlan_xmit(struct sk_ if (ntohs(eth->h_proto) == ETH_P_ARP) return arp_reduce(dev, skb, vni); #if IS_ENABLED(CONFIG_IPV6) - else if (ntohs(eth->h_proto) == ETH_P_IPV6) { - struct ipv6hdr *hdr, _hdr; - if ((hdr = skb_header_pointer(skb, - skb_network_offset(skb), - sizeof(_hdr), &_hdr)) && - hdr->nexthdr == IPPROTO_ICMPV6) + else if (ntohs(eth->h_proto) == ETH_P_IPV6 && + pskb_may_pull(skb, sizeof(struct ipv6hdr) + + sizeof(struct nd_msg)) && + ipv6_hdr(skb)->nexthdr == IPPROTO_ICMPV6) { + struct nd_msg *m = (struct nd_msg *)(ipv6_hdr(skb) + 1); + + if (m->icmph.icmp6_code == 0 && + m->icmph.icmp6_type == NDISC_NEIGHBOUR_SOLICITATION) return neigh_reduce(dev, skb, vni); } #endif Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are queue-4.13/sctp-do-not-peel-off-an-assoc-from-one-netns-to-another-one.patch queue-4.13/vxlan-fix-the-issue-that-neigh-proxy-blocks-all-icmpv6-packets.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "vlan: fix a use-after-free in vlan_device_event()" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled vlan: fix a use-after-free in vlan_device_event() to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: vlan-fix-a-use-after-free-in-vlan_device_event.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Cong Wang <xiyou.wangcong(a)gmail.com> Date: Thu, 9 Nov 2017 16:43:13 -0800 Subject: vlan: fix a use-after-free in vlan_device_event() From: Cong Wang <xiyou.wangcong(a)gmail.com> [ Upstream commit 052d41c01b3a2e3371d66de569717353af489d63 ] After refcnt reaches zero, vlan_vid_del() could free dev->vlan_info via RCU: RCU_INIT_POINTER(dev->vlan_info, NULL); call_rcu(&vlan_info->rcu, vlan_info_rcu_free); However, the pointer 'grp' still points to that memory since it is set before vlan_vid_del(): vlan_info = rtnl_dereference(dev->vlan_info); if (!vlan_info) goto out; grp = &vlan_info->grp; Depends on when that RCU callback is scheduled, we could trigger a use-after-free in vlan_group_for_each_dev() right following this vlan_vid_del(). Fix it by moving vlan_vid_del() before setting grp. This is also symmetric to the vlan_vid_add() we call in vlan_device_event(). Reported-by: Fengguang Wu <fengguang.wu(a)intel.com> Fixes: efc73f4bbc23 ("net: Fix memory leak - vlan_info struct") Cc: Alexander Duyck <alexander.duyck(a)gmail.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Girish Moodalbail <girish.moodalbail(a)oracle.com> Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> Reviewed-by: Girish Moodalbail <girish.moodalbail(a)oracle.com> Tested-by: Fengguang Wu <fengguang.wu(a)intel.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/8021q/vlan.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/net/8021q/vlan.c +++ b/net/8021q/vlan.c @@ -376,6 +376,9 @@ static int vlan_device_event(struct noti dev->name); vlan_vid_add(dev, htons(ETH_P_8021Q), 0); } + if (event == NETDEV_DOWN && + (dev->features & NETIF_F_HW_VLAN_CTAG_FILTER)) + vlan_vid_del(dev, htons(ETH_P_8021Q), 0); vlan_info = rtnl_dereference(dev->vlan_info); if (!vlan_info) @@ -423,9 +426,6 @@ static int vlan_device_event(struct noti struct net_device *tmp; LIST_HEAD(close_list); - if (dev->features & NETIF_F_HW_VLAN_CTAG_FILTER) - vlan_vid_del(dev, htons(ETH_P_8021Q), 0); - /* Put all VLANs for this dev in the down state too. */ vlan_group_for_each_dev(grp, i, vlandev) { flgs = vlandev->flags; Patches currently in stable-queue which might be from xiyou.wangcong(a)gmail.com are queue-4.13/vlan-fix-a-use-after-free-in-vlan_device_event.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "tcp_nv: fix division by zero in tcpnv_acked()" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tcp_nv: fix division by zero in tcpnv_acked() to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tcp_nv-fix-division-by-zero-in-tcpnv_acked.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru> Date: Wed, 1 Nov 2017 16:32:15 +0300 Subject: tcp_nv: fix division by zero in tcpnv_acked() From: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru> [ Upstream commit 4eebff27ca4182bbf5f039dd60d79e2d7c0a707e ] Average RTT could become zero. This happened in real life at least twice. This patch treats zero as 1us. Signed-off-by: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru> Acked-by: Lawrence Brakmo <Brakmo(a)fb.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv4/tcp_nv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/net/ipv4/tcp_nv.c +++ b/net/ipv4/tcp_nv.c @@ -263,7 +263,7 @@ static void tcpnv_acked(struct sock *sk, /* rate in 100's bits per second */ rate64 = ((u64)sample->in_flight) * 8000000; - rate = (u32)div64_u64(rate64, (u64)(avg_rtt * 100)); + rate = (u32)div64_u64(rate64, (u64)(avg_rtt ?: 1) * 100); /* Remember the maximum rate seen during this RTT * Note: It may be more than one RTT. This function should be Patches currently in stable-queue which might be from khlebnikov(a)yandex-team.ru are queue-4.13/tcp_nv-fix-division-by-zero-in-tcpnv_acked.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "tcp: gso: avoid refcount_t warning from tcp_gso_segment()" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tcp: gso: avoid refcount_t warning from tcp_gso_segment() to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tcp-gso-avoid-refcount_t-warning-from-tcp_gso_segment.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Eric Dumazet <edumazet(a)google.com> Date: Tue, 7 Nov 2017 15:15:04 -0800 Subject: tcp: gso: avoid refcount_t warning from tcp_gso_segment() From: Eric Dumazet <edumazet(a)google.com> [ Upstream commit 7ec318feeed10a64c0359ec4d10889cb4defa39a ] When a GSO skb of truesize O is segmented into 2 new skbs of truesize N1 and N2, we want to transfer socket ownership to the new fresh skbs. In order to avoid expensive atomic operations on a cache line subject to cache bouncing, we replace the sequence : refcount_add(N1, &sk->sk_wmem_alloc); refcount_add(N2, &sk->sk_wmem_alloc); // repeated by number of segments refcount_sub(O, &sk->sk_wmem_alloc); by a single refcount_add(sum_of(N) - O, &sk->sk_wmem_alloc); Problem is : In some pathological cases, sum(N) - O might be a negative number, and syzkaller bot was apparently able to trigger this trace [1] atomic_t was ok with this construct, but we need to take care of the negative delta with refcount_t [1] refcount_t: saturated; leaking memory. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 8404 at lib/refcount.c:77 refcount_add_not_zero+0x198/0x200 lib/refcount.c:77 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 8404 Comm: syz-executor2 Not tainted 4.14.0-rc5-mm1+ #20 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0x194/0x257 lib/dump_stack.c:52 panic+0x1e4/0x41c kernel/panic.c:183 __warn+0x1c4/0x1e0 kernel/panic.c:546 report_bug+0x211/0x2d0 lib/bug.c:183 fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:177 do_trap_no_signal arch/x86/kernel/traps.c:211 [inline] do_trap+0x260/0x390 arch/x86/kernel/traps.c:260 do_error_trap+0x120/0x390 arch/x86/kernel/traps.c:297 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:310 invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:905 RIP: 0010:refcount_add_not_zero+0x198/0x200 lib/refcount.c:77 RSP: 0018:ffff8801c606e3a0 EFLAGS: 00010282 RAX: 0000000000000026 RBX: 0000000000001401 RCX: 0000000000000000 RDX: 0000000000000026 RSI: ffffc900036fc000 RDI: ffffed0038c0dc68 RBP: ffff8801c606e430 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8801d97f5eba R11: 0000000000000000 R12: ffff8801d5acf73c R13: 1ffff10038c0dc75 R14: 00000000ffffffff R15: 00000000fffff72f refcount_add+0x1b/0x60 lib/refcount.c:101 tcp_gso_segment+0x10d0/0x16b0 net/ipv4/tcp_offload.c:155 tcp4_gso_segment+0xd4/0x310 net/ipv4/tcp_offload.c:51 inet_gso_segment+0x60c/0x11c0 net/ipv4/af_inet.c:1271 skb_mac_gso_segment+0x33f/0x660 net/core/dev.c:2749 __skb_gso_segment+0x35f/0x7f0 net/core/dev.c:2821 skb_gso_segment include/linux/netdevice.h:3971 [inline] validate_xmit_skb+0x4ba/0xb20 net/core/dev.c:3074 __dev_queue_xmit+0xe49/0x2070 net/core/dev.c:3497 dev_queue_xmit+0x17/0x20 net/core/dev.c:3538 neigh_hh_output include/net/neighbour.h:471 [inline] neigh_output include/net/neighbour.h:479 [inline] ip_finish_output2+0xece/0x1460 net/ipv4/ip_output.c:229 ip_finish_output+0x85e/0xd10 net/ipv4/ip_output.c:317 NF_HOOK_COND include/linux/netfilter.h:238 [inline] ip_output+0x1cc/0x860 net/ipv4/ip_output.c:405 dst_output include/net/dst.h:459 [inline] ip_local_out+0x95/0x160 net/ipv4/ip_output.c:124 ip_queue_xmit+0x8c6/0x18e0 net/ipv4/ip_output.c:504 tcp_transmit_skb+0x1ab7/0x3840 net/ipv4/tcp_output.c:1137 tcp_write_xmit+0x663/0x4de0 net/ipv4/tcp_output.c:2341 __tcp_push_pending_frames+0xa0/0x250 net/ipv4/tcp_output.c:2513 tcp_push_pending_frames include/net/tcp.h:1722 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5050 [inline] tcp_rcv_established+0x8c7/0x18a0 net/ipv4/tcp_input.c:5497 tcp_v4_do_rcv+0x2ab/0x7d0 net/ipv4/tcp_ipv4.c:1460 sk_backlog_rcv include/net/sock.h:909 [inline] __release_sock+0x124/0x360 net/core/sock.c:2264 release_sock+0xa4/0x2a0 net/core/sock.c:2776 tcp_sendmsg+0x3a/0x50 net/ipv4/tcp.c:1462 inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:763 sock_sendmsg_nosec net/socket.c:632 [inline] sock_sendmsg+0xca/0x110 net/socket.c:642 ___sys_sendmsg+0x31c/0x890 net/socket.c:2048 __sys_sendmmsg+0x1e6/0x5f0 net/socket.c:2138 Fixes: 14afee4b6092 ("net: convert sock.sk_wmem_alloc from atomic_t to refcount_t") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv4/tcp_offload.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) --- a/net/ipv4/tcp_offload.c +++ b/net/ipv4/tcp_offload.c @@ -149,11 +149,19 @@ struct sk_buff *tcp_gso_segment(struct s * is freed by GSO engine */ if (copy_destructor) { + int delta; + swap(gso_skb->sk, skb->sk); swap(gso_skb->destructor, skb->destructor); sum_truesize += skb->truesize; - refcount_add(sum_truesize - gso_skb->truesize, - &skb->sk->sk_wmem_alloc); + delta = sum_truesize - gso_skb->truesize; + /* In some pathological cases, delta can be negative. + * We need to either use refcount_add() or refcount_sub_and_test() + */ + if (likely(delta >= 0)) + refcount_add(delta, &skb->sk->sk_wmem_alloc); + else + WARN_ON_ONCE(refcount_sub_and_test(-delta, &skb->sk->sk_wmem_alloc)); } delta = htonl(oldlen + (skb_tail_pointer(skb) - Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.13/tcp-fix-tcp_fastretrans_alert-warning.patch queue-4.13/tcp-do-not-mangle-skb-cb-in-tcp_make_synack.patch queue-4.13/tcp-gso-avoid-refcount_t-warning-from-tcp_gso_segment.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "tcp: fix tcp_fastretrans_alert warning" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tcp: fix tcp_fastretrans_alert warning to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tcp-fix-tcp_fastretrans_alert-warning.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Yuchung Cheng <ycheng(a)google.com> Date: Tue, 7 Nov 2017 15:33:43 -0800 Subject: tcp: fix tcp_fastretrans_alert warning From: Yuchung Cheng <ycheng(a)google.com> [ Upstream commit 0eb96bf754d7fa6635aa0b0f6650c74b8a6b1cc9 ] This patch fixes the cause of an WARNING indicatng TCP has pending retransmission in Open state in tcp_fastretrans_alert(). The root cause is a bad interaction between path mtu probing, if enabled, and the RACK loss detection. Upong receiving a SACK above the sequence of the MTU probing packet, RACK could mark the probe packet lost in tcp_fastretrans_alert(), prior to calling tcp_simple_retransmit(). tcp_simple_retransmit() only enters Loss state if it newly marks the probe packet lost. If the probe packet is already identified as lost by RACK, the sender remains in Open state with some packets marked lost and retransmitted. Then the next SACK would trigger the warning. The likely scenario is that the probe packet was lost due to its size or network congestion. The actual impact of this warning is small by potentially entering fast recovery an ACK later. The simple fix is always entering recovery (Loss) state if some packet is marked lost during path MTU probing. Fixes: a0370b3f3f2c ("tcp: enable RACK loss detection to trigger recovery") Reported-by: Oleksandr Natalenko <oleksandr(a)natalenko.name> Reported-by: Alexei Starovoitov <alexei.starovoitov(a)gmail.com> Reported-by: Roman Gushchin <guro(a)fb.com> Signed-off-by: Yuchung Cheng <ycheng(a)google.com> Reviewed-by: Eric Dumazet <edumazet(a)google.com> Acked-by: Neal Cardwell <ncardwell(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv4/tcp_input.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -2613,7 +2613,6 @@ void tcp_simple_retransmit(struct sock * struct tcp_sock *tp = tcp_sk(sk); struct sk_buff *skb; unsigned int mss = tcp_current_mss(sk); - u32 prior_lost = tp->lost_out; tcp_for_write_queue(skb, sk) { if (skb == tcp_send_head(sk)) @@ -2630,7 +2629,7 @@ void tcp_simple_retransmit(struct sock * tcp_clear_retrans_hints_partial(tp); - if (prior_lost == tp->lost_out) + if (!tp->lost_out) return; if (tcp_is_reno(tp)) Patches currently in stable-queue which might be from ycheng(a)google.com are queue-4.13/tcp-fix-tcp_fastretrans_alert-warning.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "tcp: do not mangle skb->cb[] in tcp_make_synack()" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled tcp: do not mangle skb->cb[] in tcp_make_synack() to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: tcp-do-not-mangle-skb-cb-in-tcp_make_synack.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Eric Dumazet <edumazet(a)google.com> Date: Thu, 2 Nov 2017 12:30:25 -0700 Subject: tcp: do not mangle skb->cb[] in tcp_make_synack() From: Eric Dumazet <edumazet(a)google.com> [ Upstream commit 3b11775033dc87c3d161996c54507b15ba26414a ] Christoph Paasch sent a patch to address the following issue : tcp_make_synack() is leaving some TCP private info in skb->cb[], then send the packet by other means than tcp_transmit_skb() tcp_transmit_skb() makes sure to clear skb->cb[] to not confuse IPv4/IPV6 stacks, but we have no such cleanup for SYNACK. tcp_make_synack() should not use tcp_init_nondata_skb() : tcp_init_nondata_skb() really should be limited to skbs put in write/rtx queues (the ones that are only sent via tcp_transmit_skb()) This patch fixes the issue and should even save few cpu cycles ;) Fixes: 971f10eca186 ("tcp: better TCP_SKB_CB layout to reduce cache line misses") Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reported-by: Christoph Paasch <cpaasch(a)apple.com> Reviewed-by: Christoph Paasch <cpaasch(a)apple.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv4/tcp_output.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) --- a/net/ipv4/tcp_output.c +++ b/net/ipv4/tcp_output.c @@ -3207,13 +3207,8 @@ struct sk_buff *tcp_make_synack(const st th->source = htons(ireq->ir_num); th->dest = ireq->ir_rmt_port; skb->mark = ireq->ir_mark; - /* Setting of flags are superfluous here for callers (and ECE is - * not even correctly set) - */ - tcp_init_nondata_skb(skb, tcp_rsk(req)->snt_isn, - TCPHDR_SYN | TCPHDR_ACK); - - th->seq = htonl(TCP_SKB_CB(skb)->seq); + skb->ip_summed = CHECKSUM_PARTIAL; + th->seq = htonl(tcp_rsk(req)->snt_isn); /* XXX data is queued and acked as is. No buffer/window check */ th->ack_seq = htonl(tcp_rsk(req)->rcv_nxt); Patches currently in stable-queue which might be from edumazet(a)google.com are queue-4.13/tcp-fix-tcp_fastretrans_alert-warning.patch queue-4.13/tcp-do-not-mangle-skb-cb-in-tcp_make_synack.patch queue-4.13/tcp-gso-avoid-refcount_t-warning-from-tcp_gso_segment.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "sctp: do not peel off an assoc from one netns to another one" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sctp: do not peel off an assoc from one netns to another one to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sctp-do-not-peel-off-an-assoc-from-one-netns-to-another-one.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Xin Long <lucien.xin(a)gmail.com> Date: Tue, 17 Oct 2017 23:26:10 +0800 Subject: sctp: do not peel off an assoc from one netns to another one From: Xin Long <lucien.xin(a)gmail.com> [ Upstream commit df80cd9b28b9ebaa284a41df611dbf3a2d05ca74 ] 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: socket$inet6_sctp() bind$inet6() sendto$inet6() unshare(0x40000000) getsockopt$inet_sctp6_SCTP_GET_ASSOC_ID_LIST() getsockopt$inet_sctp6_SCTP_SOCKOPT_PEELOFF() 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 <chunwang(a)redhat.com> Signed-off-by: Xin Long <lucien.xin(a)gmail.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner(a)gmail.com> Acked-by: Neil Horman <nhorman(a)tuxdriver.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sctp/socket.c | 4 ++++ 1 file changed, 4 insertions(+) --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -4924,6 +4924,10 @@ int sctp_do_peeloff(struct sock *sk, sct struct socket *sock; int err = 0; + /* Do not peel off from one netns to another one. */ + if (!net_eq(current->nsproxy->net_ns, sock_net(sk))) + return -EINVAL; + if (!asoc) return -EINVAL; Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are queue-4.13/sctp-do-not-peel-off-an-assoc-from-one-netns-to-another-one.patch queue-4.13/vxlan-fix-the-issue-that-neigh-proxy-blocks-all-icmpv6-packets.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "qmi_wwan: Add missing skb_reset_mac_header-call" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled qmi_wwan: Add missing skb_reset_mac_header-call to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: qmi_wwan-add-missing-skb_reset_mac_header-call.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Kristian Evensen <kristian.evensen(a)gmail.com> Date: Tue, 7 Nov 2017 13:47:56 +0100 Subject: qmi_wwan: Add missing skb_reset_mac_header-call From: Kristian Evensen <kristian.evensen(a)gmail.com> [ Upstream commit 0de0add10e587effa880c741c9413c874f16be91 ] When we receive a packet on a QMI device in raw IP mode, we should call skb_reset_mac_header() to ensure that skb->mac_header contains a valid offset in the packet. While it shouldn't really matter, the packets have no MAC header and the interface is configured as-such, it seems certain parts of the network stack expects a "good" value in skb->mac_header. Without the skb_reset_mac_header() call added in this patch, for example shaping traffic (using tc) triggers the following oops on the first received packet: [ 303.642957] skbuff: skb_under_panic: text:8f137918 len:177 put:67 head:8e4b0f00 data:8e4b0eff tail:0x8e4b0fb0 end:0x8e4b1520 dev:wwan0 [ 303.655045] Kernel bug detected[#1]: [ 303.658622] CPU: 1 PID: 1002 Comm: logd Not tainted 4.9.58 #0 [ 303.664339] task: 8fdf05e0 task.stack: 8f15c000 [ 303.668844] $ 0 : 00000000 00000001 0000007a 00000000 [ 303.674062] $ 4 : 8149a2fc 8149a2fc 8149ce20 00000000 [ 303.679284] $ 8 : 00000030 3878303a 31623465 20303235 [ 303.684510] $12 : ded731e3 2626a277 00000000 03bd0000 [ 303.689747] $16 : 8ef62b40 00000043 8f137918 804db5fc [ 303.694978] $20 : 00000001 00000004 8fc13800 00000003 [ 303.700215] $24 : 00000001 8024ab10 [ 303.705442] $28 : 8f15c000 8fc19cf0 00000043 802cc920 [ 303.710664] Hi : 00000000 [ 303.713533] Lo : 74e58000 [ 303.716436] epc : 802cc920 skb_panic+0x58/0x5c [ 303.721046] ra : 802cc920 skb_panic+0x58/0x5c [ 303.725639] Status: 11007c03 KERNEL EXL IE [ 303.729823] Cause : 50800024 (ExcCode 09) [ 303.733817] PrId : 0001992f (MIPS 1004Kc) [ 303.737892] Modules linked in: rt2800pci rt2800mmio rt2800lib qcserial ppp_async option usb_wwan rt2x00pci rt2x00mmio rt2x00lib rndis_host qmi_wwan ppp_generic nf_nat_pptp nf_conntrack_pptp nf_conntrack_ipv6 mt76x2i Process logd (pid: 1002, threadinfo=8f15c000, task=8fdf05e0, tls=77b3eee4) [ 303.962509] Stack : 00000000 80408990 8f137918 000000b1 00000043 8e4b0f00 8e4b0eff 8e4b0fb0 [ 303.970871] 8e4b1520 8fec1800 00000043 802cd2a4 6e000045 00000043 00000000 8ef62000 [ 303.979219] 8eef5d00 8ef62b40 8fea7300 8f137918 00000000 00000000 0002bb01 793e5664 [ 303.987568] 8ef08884 00000001 8fea7300 00000002 8fc19e80 8eef5d00 00000006 00000003 [ 303.995934] 00000000 8030ba90 00000003 77ab3fd0 8149dc80 8004d1bc 8f15c000 8f383700 [ 304.004324] ... [ 304.006767] Call Trace: [ 304.009241] [<802cc920>] skb_panic+0x58/0x5c [ 304.013504] [<802cd2a4>] skb_push+0x78/0x90 [ 304.017783] [<8f137918>] 0x8f137918 [ 304.021269] Code: 00602825 0c02a3b4 24842888 <000c000d> 8c870060 8c8200a0 0007382b 00070336 8c88005c [ 304.031034] [ 304.032805] ---[ end trace b778c482b3f0bda9 ]--- [ 304.041384] Kernel panic - not syncing: Fatal exception in interrupt [ 304.051975] Rebooting in 3 seconds.. While the oops is for a 4.9-kernel, I was able to trigger the same oops with net-next as of yesterday. Fixes: 32f7adf633b9 ("net: qmi_wwan: support "raw IP" mode") Signed-off-by: Kristian Evensen <kristian.evensen(a)gmail.com> Acked-by: Bjørn Mork <bjorn(a)mork.no> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/qmi_wwan.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -499,6 +499,7 @@ static int qmi_wwan_rx_fixup(struct usbn return 1; } if (rawip) { + skb_reset_mac_header(skb); skb->dev = dev->net; /* normally set by eth_type_trans */ skb->protocol = proto; return 1; Patches currently in stable-queue which might be from kristian.evensen(a)gmail.com are queue-4.13/qmi_wwan-add-missing-skb_reset_mac_header-call.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "netfilter/ipvs: clear ipvs_property flag when SKB net namespace changed" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter/ipvs: clear ipvs_property flag when SKB net namespace changed to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: netfilter-ipvs-clear-ipvs_property-flag-when-skb-net-namespace-changed.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Ye Yin <hustcat(a)gmail.com> Date: Thu, 26 Oct 2017 16:57:05 +0800 Subject: netfilter/ipvs: clear ipvs_property flag when SKB net namespace changed From: Ye Yin <hustcat(a)gmail.com> [ Upstream commit 2b5ec1a5f9738ee7bf8f5ec0526e75e00362c48f ] When run ipvs in two different network namespace at the same host, and one ipvs transport network traffic to the other network namespace ipvs. 'ipvs_property' flag will make the second ipvs take no effect. So we should clear 'ipvs_property' when SKB network namespace changed. Fixes: 621e84d6f373 ("dev: introduce skb_scrub_packet()") Signed-off-by: Ye Yin <hustcat(a)gmail.com> Signed-off-by: Wei Zhou <chouryzhou(a)gmail.com> Signed-off-by: Julian Anastasov <ja(a)ssi.bg> Signed-off-by: Simon Horman <horms(a)verge.net.au> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/skbuff.h | 7 +++++++ net/core/skbuff.c | 1 + 2 files changed, 8 insertions(+) --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -3655,6 +3655,13 @@ static inline void nf_reset_trace(struct #endif } +static inline void ipvs_reset(struct sk_buff *skb) +{ +#if IS_ENABLED(CONFIG_IP_VS) + skb->ipvs_property = 0; +#endif +} + /* Note: This doesn't put any conntrack and bridge info in dst. */ static inline void __nf_copy(struct sk_buff *dst, const struct sk_buff *src, bool copy) --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -4476,6 +4476,7 @@ void skb_scrub_packet(struct sk_buff *sk if (!xnet) return; + ipvs_reset(skb); skb_orphan(skb); skb->mark = 0; } Patches currently in stable-queue which might be from hustcat(a)gmail.com are queue-4.13/netfilter-ipvs-clear-ipvs_property-flag-when-skb-net-namespace-changed.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "net: vrf: correct FRA_L3MDEV encode type" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: vrf: correct FRA_L3MDEV encode type to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-vrf-correct-fra_l3mdev-encode-type.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Jeff Barnhill <0xeffeff(a)gmail.com> Date: Wed, 1 Nov 2017 14:58:09 +0000 Subject: net: vrf: correct FRA_L3MDEV encode type From: Jeff Barnhill <0xeffeff(a)gmail.com> [ Upstream commit 18129a24983906eaf2a2d448ce4b83e27091ebe2 ] FRA_L3MDEV is defined as U8, but is being added as a U32 attribute. On big endian architecture, this results in the l3mdev entry not being added to the FIB rules. Fixes: 1aa6c4f6b8cd8 ("net: vrf: Add l3mdev rules on first device create") Signed-off-by: Jeff Barnhill <0xeffeff(a)gmail.com> Acked-by: David Ahern <dsahern(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/vrf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/vrf.c +++ b/drivers/net/vrf.c @@ -1271,7 +1271,7 @@ static int vrf_fib_rule(const struct net frh->family = family; frh->action = FR_ACT_TO_TBL; - if (nla_put_u32(skb, FRA_L3MDEV, 1)) + if (nla_put_u8(skb, FRA_L3MDEV, 1)) goto nla_put_failure; if (nla_put_u32(skb, FRA_PRIORITY, FIB_RULE_PREF)) Patches currently in stable-queue which might be from 0xeffeff(a)gmail.com are queue-4.13/net-vrf-correct-fra_l3mdev-encode-type.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "net: usb: asix: fill null-ptr-deref in asix_suspend" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: usb: asix: fill null-ptr-deref in asix_suspend to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-usb-asix-fill-null-ptr-deref-in-asix_suspend.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Andrey Konovalov <andreyknvl(a)google.com> Date: Mon, 6 Nov 2017 13:26:46 +0100 Subject: net: usb: asix: fill null-ptr-deref in asix_suspend From: Andrey Konovalov <andreyknvl(a)google.com> [ Upstream commit 8f5624629105589bcc23d0e51cc01bd8103d09a5 ] When asix_suspend() is called dev->driver_priv might not have been assigned a value, so we need to check that it's not NULL. Similar issue is present in asix_resume(), this patch fixes it as well. Found by syzkaller. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] PREEMPT SMP KASAN Modules linked in: CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc4-43422-geccacdd69a8c #400 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event task: ffff88006bb36300 task.stack: ffff88006bba8000 RIP: 0010:asix_suspend+0x76/0xc0 drivers/net/usb/asix_devices.c:629 RSP: 0018:ffff88006bbae718 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff880061ba3b80 RCX: 1ffff1000c34d644 RDX: 0000000000000001 RSI: 0000000000000402 RDI: 0000000000000008 RBP: ffff88006bbae738 R08: 1ffff1000d775cad R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800630a8b40 R13: 0000000000000000 R14: 0000000000000402 R15: ffff880061ba3b80 FS: 0000000000000000(0000) GS:ffff88006c600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff33cf89000 CR3: 0000000061c0a000 CR4: 00000000000006f0 Call Trace: usb_suspend_interface drivers/usb/core/driver.c:1209 usb_suspend_both+0x27f/0x7e0 drivers/usb/core/driver.c:1314 usb_runtime_suspend+0x41/0x120 drivers/usb/core/driver.c:1852 __rpm_callback+0x339/0xb60 drivers/base/power/runtime.c:334 rpm_callback+0x106/0x220 drivers/base/power/runtime.c:461 rpm_suspend+0x465/0x1980 drivers/base/power/runtime.c:596 __pm_runtime_suspend+0x11e/0x230 drivers/base/power/runtime.c:1009 pm_runtime_put_sync_autosuspend ./include/linux/pm_runtime.h:251 usb_new_device+0xa37/0x1020 drivers/usb/core/hub.c:2487 hub_port_connect drivers/usb/core/hub.c:4903 hub_port_connect_change drivers/usb/core/hub.c:5009 port_event drivers/usb/core/hub.c:5115 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119 worker_thread+0x221/0x1850 kernel/workqueue.c:2253 kthread+0x3a1/0x470 kernel/kthread.c:231 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431 Code: 8d 7c 24 20 48 89 fa 48 c1 ea 03 80 3c 02 00 75 5b 48 b8 00 00 00 00 00 fc ff df 4d 8b 6c 24 20 49 8d 7d 08 48 89 fa 48 c1 ea 03 <80> 3c 02 00 75 34 4d 8b 6d 08 4d 85 ed 74 0b e8 26 2b 51 fd 4c RIP: asix_suspend+0x76/0xc0 RSP: ffff88006bbae718 ---[ end trace dfc4f5649284342c ]--- Signed-off-by: Andrey Konovalov <andreyknvl(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/asix_devices.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/net/usb/asix_devices.c +++ b/drivers/net/usb/asix_devices.c @@ -626,7 +626,7 @@ static int asix_suspend(struct usb_inter struct usbnet *dev = usb_get_intfdata(intf); struct asix_common_private *priv = dev->driver_priv; - if (priv->suspend) + if (priv && priv->suspend) priv->suspend(dev); return usbnet_suspend(intf, message); @@ -678,7 +678,7 @@ static int asix_resume(struct usb_interf struct usbnet *dev = usb_get_intfdata(intf); struct asix_common_private *priv = dev->driver_priv; - if (priv->resume) + if (priv && priv->resume) priv->resume(dev); return usbnet_resume(intf); Patches currently in stable-queue which might be from andreyknvl(a)google.com are queue-4.13/net-qmi_wwan-fix-divide-by-0-on-bad-descriptors.patch queue-4.13/net-usb-asix-fill-null-ptr-deref-in-asix_suspend.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "net: systemport: Correct IPG length settings" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: systemport: Correct IPG length settings to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-systemport-correct-ipg-length-settings.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Florian Fainelli <f.fainelli(a)gmail.com> Date: Thu, 2 Nov 2017 16:08:40 -0700 Subject: net: systemport: Correct IPG length settings From: Florian Fainelli <f.fainelli(a)gmail.com> [ Upstream commit 93824c80bf47ebe087414b3a40ca0ff9aab7d1fb ] Due to a documentation mistake, the IPG length was set to 0x12 while it should have been 12 (decimal). This would affect short packet (64B typically) performance since the IPG was bigger than necessary. Fixes: 44a4524c54af ("net: systemport: Add support for SYSTEMPORT Lite") Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/broadcom/bcmsysport.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) --- a/drivers/net/ethernet/broadcom/bcmsysport.c +++ b/drivers/net/ethernet/broadcom/bcmsysport.c @@ -1743,15 +1743,17 @@ static inline void bcm_sysport_mask_all_ static inline void gib_set_pad_extension(struct bcm_sysport_priv *priv) { - u32 __maybe_unused reg; + u32 reg; - /* Include Broadcom tag in pad extension */ + reg = gib_readl(priv, GIB_CONTROL); + /* Include Broadcom tag in pad extension and fix up IPG_LENGTH */ if (netdev_uses_dsa(priv->netdev)) { - reg = gib_readl(priv, GIB_CONTROL); reg &= ~(GIB_PAD_EXTENSION_MASK << GIB_PAD_EXTENSION_SHIFT); reg |= ENET_BRCM_TAG_LEN << GIB_PAD_EXTENSION_SHIFT; - gib_writel(priv, reg, GIB_CONTROL); } + reg &= ~(GIB_IPG_LEN_MASK << GIB_IPG_LEN_SHIFT); + reg |= 12 << GIB_IPG_LEN_SHIFT; + gib_writel(priv, reg, GIB_CONTROL); } static int bcm_sysport_open(struct net_device *dev) Patches currently in stable-queue which might be from f.fainelli(a)gmail.com are queue-4.13/net-systemport-correct-ipg-length-settings.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "net/sctp: Always set scope_id in sctp_inet6_skb_msgname" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net/sctp: Always set scope_id in sctp_inet6_skb_msgname to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-sctp-always-set-scope_id-in-sctp_inet6_skb_msgname.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: "Eric W. Biederman" <ebiederm(a)xmission.com> Date: Wed, 15 Nov 2017 22:17:48 -0600 Subject: net/sctp: Always set scope_id in sctp_inet6_skb_msgname From: "Eric W. Biederman" <ebiederm(a)xmission.com> [ Upstream commit 7c8a61d9ee1df0fb4747879fa67a99614eb62fec ] Alexandar Potapenko while testing the kernel with KMSAN and syzkaller discovered that in some configurations sctp would leak 4 bytes of kernel stack. Working with his reproducer I discovered that those 4 bytes that are leaked is the scope id of an ipv6 address returned by recvmsg. With a little code inspection and a shrewd guess I discovered that sctp_inet6_skb_msgname only initializes the scope_id field for link local ipv6 addresses to the interface index the link local address pertains to instead of initializing the scope_id field for all ipv6 addresses. That is almost reasonable as scope_id's are meaniningful only for link local addresses. Set the scope_id in all other cases to 0 which is not a valid interface index to make it clear there is nothing useful in the scope_id field. There should be no danger of breaking userspace as the stack leak guaranteed that previously meaningless random data was being returned. Fixes: 372f525b495c ("SCTP: Resync with LKSCTP tree.") History-tree: https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git Reported-by: Alexander Potapenko <glider(a)google.com> Tested-by: Alexander Potapenko <glider(a)google.com> Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/sctp/ipv6.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/net/sctp/ipv6.c +++ b/net/sctp/ipv6.c @@ -807,9 +807,10 @@ static void sctp_inet6_skb_msgname(struc addr->v6.sin6_flowinfo = 0; addr->v6.sin6_port = sh->source; addr->v6.sin6_addr = ipv6_hdr(skb)->saddr; - if (ipv6_addr_type(&addr->v6.sin6_addr) & IPV6_ADDR_LINKLOCAL) { + if (ipv6_addr_type(&addr->v6.sin6_addr) & IPV6_ADDR_LINKLOCAL) addr->v6.sin6_scope_id = sctp_v6_skb_iif(skb); - } + else + addr->v6.sin6_scope_id = 0; } *addr_len = sctp_v6_addr_to_user(sctp_sk(skb->sk), addr); Patches currently in stable-queue which might be from ebiederm(a)xmission.com are queue-4.13/net-sctp-always-set-scope_id-in-sctp_inet6_skb_msgname.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "net: qmi_wwan: fix divide by 0 on bad descriptors" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: qmi_wwan: fix divide by 0 on bad descriptors to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-qmi_wwan-fix-divide-by-0-on-bad-descriptors.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Bjørn Mork <bjorn(a)mork.no> Date: Mon, 6 Nov 2017 15:32:18 +0100 Subject: net: qmi_wwan: fix divide by 0 on bad descriptors From: Bjørn Mork <bjorn(a)mork.no> [ Upstream commit 7fd078337201cf7468f53c3d9ef81ff78cb6df3b ] A CDC Ethernet functional descriptor with wMaxSegmentSize = 0 will cause a divide error in usbnet_probe: divide error: 0000 [#1] PREEMPT SMP KASAN Modules linked in: CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc8-44453-g1fdc1a82c34f #56 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Workqueue: usb_hub_wq hub_event task: ffff88006bef5c00 task.stack: ffff88006bf60000 RIP: 0010:usbnet_update_max_qlen+0x24d/0x390 drivers/net/usb/usbnet.c:355 RSP: 0018:ffff88006bf67508 EFLAGS: 00010246 RAX: 00000000000163c8 RBX: ffff8800621fce40 RCX: ffff8800621fcf34 RDX: 0000000000000000 RSI: ffffffff837ecb7a RDI: ffff8800621fcf34 RBP: ffff88006bf67520 R08: ffff88006bef5c00 R09: ffffed000c43f881 R10: ffffed000c43f880 R11: ffff8800621fc406 R12: 0000000000000003 R13: ffffffff85c71de0 R14: 0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88006ca00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffe9c0d6dac CR3: 00000000614f4000 CR4: 00000000000006f0 Call Trace: usbnet_probe+0x18b5/0x2790 drivers/net/usb/usbnet.c:1783 qmi_wwan_probe+0x133/0x220 drivers/net/usb/qmi_wwan.c:1338 usb_probe_interface+0x324/0x940 drivers/usb/core/driver.c:361 really_probe drivers/base/dd.c:413 driver_probe_device+0x522/0x740 drivers/base/dd.c:557 Fix by simply ignoring the bogus descriptor, as it is optional for QMI devices anyway. Fixes: 423ce8caab7e ("net: usb: qmi_wwan: New driver for Huawei QMI based WWAN devices") Reported-by: Andrey Konovalov <andreyknvl(a)google.com> Signed-off-by: BjÃ¸rn Mork <bjorn(a)mork.no> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/qmi_wwan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -681,7 +681,7 @@ static int qmi_wwan_bind(struct usbnet * } /* errors aren't fatal - we can live with the dynamic address */ - if (cdc_ether) { + if (cdc_ether && cdc_ether->wMaxSegmentSize) { dev->hard_mtu = le16_to_cpu(cdc_ether->wMaxSegmentSize); usbnet_get_ethernet_addr(dev, cdc_ether->iMACAddress); } Patches currently in stable-queue which might be from bjorn(a)mork.no are queue-4.13/net-cdc_ether-fix-divide-by-0-on-bad-descriptors.patch queue-4.13/qmi_wwan-add-missing-skb_reset_mac_header-call.patch queue-4.13/net-qmi_wwan-fix-divide-by-0-on-bad-descriptors.patch queue-4.13/net-cdc_ncm-getntbformat-endian-fix.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "net/mlx5e: Set page to null in case dma mapping fails" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net/mlx5e: Set page to null in case dma mapping fails to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-mlx5e-set-page-to-null-in-case-dma-mapping-fails.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Inbar Karmy <inbark(a)mellanox.com> Date: Sun, 15 Oct 2017 17:30:59 +0300 Subject: net/mlx5e: Set page to null in case dma mapping fails From: Inbar Karmy <inbark(a)mellanox.com> [ Upstream commit 2e50b2619538ea0224c037f6fa746023089e0654 ] Currently, when dma mapping fails, put_page is called, but the page is not set to null. Later, in the page_reuse treatment in mlx5e_free_rx_descs(), mlx5e_page_release() is called for the second time, improperly doing dma_unmap (for a non-mapped address) and an extra put_page. Prevent this by nullifying the page pointer when dma_map fails. Fixes: accd58833237 ("net/mlx5e: Introduce RX Page-Reuse") Signed-off-by: Inbar Karmy <inbark(a)mellanox.com> Reviewed-by: Tariq Toukan <tariqt(a)mellanox.com> Cc: kernel-team(a)fb.com Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) --- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c @@ -213,22 +213,20 @@ static inline bool mlx5e_rx_cache_get(st static inline int mlx5e_page_alloc_mapped(struct mlx5e_rq *rq, struct mlx5e_dma_info *dma_info) { - struct page *page; - if (mlx5e_rx_cache_get(rq, dma_info)) return 0; - page = dev_alloc_pages(rq->buff.page_order); - if (unlikely(!page)) + dma_info->page = dev_alloc_pages(rq->buff.page_order); + if (unlikely(!dma_info->page)) return -ENOMEM; - dma_info->addr = dma_map_page(rq->pdev, page, 0, + dma_info->addr = dma_map_page(rq->pdev, dma_info->page, 0, RQ_PAGE_SIZE(rq), rq->buff.map_dir); if (unlikely(dma_mapping_error(rq->pdev, dma_info->addr))) { - put_page(page); + put_page(dma_info->page); + dma_info->page = NULL; return -ENOMEM; } - dma_info->page = page; return 0; } Patches currently in stable-queue which might be from inbark(a)mellanox.com are queue-4.13/net-mlx5e-set-page-to-null-in-case-dma-mapping-fails.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "net/mlx5: Cancel health poll before sending panic teardown command" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net/mlx5: Cancel health poll before sending panic teardown command to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-mlx5-cancel-health-poll-before-sending-panic-teardown-command.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Huy Nguyen <huyn(a)mellanox.com> Date: Tue, 26 Sep 2017 15:11:56 -0500 Subject: net/mlx5: Cancel health poll before sending panic teardown command From: Huy Nguyen <huyn(a)mellanox.com> [ Upstream commit d2aa060d40fa060e963f9a356d43481e43ba3dac ] After the panic teardown firmware command, health_care detects the error in PCI bus and calls the mlx5_pci_err_detected. This health_care flow is no longer needed because the panic teardown firmware command will bring down the PCI bus communication with the HCA. The solution is to cancel the health care timer and its pending workqueue request before sending panic teardown firmware command. Kernel trace: mlx5_core 0033:01:00.0: Shutdown was called mlx5_core 0033:01:00.0: health_care:154:(pid 9304): handling bad device here mlx5_core 0033:01:00.0: mlx5_handle_bad_state:114:(pid 9304): NIC state 1 mlx5_core 0033:01:00.0: mlx5_pci_err_detected was called mlx5_core 0033:01:00.0: mlx5_enter_error_state:96:(pid 9304): start mlx5_3:mlx5_ib_event:3061:(pid 9304): warning: event on port 0 mlx5_core 0033:01:00.0: mlx5_enter_error_state:104:(pid 9304): end Unable to handle kernel paging request for data at address 0x0000003f Faulting instruction address: 0xc0080000434b8c80 Fixes: 8812c24d28f4 ('net/mlx5: Add fast unload support in shutdown flow') Signed-off-by: Huy Nguyen <huyn(a)mellanox.com> Reviewed-by: Moshe Shemesh <moshe(a)mellanox.com> Signed-off-by: Saeed Mahameed <saeedm(a)mellanox.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/mellanox/mlx5/core/main.c | 7 +++++++ 1 file changed, 7 insertions(+) --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c @@ -1545,9 +1545,16 @@ static int mlx5_try_fast_unload(struct m return -EAGAIN; } + /* Panic tear down fw command will stop the PCI bus communication + * with the HCA, so the health polll is no longer needed. + */ + mlx5_drain_health_wq(dev); + mlx5_stop_health_poll(dev); + ret = mlx5_cmd_force_teardown_hca(dev); if (ret) { mlx5_core_dbg(dev, "Firmware couldn't do fast unload error: %d\n", ret); + mlx5_start_health_poll(dev); return ret; } Patches currently in stable-queue which might be from huyn(a)mellanox.com are queue-4.13/net-mlx5-cancel-health-poll-before-sending-panic-teardown-command.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "net: cdc_ncm: GetNtbFormat endian fix" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: cdc_ncm: GetNtbFormat endian fix to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-cdc_ncm-getntbformat-endian-fix.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Bjørn Mork <bjorn(a)mork.no> Date: Wed, 15 Nov 2017 09:35:02 +0100 Subject: net: cdc_ncm: GetNtbFormat endian fix From: Bjørn Mork <bjorn(a)mork.no> [ Upstream commit 6314dab4b8fb8493d810e175cb340376052c69b6 ] The GetNtbFormat and SetNtbFormat requests operate on 16 bit little endian values. We get away with ignoring this most of the time, because we only care about USB_CDC_NCM_NTB16_FORMAT which is 0x0000. This fails for USB_CDC_NCM_NTB32_FORMAT. Fix comparison between LE value from device and constant by converting the constant to LE. Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk> Fixes: 2b02c20ce0c2 ("cdc_ncm: Set NTB format again after altsetting switch for Huawei devices") Cc: Enrico Mioso <mrkiko.rs(a)gmail.com> Cc: Christian Panton <christian(a)panton.org> Signed-off-by: BjÃ¸rn Mork <bjorn(a)mork.no> Acked-By: Enrico Mioso <mrkiko.rs(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/cdc_ncm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/net/usb/cdc_ncm.c +++ b/drivers/net/usb/cdc_ncm.c @@ -771,7 +771,7 @@ int cdc_ncm_bind_common(struct usbnet *d int err; u8 iface_no; struct usb_cdc_parsed_header hdr; - u16 curr_ntb_format; + __le16 curr_ntb_format; ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); if (!ctx) @@ -889,7 +889,7 @@ int cdc_ncm_bind_common(struct usbnet *d goto error2; } - if (curr_ntb_format == USB_CDC_NCM_NTB32_FORMAT) { + if (curr_ntb_format == cpu_to_le16(USB_CDC_NCM_NTB32_FORMAT)) { dev_info(&intf->dev, "resetting NTB format to 16-bit"); err = usbnet_write_cmd(dev, USB_CDC_SET_NTB_FORMAT, USB_TYPE_CLASS | USB_DIR_OUT Patches currently in stable-queue which might be from bjorn(a)mork.no are queue-4.13/net-cdc_ether-fix-divide-by-0-on-bad-descriptors.patch queue-4.13/qmi_wwan-add-missing-skb_reset_mac_header-call.patch queue-4.13/net-qmi_wwan-fix-divide-by-0-on-bad-descriptors.patch queue-4.13/net-cdc_ncm-getntbformat-endian-fix.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "net: cdc_ether: fix divide by 0 on bad descriptors" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: cdc_ether: fix divide by 0 on bad descriptors to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-cdc_ether-fix-divide-by-0-on-bad-descriptors.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Bjørn Mork <bjorn(a)mork.no> Date: Mon, 6 Nov 2017 15:37:22 +0100 Subject: net: cdc_ether: fix divide by 0 on bad descriptors From: Bjørn Mork <bjorn(a)mork.no> [ Upstream commit 2cb80187ba065d7decad7c6614e35e07aec8a974 ] Setting dev->hard_mtu to 0 will cause a divide error in usbnet_probe. Protect against devices with bogus CDC Ethernet functional descriptors by ignoring a zero wMaxSegmentSize. Signed-off-by: BjÃ¸rn Mork <bjorn(a)mork.no> Acked-by: Oliver Neukum <oneukum(a)suse.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/cdc_ether.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/usb/cdc_ether.c +++ b/drivers/net/usb/cdc_ether.c @@ -221,7 +221,7 @@ skip: goto bad_desc; } - if (header.usb_cdc_ether_desc) { + if (header.usb_cdc_ether_desc && info->ether->wMaxSegmentSize) { dev->hard_mtu = le16_to_cpu(info->ether->wMaxSegmentSize); /* because of Zaurus, we may be ignoring the host * side link address we were given. Patches currently in stable-queue which might be from bjorn(a)mork.no are queue-4.13/net-cdc_ether-fix-divide-by-0-on-bad-descriptors.patch queue-4.13/qmi_wwan-add-missing-skb_reset_mac_header-call.patch queue-4.13/net-qmi_wwan-fix-divide-by-0-on-bad-descriptors.patch queue-4.13/net-cdc_ncm-getntbformat-endian-fix.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "l2tp: don't use l2tp_tunnel_find() in l2tp_ip and l2tp_ip6" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled l2tp: don't use l2tp_tunnel_find() in l2tp_ip and l2tp_ip6 to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: l2tp-don-t-use-l2tp_tunnel_find-in-l2tp_ip-and-l2tp_ip6.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Guillaume Nault <g.nault(a)alphalink.fr> Date: Fri, 3 Nov 2017 16:49:00 +0100 Subject: l2tp: don't use l2tp_tunnel_find() in l2tp_ip and l2tp_ip6 From: Guillaume Nault <g.nault(a)alphalink.fr> [ Upstream commit 8f7dc9ae4a7aece9fbc3e6637bdfa38b36bcdf09 ] Using l2tp_tunnel_find() in l2tp_ip_recv() is wrong for two reasons: * It doesn't take a reference on the returned tunnel, which makes the call racy wrt. concurrent tunnel deletion. * The lookup is only based on the tunnel identifier, so it can return a tunnel that doesn't match the packet's addresses or protocol. For example, a packet sent to an L2TPv3 over IPv6 tunnel can be delivered to an L2TPv2 over UDPv4 tunnel. This is worse than a simple cross-talk: when delivering the packet to an L2TP over UDP tunnel, the corresponding socket is UDP, where ->sk_backlog_rcv() is NULL. Calling sk_receive_skb() will then crash the kernel by trying to execute this callback. And l2tp_tunnel_find() isn't even needed here. __l2tp_ip_bind_lookup() properly checks the socket binding and connection settings. It was used as a fallback mechanism for finding tunnels that didn't have their data path registered yet. But it's not limited to this case and can be used to replace l2tp_tunnel_find() in the general case. Fix l2tp_ip6 in the same way. Fixes: 0d76751fad77 ("l2tp: Add L2TPv3 IP encapsulation (no UDP) support") Fixes: a32e0eec7042 ("l2tp: introduce L2TPv3 IP encapsulation support for IPv6") Signed-off-by: Guillaume Nault <g.nault(a)alphalink.fr> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/l2tp/l2tp_ip.c | 24 +++++++++--------------- net/l2tp/l2tp_ip6.c | 24 +++++++++--------------- 2 files changed, 18 insertions(+), 30 deletions(-) --- a/net/l2tp/l2tp_ip.c +++ b/net/l2tp/l2tp_ip.c @@ -123,6 +123,7 @@ static int l2tp_ip_recv(struct sk_buff * unsigned char *ptr, *optr; struct l2tp_session *session; struct l2tp_tunnel *tunnel = NULL; + struct iphdr *iph; int length; if (!pskb_may_pull(skb, 4)) @@ -178,24 +179,17 @@ pass_up: goto discard; tunnel_id = ntohl(*(__be32 *) &skb->data[4]); - tunnel = l2tp_tunnel_find(net, tunnel_id); - if (tunnel) { - sk = tunnel->sock; - sock_hold(sk); - } else { - struct iphdr *iph = (struct iphdr *) skb_network_header(skb); - - read_lock_bh(&l2tp_ip_lock); - sk = __l2tp_ip_bind_lookup(net, iph->daddr, iph->saddr, - inet_iif(skb), tunnel_id); - if (!sk) { - read_unlock_bh(&l2tp_ip_lock); - goto discard; - } + iph = (struct iphdr *)skb_network_header(skb); - sock_hold(sk); + read_lock_bh(&l2tp_ip_lock); + sk = __l2tp_ip_bind_lookup(net, iph->daddr, iph->saddr, inet_iif(skb), + tunnel_id); + if (!sk) { read_unlock_bh(&l2tp_ip_lock); + goto discard; } + sock_hold(sk); + read_unlock_bh(&l2tp_ip_lock); if (!xfrm4_policy_check(sk, XFRM_POLICY_IN, skb)) goto discard_put; --- a/net/l2tp/l2tp_ip6.c +++ b/net/l2tp/l2tp_ip6.c @@ -136,6 +136,7 @@ static int l2tp_ip6_recv(struct sk_buff unsigned char *ptr, *optr; struct l2tp_session *session; struct l2tp_tunnel *tunnel = NULL; + struct ipv6hdr *iph; int length; if (!pskb_may_pull(skb, 4)) @@ -192,24 +193,17 @@ pass_up: goto discard; tunnel_id = ntohl(*(__be32 *) &skb->data[4]); - tunnel = l2tp_tunnel_find(net, tunnel_id); - if (tunnel) { - sk = tunnel->sock; - sock_hold(sk); - } else { - struct ipv6hdr *iph = ipv6_hdr(skb); - - read_lock_bh(&l2tp_ip6_lock); - sk = __l2tp_ip6_bind_lookup(net, &iph->daddr, &iph->saddr, - inet6_iif(skb), tunnel_id); - if (!sk) { - read_unlock_bh(&l2tp_ip6_lock); - goto discard; - } + iph = ipv6_hdr(skb); - sock_hold(sk); + read_lock_bh(&l2tp_ip6_lock); + sk = __l2tp_ip6_bind_lookup(net, &iph->daddr, &iph->saddr, + inet6_iif(skb), tunnel_id); + if (!sk) { read_unlock_bh(&l2tp_ip6_lock); + goto discard; } + sock_hold(sk); + read_unlock_bh(&l2tp_ip6_lock); if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb)) goto discard_put; Patches currently in stable-queue which might be from g.nault(a)alphalink.fr are queue-4.13/l2tp-don-t-use-l2tp_tunnel_find-in-l2tp_ip-and-l2tp_ip6.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "fealnx: Fix building error on MIPS" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fealnx: Fix building error on MIPS to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fealnx-fix-building-error-on-mips.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Huacai Chen <chenhc(a)lemote.com> Date: Thu, 16 Nov 2017 11:07:15 +0800 Subject: fealnx: Fix building error on MIPS From: Huacai Chen <chenhc(a)lemote.com> [ Upstream commit cc54c1d32e6a4bb3f116721abf900513173e4d02 ] This patch try to fix the building error on MIPS. The reason is MIPS has already defined the LONG macro, which conflicts with the LONG enum in drivers/net/ethernet/fealnx.c. Signed-off-by: Huacai Chen <chenhc(a)lemote.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/fealnx.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/net/ethernet/fealnx.c +++ b/drivers/net/ethernet/fealnx.c @@ -257,8 +257,8 @@ enum rx_desc_status_bits { RXFSD = 0x00000800, /* first descriptor */ RXLSD = 0x00000400, /* last descriptor */ ErrorSummary = 0x80, /* error summary */ - RUNT = 0x40, /* runt packet received */ - LONG = 0x20, /* long packet received */ + RUNTPKT = 0x40, /* runt packet received */ + LONGPKT = 0x20, /* long packet received */ FAE = 0x10, /* frame align error */ CRC = 0x08, /* crc error */ RXER = 0x04, /* receive error */ @@ -1632,7 +1632,7 @@ static int netdev_rx(struct net_device * dev->name, rx_status); dev->stats.rx_errors++; /* end of a packet. */ - if (rx_status & (LONG | RUNT)) + if (rx_status & (LONGPKT | RUNTPKT)) dev->stats.rx_length_errors++; if (rx_status & RXER) dev->stats.rx_frame_errors++; Patches currently in stable-queue which might be from chenhc(a)lemote.com are queue-4.13/fealnx-fix-building-error-on-mips.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "bonding: discard lowest hash bit for 802.3ad layer3+4" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled bonding: discard lowest hash bit for 802.3ad layer3+4 to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: bonding-discard-lowest-hash-bit-for-802.3ad-layer3-4.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: Hangbin Liu <liuhangbin(a)gmail.com> Date: Mon, 6 Nov 2017 09:01:57 +0800 Subject: bonding: discard lowest hash bit for 802.3ad layer3+4 From: Hangbin Liu <liuhangbin(a)gmail.com> [ Upstream commit b5f862180d7011d9575d0499fa37f0f25b423b12 ] After commit 07f4c90062f8 ("tcp/dccp: try to not exhaust ip_local_port_range in connect()"), we will try to use even ports for connect(). Then if an application (seen clearly with iperf) opens multiple streams to the same destination IP and port, each stream will be given an even source port. So the bonding driver's simple xmit_hash_policy based on layer3+4 addressing will always hash all these streams to the same interface. And the total throughput will limited to a single slave. Change the tcp code will impact the whole tcp behavior, only for bonding usage. Paolo Abeni suggested fix this by changing the bonding code only, which should be more reasonable, and less impact. Fix this by discarding the lowest hash bit because it contains little entropy. After the fix we can re-balance between slaves. Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/bonding/bond_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/bonding/bond_main.c +++ b/drivers/net/bonding/bond_main.c @@ -3253,7 +3253,7 @@ u32 bond_xmit_hash(struct bonding *bond, hash ^= (hash >> 16); hash ^= (hash >> 8); - return hash; + return hash >> 1; } /*-------------------------- Device entry points ----------------------------*/ Patches currently in stable-queue which might be from liuhangbin(a)gmail.com are queue-4.13/bonding-discard-lowest-hash-bit-for-802.3ad-layer3-4.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "af_netlink: ensure that NLMSG_DONE never fails in dumps" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled af_netlink: ensure that NLMSG_DONE never fails in dumps to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: af_netlink-ensure-that-nlmsg_done-never-fails-in-dumps.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Tue Nov 21 13:07:20 CET 2017 From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> Date: Thu, 9 Nov 2017 13:04:44 +0900 Subject: af_netlink: ensure that NLMSG_DONE never fails in dumps From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> [ Upstream commit 0642840b8bb008528dbdf929cec9f65ac4231ad0 ] The way people generally use netlink_dump is that they fill in the skb as much as possible, breaking when nla_put returns an error. Then, they get called again and start filling out the next skb, and again, and so forth. The mechanism at work here is the ability for the iterative dumping function to detect when the skb is filled up and not fill it past the brim, waiting for a fresh skb for the rest of the data. However, if the attributes are small and nicely packed, it is possible that a dump callback function successfully fills in attributes until the skb is of size 4080 (libmnl's default page-sized receive buffer size). The dump function completes, satisfied, and then, if it happens to be that this is actually the last skb, and no further ones are to be sent, then netlink_dump will add on the NLMSG_DONE part: nlh = nlmsg_put_answer(skb, cb, NLMSG_DONE, sizeof(len), NLM_F_MULTI); It is very important that netlink_dump does this, of course. However, in this example, that call to nlmsg_put_answer will fail, because the previous filling by the dump function did not leave it enough room. And how could it possibly have done so? All of the nla_put variety of functions simply check to see if the skb has enough tailroom, independent of the context it is in. In order to keep the important assumptions of all netlink dump users, it is therefore important to give them an skb that has this end part of the tail already reserved, so that the call to nlmsg_put_answer does not fail. Otherwise, library authors are forced to find some bizarre sized receive buffer that has a large modulo relative to the common sizes of messages received, which is ugly and buggy. This patch thus saves the NLMSG_DONE for an additional message, for the case that things are dangerously close to the brim. This requires keeping track of the errno from ->dump() across calls. Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netlink/af_netlink.c | 17 +++++++++++------ net/netlink/af_netlink.h | 1 + 2 files changed, 12 insertions(+), 6 deletions(-) --- a/net/netlink/af_netlink.c +++ b/net/netlink/af_netlink.c @@ -2128,7 +2128,7 @@ static int netlink_dump(struct sock *sk) struct sk_buff *skb = NULL; struct nlmsghdr *nlh; struct module *module; - int len, err = -ENOBUFS; + int err = -ENOBUFS; int alloc_min_size; int alloc_size; @@ -2175,9 +2175,11 @@ static int netlink_dump(struct sock *sk) skb_reserve(skb, skb_tailroom(skb) - alloc_size); netlink_skb_set_owner_r(skb, sk); - len = cb->dump(skb, cb); + if (nlk->dump_done_errno > 0) + nlk->dump_done_errno = cb->dump(skb, cb); - if (len > 0) { + if (nlk->dump_done_errno > 0 || + skb_tailroom(skb) < nlmsg_total_size(sizeof(nlk->dump_done_errno))) { mutex_unlock(nlk->cb_mutex); if (sk_filter(sk, skb)) @@ -2187,13 +2189,15 @@ static int netlink_dump(struct sock *sk) return 0; } - nlh = nlmsg_put_answer(skb, cb, NLMSG_DONE, sizeof(len), NLM_F_MULTI); - if (!nlh) + nlh = nlmsg_put_answer(skb, cb, NLMSG_DONE, + sizeof(nlk->dump_done_errno), NLM_F_MULTI); + if (WARN_ON(!nlh)) goto errout_skb; nl_dump_check_consistent(cb, nlh); - memcpy(nlmsg_data(nlh), &len, sizeof(len)); + memcpy(nlmsg_data(nlh), &nlk->dump_done_errno, + sizeof(nlk->dump_done_errno)); if (sk_filter(sk, skb)) kfree_skb(skb); @@ -2265,6 +2269,7 @@ int __netlink_dump_start(struct sock *ss } nlk->cb_running = true; + nlk->dump_done_errno = INT_MAX; mutex_unlock(nlk->cb_mutex); --- a/net/netlink/af_netlink.h +++ b/net/netlink/af_netlink.h @@ -33,6 +33,7 @@ struct netlink_sock { wait_queue_head_t wait; bool bound; bool cb_running; + int dump_done_errno; struct netlink_callback cb; struct mutex *cb_mutex; struct mutex cb_def_mutex; Patches currently in stable-queue which might be from Jason(a)zx2c4.com are queue-4.13/af_netlink-ensure-that-nlmsg_done-never-fails-in-dumps.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] [PATCH v2] omapdrm: hdmi4: Correct the SoC revision matching

by Peter Ujfalusi

I believe the intention of the commit 2c9fc9bf45f8 ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver") was to identify omap4430 ES1.x, omap4430 ES2.x and other OMAP4 revisions, like omap4460. By using family=OMAP4 in the match the code will treat omap4460 ES1.x in a same way as it would treat omap4430 ES1.x This breaks HDMI audio on OMAP4460 devices (PandaES for example). Correct the match rule so we are not going to get false positive match. Fixes: 2c9fc9bf45f8 ("drm: omapdrm: Move FEAT_HDMI_* features to hdmi4 driver") CC: stable(a)vger.kernel.org # 4.14 Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- Hi, Changes since v1: - fix the hdmi4_features structure names for clarity. Regards, Peter drivers/gpu/drm/omapdrm/dss/hdmi4_core.c | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c index 62e451162d96..b06f9956e733 100644 --- a/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4_core.c @@ -886,25 +886,36 @@ struct hdmi4_features { bool audio_use_mclk; }; -static const struct hdmi4_features hdmi4_es1_features = { +static const struct hdmi4_features hdmi4430_es1_features = { .cts_swmode = false, .audio_use_mclk = false, }; -static const struct hdmi4_features hdmi4_es2_features = { +static const struct hdmi4_features hdmi4430_es2_features = { .cts_swmode = true, .audio_use_mclk = false, }; -static const struct hdmi4_features hdmi4_es3_features = { +static const struct hdmi4_features hdmi4_features = { .cts_swmode = true, .audio_use_mclk = true, }; static const struct soc_device_attribute hdmi4_soc_devices[] = { - { .family = "OMAP4", .revision = "ES1.?", .data = &hdmi4_es1_features }, - { .family = "OMAP4", .revision = "ES2.?", .data = &hdmi4_es2_features }, - { .family = "OMAP4", .data = &hdmi4_es3_features }, + { + .machine = "OMAP4430", + .revision = "ES1.?", + .data = &hdmi4430_es1_features, + }, + { + .machine = "OMAP4430", + .revision = "ES2.?", + .data = &hdmi4430_es2_features, + }, + { + .family = "OMAP4", + .data = &hdmi4_features, + }, { /* sentinel */ } }; -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

7 years, 11 months

3
2
0 0

[Linux-stable-mirror] [PATCH v3 15/17] lpfc: Fix driver handling of nvme resources during unload

by James Smart

During driver unload, the driver may crash due to NULL pointers. The NULL pointers were due to the driver not protecting itself sufficiently during some of the teardown paths. Additionally, the driver was not waiting for and cleanup up nvme io resources. As such, the driver wasn't making the callbacks to the transport, stalling the transports association teardown. This patch waits for io clean up before tearding down and adds checks for possible NULL pointers. Cc: <stable(a)vger.kernel.org> # 4.12+ Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com> Signed-off-by: James Smart <james.smart(a)broadcom.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> --- drivers/scsi/lpfc/lpfc_crtn.h | 2 + drivers/scsi/lpfc/lpfc_init.c | 18 ++++++++ drivers/scsi/lpfc/lpfc_nvme.c | 96 ++++++++++++++++++++++++++++++++++++++----- 3 files changed, 105 insertions(+), 11 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_crtn.h b/drivers/scsi/lpfc/lpfc_crtn.h index 7e300734b345..dac33900bf17 100644 --- a/drivers/scsi/lpfc/lpfc_crtn.h +++ b/drivers/scsi/lpfc/lpfc_crtn.h @@ -254,6 +254,8 @@ void lpfc_nvmet_ctxbuf_post(struct lpfc_hba *phba, struct lpfc_nvmet_ctxbuf *ctxp); int lpfc_nvmet_rcv_unsol_abort(struct lpfc_vport *vport, struct fc_frame_header *fc_hdr); +void lpfc_sli_flush_nvme_rings(struct lpfc_hba *phba); +void lpfc_nvme_wait_for_io_drain(struct lpfc_hba *phba); void lpfc_sli4_build_dflt_fcf_record(struct lpfc_hba *, struct fcf_record *, uint16_t); int lpfc_sli4_rq_put(struct lpfc_queue *hq, struct lpfc_queue *dq, diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c index 7a06f23a3baf..c466ceb43bc9 100644 --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -10136,6 +10136,16 @@ lpfc_sli4_xri_exchange_busy_wait(struct lpfc_hba *phba) int fcp_xri_cmpl = 1; int els_xri_cmpl = list_empty(&phba->sli4_hba.lpfc_abts_els_sgl_list); + /* Driver just aborted IOs during the hba_unset process. Pause + * here to give the HBA time to complete the IO and get entries + * into the abts lists. + */ + msleep(LPFC_XRI_EXCH_BUSY_WAIT_T1 * 5); + + /* Wait for NVME pending IO to flush back to transport. */ + if (phba->cfg_enable_fc4_type & LPFC_ENABLE_NVME) + lpfc_nvme_wait_for_io_drain(phba); + if (phba->cfg_enable_fc4_type & LPFC_ENABLE_FCP) fcp_xri_cmpl = list_empty(&phba->sli4_hba.lpfc_abts_scsi_buf_list); @@ -11659,6 +11669,10 @@ lpfc_sli4_prep_dev_for_reset(struct lpfc_hba *phba) /* Flush all driver's outstanding SCSI I/Os as we are to reset */ lpfc_sli_flush_fcp_rings(phba); + /* Flush the outstanding NVME IOs if fc4 type enabled. */ + if (phba->cfg_enable_fc4_type & LPFC_ENABLE_NVME) + lpfc_sli_flush_nvme_rings(phba); + /* stop all timers */ lpfc_stop_hba_timers(phba); @@ -11690,6 +11704,10 @@ lpfc_sli4_prep_dev_for_perm_failure(struct lpfc_hba *phba) /* Clean up all driver's outstanding SCSI I/Os */ lpfc_sli_flush_fcp_rings(phba); + + /* Flush the outstanding NVME IOs if fc4 type enabled. */ + if (phba->cfg_enable_fc4_type & LPFC_ENABLE_NVME) + lpfc_sli_flush_nvme_rings(phba); } /** diff --git a/drivers/scsi/lpfc/lpfc_nvme.c b/drivers/scsi/lpfc/lpfc_nvme.c index 9b231c88ca8b..50bbc61bfe5d 100644 --- a/drivers/scsi/lpfc/lpfc_nvme.c +++ b/drivers/scsi/lpfc/lpfc_nvme.c @@ -88,6 +88,9 @@ lpfc_nvme_create_queue(struct nvme_fc_local_port *pnvme_lport, struct lpfc_nvme_qhandle *qhandle; char *str; + if (!pnvme_lport->private) + return -ENOMEM; + lport = (struct lpfc_nvme_lport *)pnvme_lport->private; vport = lport->vport; qhandle = kzalloc(sizeof(struct lpfc_nvme_qhandle), GFP_KERNEL); @@ -140,6 +143,9 @@ lpfc_nvme_delete_queue(struct nvme_fc_local_port *pnvme_lport, struct lpfc_nvme_lport *lport; struct lpfc_vport *vport; + if (!pnvme_lport->private) + return; + lport = (struct lpfc_nvme_lport *)pnvme_lport->private; vport = lport->vport; @@ -1265,13 +1271,29 @@ lpfc_nvme_fcp_io_submit(struct nvme_fc_local_port *pnvme_lport, struct lpfc_nvme_buf *lpfc_ncmd; struct lpfc_nvme_rport *rport; struct lpfc_nvme_qhandle *lpfc_queue_info; - struct lpfc_nvme_fcpreq_priv *freqpriv = pnvme_fcreq->private; + struct lpfc_nvme_fcpreq_priv *freqpriv; #ifdef CONFIG_SCSI_LPFC_DEBUG_FS uint64_t start = 0; #endif + /* Validate pointers. LLDD fault handling with transport does + * have timing races. + */ lport = (struct lpfc_nvme_lport *)pnvme_lport->private; + if (unlikely(!lport)) { + ret = -EINVAL; + goto out_fail; + } + vport = lport->vport; + + if (unlikely(!hw_queue_handle)) { + lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_ABTS, + "6129 Fail Abort, NULL hw_queue_handle\n"); + ret = -EINVAL; + goto out_fail; + } + phba = vport->phba; if (vport->load_flag & FC_UNLOADING) { @@ -1284,13 +1306,9 @@ lpfc_nvme_fcp_io_submit(struct nvme_fc_local_port *pnvme_lport, goto out_fail; } - /* Validate pointers. */ - if (!pnvme_lport || !pnvme_rport || !freqpriv) { - lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_IOERR | LOG_NODE, - "6117 No Send:IO submit ptrs NULL, lport %p, " - "rport %p fcreq_priv %p\n", - pnvme_lport, pnvme_rport, freqpriv); - ret = -ENODEV; + freqpriv = pnvme_fcreq->private; + if (unlikely(!freqpriv)) { + ret = -EINVAL; goto out_fail; } @@ -1497,20 +1515,34 @@ lpfc_nvme_fcp_abort(struct nvme_fc_local_port *pnvme_lport, struct lpfc_nvme_lport *lport; struct lpfc_vport *vport; struct lpfc_hba *phba; - struct lpfc_nvme_rport *rport; struct lpfc_nvme_buf *lpfc_nbuf; struct lpfc_iocbq *abts_buf; struct lpfc_iocbq *nvmereq_wqe; - struct lpfc_nvme_fcpreq_priv *freqpriv = pnvme_fcreq->private; + struct lpfc_nvme_fcpreq_priv *freqpriv; union lpfc_wqe *abts_wqe; unsigned long flags; int ret_val; + /* Validate pointers. LLDD fault handling with transport does + * have timing races. + */ lport = (struct lpfc_nvme_lport *)pnvme_lport->private; - rport = (struct lpfc_nvme_rport *)pnvme_rport->private; + if (unlikely(!lport)) + return; + vport = lport->vport; + + if (unlikely(!hw_queue_handle)) { + lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_ABTS, + "6129 Fail Abort, HW Queue Handle NULL.\n"); + return; + } + phba = vport->phba; + freqpriv = pnvme_fcreq->private; + if (unlikely(!freqpriv)) + return; if (vport->load_flag & FC_UNLOADING) return; @@ -2677,3 +2709,45 @@ lpfc_sli4_nvme_xri_aborted(struct lpfc_hba *phba, "6312 XRI Aborted xri x%x not found\n", xri); } + +/** + * lpfc_nvme_wait_for_io_drain - Wait for all NVME wqes to complete + * @phba: Pointer to HBA context object. + * + * This function flushes all wqes in the nvme rings and frees all resources + * in the txcmplq. This function does not issue abort wqes for the IO + * commands in txcmplq, they will just be returned with + * IOERR_SLI_DOWN. This function is invoked with EEH when device's PCI + * slot has been permanently disabled. + **/ +void +lpfc_nvme_wait_for_io_drain(struct lpfc_hba *phba) +{ + struct lpfc_sli_ring *pring; + u32 i, wait_cnt = 0; + + if (phba->sli_rev < LPFC_SLI_REV4) + return; + + /* Cycle through all NVME rings and make sure all outstanding + * WQEs have been removed from the txcmplqs. + */ + for (i = 0; i < phba->cfg_nvme_io_channel; i++) { + pring = phba->sli4_hba.nvme_wq[i]->pring; + + /* Retrieve everything on the txcmplq */ + while (!list_empty(&pring->txcmplq)) { + msleep(LPFC_XRI_EXCH_BUSY_WAIT_T1); + wait_cnt++; + + /* The sleep is 10mS. Every ten seconds, + * dump a message. Something is wrong. + */ + if ((wait_cnt % 1000) == 0) { + lpfc_printf_log(phba, KERN_ERR, LOG_NVME_IOERR, + "6178 NVME IO not empty, " + "cnt %d\n", wait_cnt); + } + } + } +} -- 2.13.1

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] [PATCH v3 04/17] lpfc: Fix crash after bad bar setup on driver attachment

by James Smart

In test cases where an instance of the driver is detached and reattached, the driver will crash on reattachment. There is a compound if statement that will skip over the bar setup if the pci_resource_start call is not successful. The driver erroneously returns success to its bar setup in this scenario even though the bars aren't properly configured. Rework the offending code segment for proper initialization steps. If the pci_resource_start call fails, -ENOMEM is now returned. Sample stack: rport-5:0-10: blocked FC remote port time out: removing rport BUG: unable to handle kernel NULL pointer dereference at (null) ... lpfc_sli4_wait_bmbx_ready+0x32/0x70 [lpfc] ... ... RIP: 0010:... ... lpfc_sli4_wait_bmbx_ready+0x32/0x70 [lpfc] Call Trace: ... lpfc_sli4_post_sync_mbox+0x106/0x4d0 [lpfc] ... ? __alloc_pages_nodemask+0x176/0x420 ... ? __kmalloc+0x2e/0x230 ... lpfc_sli_issue_mbox_s4+0x533/0x720 [lpfc] ... ? mempool_alloc+0x69/0x170 ... ? dma_generic_alloc_coherent+0x8f/0x140 ... lpfc_sli_issue_mbox+0xf/0x20 [lpfc] ... lpfc_sli4_driver_resource_setup+0xa6f/0x1130 [lpfc] ... ? lpfc_pci_probe_one+0x23e/0x16f0 [lpfc] ... lpfc_pci_probe_one+0x445/0x16f0 [lpfc] ... local_pci_probe+0x45/0xa0 ... work_for_cpu_fn+0x14/0x20 ... process_one_work+0x17a/0x440 Cc: <stable(a)vger.kernel.org> # 4.12+ Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com> Signed-off-by: James Smart <james.smart(a)broadcom.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> --- drivers/scsi/lpfc/lpfc_init.c | 84 ++++++++++++++++++++++++++----------------- 1 file changed, 51 insertions(+), 33 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c index 745aff753396..fc9f91327724 100644 --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -9437,44 +9437,62 @@ lpfc_sli4_pci_mem_setup(struct lpfc_hba *phba) lpfc_sli4_bar0_register_memmap(phba, if_type); } - if ((if_type == LPFC_SLI_INTF_IF_TYPE_0) && - (pci_resource_start(pdev, PCI_64BIT_BAR2))) { - /* - * Map SLI4 if type 0 HBA Control Register base to a kernel - * virtual address and setup the registers. - */ - phba->pci_bar1_map = pci_resource_start(pdev, PCI_64BIT_BAR2); - bar1map_len = pci_resource_len(pdev, PCI_64BIT_BAR2); - phba->sli4_hba.ctrl_regs_memmap_p = - ioremap(phba->pci_bar1_map, bar1map_len); - if (!phba->sli4_hba.ctrl_regs_memmap_p) { - dev_printk(KERN_ERR, &pdev->dev, - "ioremap failed for SLI4 HBA control registers.\n"); + if (if_type == LPFC_SLI_INTF_IF_TYPE_0) { + if (pci_resource_start(pdev, PCI_64BIT_BAR2)) { + /* + * Map SLI4 if type 0 HBA Control Register base to a + * kernel virtual address and setup the registers. + */ + phba->pci_bar1_map = pci_resource_start(pdev, + PCI_64BIT_BAR2); + bar1map_len = pci_resource_len(pdev, PCI_64BIT_BAR2); + phba->sli4_hba.ctrl_regs_memmap_p = + ioremap(phba->pci_bar1_map, + bar1map_len); + if (!phba->sli4_hba.ctrl_regs_memmap_p) { + dev_err(&pdev->dev, + "ioremap failed for SLI4 HBA " + "control registers.\n"); + error = -ENOMEM; + goto out_iounmap_conf; + } + phba->pci_bar2_memmap_p = + phba->sli4_hba.ctrl_regs_memmap_p; + lpfc_sli4_bar1_register_memmap(phba); + } else { + error = -ENOMEM; goto out_iounmap_conf; } - phba->pci_bar2_memmap_p = phba->sli4_hba.ctrl_regs_memmap_p; - lpfc_sli4_bar1_register_memmap(phba); } - if ((if_type == LPFC_SLI_INTF_IF_TYPE_0) && - (pci_resource_start(pdev, PCI_64BIT_BAR4))) { - /* - * Map SLI4 if type 0 HBA Doorbell Register base to a kernel - * virtual address and setup the registers. - */ - phba->pci_bar2_map = pci_resource_start(pdev, PCI_64BIT_BAR4); - bar2map_len = pci_resource_len(pdev, PCI_64BIT_BAR4); - phba->sli4_hba.drbl_regs_memmap_p = - ioremap(phba->pci_bar2_map, bar2map_len); - if (!phba->sli4_hba.drbl_regs_memmap_p) { - dev_printk(KERN_ERR, &pdev->dev, - "ioremap failed for SLI4 HBA doorbell registers.\n"); - goto out_iounmap_ctrl; - } - phba->pci_bar4_memmap_p = phba->sli4_hba.drbl_regs_memmap_p; - error = lpfc_sli4_bar2_register_memmap(phba, LPFC_VF0); - if (error) + if (if_type == LPFC_SLI_INTF_IF_TYPE_0) { + if (pci_resource_start(pdev, PCI_64BIT_BAR4)) { + /* + * Map SLI4 if type 0 HBA Doorbell Register base to + * a kernel virtual address and setup the registers. + */ + phba->pci_bar2_map = pci_resource_start(pdev, + PCI_64BIT_BAR4); + bar2map_len = pci_resource_len(pdev, PCI_64BIT_BAR4); + phba->sli4_hba.drbl_regs_memmap_p = + ioremap(phba->pci_bar2_map, + bar2map_len); + if (!phba->sli4_hba.drbl_regs_memmap_p) { + dev_err(&pdev->dev, + "ioremap failed for SLI4 HBA" + " doorbell registers.\n"); + error = -ENOMEM; + goto out_iounmap_ctrl; + } + phba->pci_bar4_memmap_p = + phba->sli4_hba.drbl_regs_memmap_p; + error = lpfc_sli4_bar2_register_memmap(phba, LPFC_VF0); + if (error) + goto out_iounmap_all; + } else { + error = -ENOMEM; goto out_iounmap_all; + } } return 0; -- 2.13.1

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] + mm-cma-fix-alloc_contig_range-ret-code-potential-leak.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/cma: fix alloc_contig_range ret code/potential leak has been added to the -mm tree. Its filename is mm-cma-fix-alloc_contig_range-ret-code-potential-leak.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-cma-fix-alloc_contig_range-ret-… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-cma-fix-alloc_contig_range-ret-… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Mike Kravetz <mike.kravetz(a)oracle.com> Subject: mm/cma: fix alloc_contig_range ret code/potential leak If the call __alloc_contig_migrate_range() in alloc_contig_range returns -EBUSY, processing continues so that test_pages_isolated() is called where there is a tracepoint to identify the busy pages. However, it is possible for busy pages to become available between the calls to these two routines. In this case, the range of pages may be allocated. Unfortunately, the original return code (ret == -EBUSY) is still set and returned to the caller. Therefore, the caller believes the pages were not allocated and they are leaked. Update the return code with the value from test_pages_isolated(). Link: http://lkml.kernel.org/r/20171120193930.23428-2-mike.kravetz@oracle.com Fixes: 8ef5849fa8a2 ("mm/cma: always check which page caused allocation failure") Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> Cc: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Cc: Laura Abbott <labbott(a)redhat.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Michal Nazarewicz <mina86(a)mina86.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/page_alloc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -puN mm/page_alloc.c~mm-cma-fix-alloc_contig_range-ret-code-potential-leak mm/page_alloc.c --- a/mm/page_alloc.c~mm-cma-fix-alloc_contig_range-ret-code-potential-leak +++ a/mm/page_alloc.c @@ -7706,10 +7706,10 @@ int alloc_contig_range(unsigned long sta } /* Make sure the range is really isolated. */ - if (test_pages_isolated(outer_start, end, false)) { + ret = test_pages_isolated(outer_start, end, false); + if (ret) { pr_info_ratelimited("%s: [%lx, %lx) PFNs busy\n", __func__, outer_start, end); - ret = -EBUSY; goto done; } _ Patches currently in -mm which might be from mike.kravetz(a)oracle.com are mm-cma-fix-alloc_contig_range-ret-code-potential-leak.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] [merged] nilfs2-fix-race-condition-that-causes-file-system-corruption.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: nilfs2: fix race condition that causes file system corruption has been removed from the -mm tree. Its filename was nilfs2-fix-race-condition-that-causes-file-system-corruption.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Andreas Rohner <andreas.rohner(a)gmx.net> Subject: nilfs2: fix race condition that causes file system corruption There is a race condition between nilfs_dirty_inode() and nilfs_set_file_dirty(). When a file is opened, nilfs_dirty_inode() is called to update the access timestamp in the inode. It calls __nilfs_mark_inode_dirty() in a separate transaction. __nilfs_mark_inode_dirty() caches the ifile buffer_head in the i_bh field of the inode info structure and marks it as dirty. After some data was written to the file in another transaction, the function nilfs_set_file_dirty() is called, which adds the inode to the ns_dirty_files list. Then the segment construction calls nilfs_segctor_collect_dirty_files(), which goes through the ns_dirty_files list and checks the i_bh field. If there is a cached buffer_head in i_bh it is not marked as dirty again. Since nilfs_dirty_inode() and nilfs_set_file_dirty() use separate transactions, it is possible that a segment construction that writes out the ifile occurs in-between the two. If this happens the inode is not on the ns_dirty_files list, but its ifile block is still marked as dirty and written out. In the next segment construction, the data for the file is written out and nilfs_bmap_propagate() updates the b-tree. Eventually the bmap root is written into the i_bh block, which is not dirty, because it was written out in another segment construction. As a result the bmap update can be lost, which leads to file system corruption. Either the virtual block address points to an unallocated DAT block, or the DAT entry will be reused for something different. The error can remain undetected for a long time. A typical error message would be one of the "bad btree" errors or a warning that a DAT entry could not be found. This bug can be reproduced reliably by a simple benchmark that creates and overwrites millions of 4k files. Link: http://lkml.kernel.org/r/1509367935-3086-2-git-send-email-konishi.ryusuke@l… Signed-off-by: Andreas Rohner <andreas.rohner(a)gmx.net> Signed-off-by: Ryusuke Konishi <konishi.ryusuke(a)lab.ntt.co.jp> Tested-by: Andreas Rohner <andreas.rohner(a)gmx.net> Tested-by: Ryusuke Konishi <konishi.ryusuke(a)lab.ntt.co.jp> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/nilfs2/segment.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff -puN fs/nilfs2/segment.c~nilfs2-fix-race-condition-that-causes-file-system-corruption fs/nilfs2/segment.c --- a/fs/nilfs2/segment.c~nilfs2-fix-race-condition-that-causes-file-system-corruption +++ a/fs/nilfs2/segment.c @@ -1954,8 +1954,6 @@ static int nilfs_segctor_collect_dirty_f err, ii->vfs_inode.i_ino); return err; } - mark_buffer_dirty(ibh); - nilfs_mdt_mark_dirty(ifile); spin_lock(&nilfs->ns_inode_lock); if (likely(!ii->i_bh)) ii->i_bh = ibh; @@ -1964,6 +1962,10 @@ static int nilfs_segctor_collect_dirty_f goto retry; } + // Always redirty the buffer to avoid race condition + mark_buffer_dirty(ii->i_bh); + nilfs_mdt_mark_dirty(ifile); + clear_bit(NILFS_I_QUEUED, &ii->i_state); set_bit(NILFS_I_BUSY, &ii->i_state); list_move_tail(&ii->i_dirty, &sci->sc_dirty_files); _ Patches currently in -mm which might be from andreas.rohner(a)gmx.net are

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] [merged] autofs-dont-fail-mount-for-transient-error.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: autofs: don't fail mount for transient error has been removed from the -mm tree. Its filename was autofs-dont-fail-mount-for-transient-error.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: NeilBrown <neilb(a)suse.com> Subject: autofs: don't fail mount for transient error Currently if the autofs kernel module gets an error when writing to the pipe which links to the daemon, then it marks the whole moutpoint as catatonic, and it will stop working. It is possible that the error is transient. This can happen if the daemon is slow and more than 16 requests queue up. If a subsequent process tries to queue a request, and is then signalled, the write to the pipe will return -ERESTARTSYS and autofs will take that as total failure. So change the code to assess -ERESTARTSYS and -ENOMEM as transient failures which only abort the current request, not the whole mountpoint. It isn't a crash or a data corruption, but having autofs mountpoints suddenly stop working is rather inconvenient. Ian said: : And given the problems with a half dozen (or so) user space applications : consuming large amounts of CPU under heavy mount and umount activity this : could happen more easily than we expect. Link: http://lkml.kernel.org/r/87y3norvgp.fsf@notabene.neil.brown.name Signed-off-by: NeilBrown <neilb(a)suse.com> Acked-by: Ian Kent <raven(a)themaw.net> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/autofs4/waitq.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff -puN fs/autofs4/waitq.c~autofs-dont-fail-mount-for-transient-error fs/autofs4/waitq.c --- a/fs/autofs4/waitq.c~autofs-dont-fail-mount-for-transient-error +++ a/fs/autofs4/waitq.c @@ -81,7 +81,8 @@ static int autofs4_write(struct autofs_s spin_unlock_irqrestore(&current->sighand->siglock, flags); } - return (bytes > 0); + /* if 'wr' returned 0 (impossible) we assume -EIO (safe) */ + return bytes == 0 ? 0 : wr < 0 ? wr : -EIO; } static void autofs4_notify_daemon(struct autofs_sb_info *sbi, @@ -95,6 +96,7 @@ static void autofs4_notify_daemon(struct } pkt; struct file *pipe = NULL; size_t pktsz; + int ret; pr_debug("wait id = 0x%08lx, name = %.*s, type=%d\n", (unsigned long) wq->wait_queue_token, @@ -169,7 +171,18 @@ static void autofs4_notify_daemon(struct mutex_unlock(&sbi->wq_mutex); if (autofs4_write(sbi, pipe, &pkt, pktsz)) + switch (ret = autofs4_write(sbi, pipe, &pkt, pktsz)) { + case 0: + break; + case -ENOMEM: + case -ERESTARTSYS: + /* Just fail this one */ + autofs4_wait_release(sbi, wq->wait_queue_token, ret); + break; + default: autofs4_catatonic_mode(sbi); + break; + } fput(pipe); } _ Patches currently in -mm which might be from neilb(a)suse.com are

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] [merged] z3fold-use-kref-to-prevent-page-free-compact-race.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/z3fold.c: use kref to prevent page free/compact race has been removed from the -mm tree. Its filename was z3fold-use-kref-to-prevent-page-free-compact-race.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Vitaly Wool <vitalywool(a)gmail.com> Subject: mm/z3fold.c: use kref to prevent page free/compact race There is a race in the current z3fold implementation between do_compact() called in a work queue context and the page release procedure when page's kref goes to 0. do_compact() may be waiting for page lock, which is released by release_z3fold_page_locked right before putting the page onto the "stale" list, and then the page may be freed as do_compact() modifies its contents. The mechanism currently implemented to handle that (checking the PAGE_STALE flag) is not reliable enough. Instead, we'll use page's kref counter to guarantee that the page is not released if its compaction is scheduled. It then becomes compaction function's responsibility to decrease the counter and quit immediately if the page was actually freed. Link: http://lkml.kernel.org/r/20171117092032.00ea56f42affbed19f4fcc6c@gmail.com Signed-off-by: Vitaly Wool <vitaly.wool(a)sonymobile.com> Cc: <Oleksiy.Avramchenko(a)sony.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/z3fold.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff -puN mm/z3fold.c~z3fold-use-kref-to-prevent-page-free-compact-race mm/z3fold.c --- a/mm/z3fold.c~z3fold-use-kref-to-prevent-page-free-compact-race +++ a/mm/z3fold.c @@ -404,8 +404,7 @@ static void do_compact_page(struct z3fol WARN_ON(z3fold_page_trylock(zhdr)); else z3fold_page_lock(zhdr); - if (test_bit(PAGE_STALE, &page->private) || - !test_and_clear_bit(NEEDS_COMPACTING, &page->private)) { + if (WARN_ON(!test_and_clear_bit(NEEDS_COMPACTING, &page->private))) { z3fold_page_unlock(zhdr); return; } @@ -413,6 +412,11 @@ static void do_compact_page(struct z3fol list_del_init(&zhdr->buddy); spin_unlock(&pool->lock); + if (kref_put(&zhdr->refcount, release_z3fold_page_locked)) { + atomic64_dec(&pool->pages_nr); + return; + } + z3fold_compact_page(zhdr); unbuddied = get_cpu_ptr(pool->unbuddied); fchunks = num_free_chunks(zhdr); @@ -753,9 +757,11 @@ static void z3fold_free(struct z3fold_po list_del_init(&zhdr->buddy); spin_unlock(&pool->lock); zhdr->cpu = -1; + kref_get(&zhdr->refcount); do_compact_page(zhdr, true); return; } + kref_get(&zhdr->refcount); queue_work_on(zhdr->cpu, pool->compact_wq, &zhdr->work); z3fold_page_unlock(zhdr); } _ Patches currently in -mm which might be from vitalywool(a)gmail.com are

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] [PATCH 4.9 00/72] 4.9.64-stable review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.9.64 release. There are 72 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Tue Nov 21 14:35:13 UTC 2017. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.64-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.9.64-rc1 Johan Hovold <johan(a)kernel.org> staging: greybus: spilib: fix use-after-free after deregistration Rafał Miłecki <rafal(a)milecki.pl> brcmfmac: don't preset all channels as disabled Yazen Ghannam <yazen.ghannam(a)amd.com> x86/MCE/AMD: Always give panic severity for UC errors in kernel context Johan Hovold <johan(a)kernel.org> USB: serial: garmin_gps: fix memory leak on probe errors Johan Hovold <johan(a)kernel.org> USB: serial: garmin_gps: fix I/O after failed probe and remove Douglas Fischer <douglas.fischer(a)outlook.com> USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update Andrew Gabbasov <andrew_gabbasov(a)mentor.com> usb: gadget: f_fs: Fix use-after-free in ffs_free_inst Bernhard Rosenkraenzer <bernhard.rosenkranzer(a)linaro.org> USB: Add delay-init quirk for Corsair K70 LUX keyboards Alan Stern <stern(a)rowland.harvard.edu> USB: usbfs: compute urb->actual_length for isochronous Eric Biggers <ebiggers(a)google.com> crypto: dh - Don't permit 'key' or 'g' size longer than 'p' Eric Biggers <ebiggers(a)google.com> crypto: dh - Don't permit 'p' to be 0 Sasha Levin <alexander.levin(a)verizon.com> Revert "dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification" Sasha Levin <alexander.levin(a)verizon.com> Revert "dt-bindings: Add vendor prefix for LEGO" Dmitry V. Levin <ldv(a)altlinux.org> uapi: fix linux/rds.h userspace compilation errors Dmitry V. Levin <ldv(a)altlinux.org> uapi: fix linux/rds.h userspace compilation error Sasha Levin <alexander.levin(a)verizon.com> Revert "uapi: fix linux/rds.h userspace compilation errors" Sasha Levin <alexander.levin(a)verizon.com> Revert "crypto: xts - Add ECB dependency" Paul Burton <paul.burton(a)imgtec.com> MIPS: Netlogic: Exclude netlogic,xlp-pic code from XLR builds Paul Burton <paul.burton(a)imgtec.com> MIPS: traps: Ensure L1 & L2 ECC checking match for CM3 systems Marcin Nowakowski <marcin.nowakowski(a)imgtec.com> MIPS: init: Ensure reserved memory regions are not added to bootmem Marcin Nowakowski <marcin.nowakowski(a)imgtec.com> MIPS: init: Ensure bootmem does not corrupt reserved memory Paul Burton <paul.burton(a)imgtec.com> MIPS: End asm function prologue macros with .insn Jason Hrycay <jhrycay(a)gmail.com> staging: greybus: add host device function pointer checks Mike Kofron <mpkofron(a)gmail.com> staging: wilc1000: Fix endian sparse warning Jannik Becher <becher.jannik(a)gmail.com> staging: rtl8712: fixed little endian problem Emil Tantilov <emil.s.tantilov(a)intel.com> ixgbe: do not disable FEC from the driver Emil Tantilov <emil.s.tantilov(a)intel.com> ixgbe: add mask for 64 RSS queues Tony Nguyen <anthony.l.nguyen(a)intel.com> ixgbe: Reduce I2C retry count on X550 devices Tony Nguyen <anthony.l.nguyen(a)intel.com> ixgbe: Fix reporting of 100Mb capability Emil Tantilov <emil.s.tantilov(a)intel.com> ixgbe: handle close/suspend race with netif_device_detach/present Emil Tantilov <emil.s.tantilov(a)intel.com> ixgbe: fix AER error handling Don Skidmore <donald.c.skidmore(a)intel.com> ixgbe: Configure advertised speeds correctly for KR/KX backplane Jon Mason <jon.mason(a)broadcom.com> arm64: dts: NS2: reserve memory for Nitro firmware Kailang Yang <kailang(a)realtek.com> ALSA: hda/realtek - Add new codec ID ALC299 Arvind Yadav <arvind.yadav.cs(a)gmail.com> gpu: drm: mgag200: mgag200_main:- Handle error from pci_iomap Alexey Khoroshilov <khoroshilov(a)ispras.ru> backlight: adp5520: Fix error handling in adp5520_bl_probe() Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> backlight: lcd: Fix race condition during register Jarkko Nikula <jarkko.nikula(a)bitmer.com> drm/omap: panel-sony-acx565akm.c: Add MODULE_ALIAS Takashi Iwai <tiwai(a)suse.de> ALSA: vx: Fix possible transfer overflow Takashi Iwai <tiwai(a)suse.de> ALSA: vx: Don't try to update capture stream before running Hans de Goede <hdegoede(a)redhat.com> power: supply: axp288_fuel_gauge: Read 12 bit values 2 registers at a time Hans de Goede <hdegoede(a)redhat.com> power: supply: axp288_fuel_gauge: Read 15 bit values 2 registers at a time Fabien Lahoudere <fabien.lahoudere(a)collabora.co.uk> rtc: rx8010: change lock mechanism James Smart <james.smart(a)broadcom.com> scsi: lpfc: Clear the VendorVersion in the PLOGI/PLOGI ACC payload James Smart <james.smart(a)broadcom.com> scsi: lpfc: Correct issue leading to oops during link reset James Smart <james.smart(a)broadcom.com> scsi: lpfc: Correct host name in symbolic_name field James Smart <james.smart(a)broadcom.com> scsi: lpfc: FCoE VPort enable-disable does not bring up the VPort James Smart <james.smart(a)broadcom.com> scsi: lpfc: Add missing memory barrier Daniel Bristot de Oliveira <bristot(a)redhat.com> x86/irq, trace: Add __irq_entry annotation to x86's platform IRQ handlers Galo Navarro <anglorvaroa(a)gmail.com> staging: rtl8188eu: fix incorrect ERROR tags from logs Soheil Hassas Yeganeh <soheil(a)google.com> tcp: provide timestamps for partial writes subhashj(a)codeaurora.org <subhashj(a)codeaurora.org> scsi: ufs: add capability to keep auto bkops always enabled Javier Martinez Canillas <javier(a)osg.samsung.com> scsi: ufs-qcom: Fix module autoload Hannu Lounento <hannu.lounento(a)ge.com> igb: Fix hw_dbg logging in igb_update_flash_i210 Todd Fujinaka <todd.fujinaka(a)intel.com> igb: close/suspend race in netif_device_detach Aaron Sierra <asierra(a)xes-inc.com> igb: reset the PHY before reading the PHY ID Arvind Yadav <arvind.yadav.cs(a)gmail.com> drm/sti: sti_vtg: Handle return NULL error from devm_ioremap_nocache Geert Uytterhoeven <geert(a)linux-m68k.org> ata: SATA_MV should depend on HAS_DMA Geert Uytterhoeven <geert(a)linux-m68k.org> ata: SATA_HIGHBANK should depend on HAS_DMA Geert Uytterhoeven <geert(a)linux-m68k.org> ata: ATA_BMDMA should depend on HAS_DMA Tony Lindgren <tony(a)atomide.com> ARM: dts: omap5-uevm: Allow bootloader to configure USB Ethernet MAC Tony Lindgren <tony(a)atomide.com> ARM: dts: Fix omap3 off mode pull defines Tony Lindgren <tony(a)atomide.com> ARM: OMAP2+: Fix init for multiple quirks for the same SoC Tony Lindgren <tony(a)atomide.com> ARM: dts: Fix am335x and dm814x scm syscon to probe children Tony Lindgren <tony(a)atomide.com> ARM: dts: Fix compatible for ti81xx uarts for 8250 Ngai-Mint Kwan <ngai-mint.kwan(a)intel.com> fm10k: request reset when mbx->state changes Roger Quadros <rogerq(a)ti.com> extcon: palmas: Check the parent instance to prevent the NULL Chanwoo Choi <cw00.choi(a)samsung.com> extcon: Remove potential problem when calling extcon_register_notifier() Leif Liddy <leif.linux(a)gmail.com> Bluetooth: btusb: fix QCA Rome suspend/resume Eric Biggers <ebiggers(a)google.com> arm: crypto: reduce priority of bit-sliced AES cipher Andrey Konovalov <andreyknvl(a)google.com> media: dib0700: fix invalid dvb_detach argument Arvind Yadav <arvind.yadav.cs(a)gmail.com> media: imon: Fix null-ptr-deref in imon_probe ------------- Diffstat: Documentation/devicetree/bindings/arm/davinci.txt | 4 - .../devicetree/bindings/vendor-prefixes.txt | 1 - Makefile | 4 +- arch/arm/boot/dts/am33xx.dtsi | 3 +- arch/arm/boot/dts/dm814x.dtsi | 9 +- arch/arm/boot/dts/dm816x.dtsi | 6 +- arch/arm/boot/dts/omap5-uevm.dts | 21 +++++ arch/arm/crypto/aesbs-glue.c | 6 +- arch/arm/mach-omap2/pdata-quirks.c | 1 - arch/arm64/boot/dts/broadcom/ns2.dtsi | 2 + arch/mips/include/asm/asm.h | 10 +- arch/mips/include/asm/mips-cm.h | 7 ++ arch/mips/kernel/setup.c | 78 +++++++++++++++- arch/mips/kernel/traps.c | 63 ++++++++++++- arch/mips/netlogic/common/irq.c | 4 +- arch/x86/kernel/apic/apic.c | 8 +- arch/x86/kernel/apic/vector.c | 2 +- arch/x86/kernel/cpu/mcheck/mce-severity.c | 7 +- arch/x86/kernel/cpu/mcheck/mce_amd.c | 4 +- arch/x86/kernel/cpu/mcheck/therm_throt.c | 6 +- arch/x86/kernel/cpu/mcheck/threshold.c | 4 +- arch/x86/kernel/irq.c | 4 +- arch/x86/kernel/irq_work.c | 5 +- arch/x86/kernel/smp.c | 15 +-- crypto/Kconfig | 1 - crypto/dh_helper.c | 16 ++++ drivers/ata/Kconfig | 3 + drivers/bluetooth/btusb.c | 6 ++ drivers/extcon/extcon-palmas.c | 5 + drivers/extcon/extcon.c | 33 ++----- drivers/gpu/drm/mgag200/mgag200_main.c | 2 + .../drm/omapdrm/displays/panel-sony-acx565akm.c | 1 + drivers/gpu/drm/sti/sti_vtg.c | 4 + drivers/media/rc/imon.c | 5 + drivers/media/usb/dvb-usb/dib0700_devices.c | 24 ++--- drivers/net/ethernet/intel/fm10k/fm10k_mbx.c | 10 +- drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 6 +- drivers/net/ethernet/intel/igb/e1000_82575.c | 11 +++ drivers/net/ethernet/intel/igb/e1000_i210.c | 4 +- drivers/net/ethernet/intel/igb/igb_main.c | 21 +++-- drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 2 +- drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 8 +- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 23 ++--- drivers/net/ethernet/intel/ixgbe/ixgbe_phy.c | 4 +- drivers/net/ethernet/intel/ixgbe/ixgbe_x550.c | 7 +- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 2 - drivers/power/supply/axp288_fuel_gauge.c | 103 +++++++++++---------- drivers/rtc/rtc-rx8010.c | 24 +---- drivers/scsi/lpfc/lpfc_attr.c | 17 ++++ drivers/scsi/lpfc/lpfc_els.c | 6 ++ drivers/scsi/lpfc/lpfc_hw.h | 6 ++ drivers/scsi/lpfc/lpfc_sli.c | 3 + drivers/scsi/lpfc/lpfc_vport.c | 8 ++ drivers/scsi/ufs/ufs-qcom.c | 1 + drivers/scsi/ufs/ufshcd.c | 33 ++++--- drivers/scsi/ufs/ufshcd.h | 13 +++ drivers/staging/greybus/connection.c | 6 ++ drivers/staging/greybus/spilib.c | 8 +- drivers/staging/rtl8188eu/include/rtw_debug.h | 2 +- drivers/staging/rtl8712/rtl871x_ioctl_linux.c | 2 +- drivers/staging/wilc1000/linux_wlan.c | 2 +- drivers/usb/core/devio.c | 14 +++ drivers/usb/core/quirks.c | 3 + drivers/usb/gadget/function/f_fs.c | 1 + drivers/usb/serial/garmin_gps.c | 22 ++++- drivers/usb/serial/qcserial.c | 1 + drivers/video/backlight/adp5520_bl.c | 12 ++- drivers/video/backlight/lcd.c | 4 +- include/dt-bindings/pinctrl/omap.h | 4 +- include/uapi/linux/rds.h | 102 ++++++++++---------- net/ipv4/tcp.c | 18 ++-- sound/drivers/vx/vx_pcm.c | 8 +- sound/pci/hda/patch_realtek.c | 10 ++ sound/pci/vx222/vx222_ops.c | 12 +-- sound/pcmcia/vx/vxp_ops.c | 12 +-- 75 files changed, 630 insertions(+), 299 deletions(-)

7 years, 11 months

4
74
0 0

[Linux-stable-mirror] [PATCH 3.18 00/38] 3.18.83-stable review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.18.83 release. There are 38 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Tue Nov 21 14:29:00 UTC 2017. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.83-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-3.18.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 3.18.83-rc1 Johan Hovold <johan(a)kernel.org> USB: serial: garmin_gps: fix memory leak on probe errors Johan Hovold <johan(a)kernel.org> USB: serial: garmin_gps: fix I/O after failed probe and remove Johan Hovold <johan(a)kernel.org> USB: serial: garmin_gps: fix memory leak on failed URB submit Douglas Fischer <douglas.fischer(a)outlook.com> USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update Bernhard Rosenkraenzer <bernhard.rosenkranzer(a)linaro.org> USB: Add delay-init quirk for Corsair K70 LUX keyboards Alan Stern <stern(a)rowland.harvard.edu> USB: usbfs: compute urb->actual_length for isochronous Dmitry V. Levin <ldv(a)altlinux.org> uapi: fix linux/rds.h userspace compilation errors Dmitry V. Levin <ldv(a)altlinux.org> uapi: fix linux/rds.h userspace compilation error Sasha Levin <alexander.levin(a)verizon.com> Revert "uapi: fix linux/rds.h userspace compilation errors" Sasha Levin <alexander.levin(a)verizon.com> Revert "crypto: xts - Add ECB dependency" Paul Burton <paul.burton(a)imgtec.com> MIPS: Netlogic: Exclude netlogic,xlp-pic code from XLR builds Marcin Nowakowski <marcin.nowakowski(a)imgtec.com> MIPS: init: Ensure reserved memory regions are not added to bootmem Paul Burton <paul.burton(a)imgtec.com> MIPS: End asm function prologue macros with .insn Emil Tantilov <emil.s.tantilov(a)intel.com> ixgbe: handle close/suspend race with netif_device_detach/present Emil Tantilov <emil.s.tantilov(a)intel.com> ixgbe: fix AER error handling Arvind Yadav <arvind.yadav.cs(a)gmail.com> gpu: drm: mgag200: mgag200_main:- Handle error from pci_iomap Alexey Khoroshilov <khoroshilov(a)ispras.ru> backlight: adp5520: Fix error handling in adp5520_bl_probe() Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> backlight: lcd: Fix race condition during register Takashi Iwai <tiwai(a)suse.de> ALSA: vx: Fix possible transfer overflow Takashi Iwai <tiwai(a)suse.de> ALSA: vx: Don't try to update capture stream before running James Smart <james.smart(a)broadcom.com> scsi: lpfc: Correct issue leading to oops during link reset James Smart <james.smart(a)broadcom.com> scsi: lpfc: Correct host name in symbolic_name field James Smart <james.smart(a)broadcom.com> scsi: lpfc: FCoE VPort enable-disable does not bring up the VPort James Smart <james.smart(a)broadcom.com> scsi: lpfc: Add missing memory barrier Galo Navarro <anglorvaroa(a)gmail.com> staging: rtl8188eu: fix incorrect ERROR tags from logs Hannu Lounento <hannu.lounento(a)ge.com> igb: Fix hw_dbg logging in igb_update_flash_i210 Todd Fujinaka <todd.fujinaka(a)intel.com> igb: close/suspend race in netif_device_detach Aaron Sierra <asierra(a)xes-inc.com> igb: reset the PHY before reading the PHY ID Arvind Yadav <arvind.yadav.cs(a)gmail.com> drm/sti: sti_vtg: Handle return NULL error from devm_ioremap_nocache Geert Uytterhoeven <geert(a)linux-m68k.org> ata: SATA_MV should depend on HAS_DMA Geert Uytterhoeven <geert(a)linux-m68k.org> ata: SATA_HIGHBANK should depend on HAS_DMA Geert Uytterhoeven <geert(a)linux-m68k.org> ata: ATA_BMDMA should depend on HAS_DMA Tony Lindgren <tony(a)atomide.com> ARM: dts: Fix omap3 off mode pull defines Tony Lindgren <tony(a)atomide.com> ARM: OMAP2+: Fix init for multiple quirks for the same SoC Roger Quadros <rogerq(a)ti.com> extcon: palmas: Check the parent instance to prevent the NULL Nicholas Bellinger <nab(a)linux-iscsi.org> iscsi-target: Fix iscsi_np reset hung task during parallel delete Andrey Konovalov <andreyknvl(a)google.com> media: dib0700: fix invalid dvb_detach argument Arvind Yadav <arvind.yadav.cs(a)gmail.com> media: imon: Fix null-ptr-deref in imon_probe ------------- Diffstat: Makefile | 4 +- arch/arm/mach-omap2/pdata-quirks.c | 1 - arch/mips/include/asm/asm.h | 10 ++- arch/mips/kernel/setup.c | 4 + arch/mips/netlogic/common/irq.c | 4 +- crypto/Kconfig | 1 - drivers/ata/Kconfig | 3 + drivers/extcon/extcon-palmas.c | 5 ++ drivers/gpu/drm/mgag200/mgag200_main.c | 2 + drivers/gpu/drm/sti/sti_vtg.c | 4 + drivers/media/rc/imon.c | 5 ++ drivers/media/usb/dvb-usb/dib0700_devices.c | 24 +++--- drivers/net/ethernet/intel/igb/e1000_82575.c | 11 +++ drivers/net/ethernet/intel/igb/e1000_i210.c | 4 +- drivers/net/ethernet/intel/igb/igb_main.c | 21 +++--- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 23 +++--- drivers/scsi/lpfc/lpfc_attr.c | 17 +++++ drivers/scsi/lpfc/lpfc_sli.c | 3 + drivers/scsi/lpfc/lpfc_vport.c | 8 ++ drivers/staging/rtl8188eu/include/rtw_debug.h | 2 +- drivers/target/iscsi/iscsi_target.c | 1 + drivers/target/iscsi/iscsi_target_core.h | 1 + drivers/target/iscsi/iscsi_target_login.c | 7 +- drivers/usb/core/devio.c | 14 ++++ drivers/usb/core/quirks.c | 3 + drivers/usb/serial/garmin_gps.c | 23 +++++- drivers/usb/serial/qcserial.c | 1 + drivers/video/backlight/adp5520_bl.c | 12 ++- drivers/video/backlight/lcd.c | 4 +- include/dt-bindings/pinctrl/omap.h | 4 +- include/target/iscsi/iscsi_target_core.h | 1 + include/uapi/linux/rds.h | 102 +++++++++++++------------- sound/drivers/vx/vx_pcm.c | 8 +- sound/pci/vx222/vx222_ops.c | 12 +-- sound/pcmcia/vx/vxp_ops.c | 12 +-- 35 files changed, 239 insertions(+), 122 deletions(-)

7 years, 11 months

3
42
0 0

[Linux-stable-mirror] [PATCH] Sparc

by David Miller

Please queue up the following bug fix for 4.14.x -stable. Thank you.

7 years, 11 months

2
1
0 0

[Linux-stable-mirror] Patch "sparc64: Fix page table walk for PUD hugepages" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sparc64: Fix page table walk for PUD hugepages to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: 0001-sparc64-Fix-page-table-walk-for-PUD-hugepages.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fac33aa62841b69cd0e19a29b0e2ac96e4e8cf32 Mon Sep 17 00:00:00 2001 From: Nitin Gupta <nitin.m.gupta(a)oracle.com> Date: Fri, 3 Nov 2017 12:26:06 -0700 Subject: sparc64: Fix page table walk for PUD hugepages From: Nitin Gupta <nitin.m.gupta(a)oracle.com> [ Upstream commit 70f3c8b7c2e7ebcdde8354da004872e7c9184e97 ] For a PUD hugepage entry, we need to propagate bits [32:22] from virtual address to resolve at 4M granularity. However, the current code was incorrectly propagating bits [29:19]. This bug can cause incorrect data to be returned for pages backed with 16G hugepages. Signed-off-by: Nitin Gupta <nitin.m.gupta(a)oracle.com> Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk> Cc: Al Viro <viro(a)ZenIV.linux.org.uk> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/sparc/include/asm/tsb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/sparc/include/asm/tsb.h b/arch/sparc/include/asm/tsb.h index 25b6abdb3908..522a677e050d 100644 --- a/arch/sparc/include/asm/tsb.h +++ b/arch/sparc/include/asm/tsb.h @@ -217,7 +217,7 @@ extern struct tsb_phys_patch_entry __tsb_phys_patch, __tsb_phys_patch_end; sllx REG2, 32, REG2; \ andcc REG1, REG2, %g0; \ be,pt %xcc, 700f; \ - sethi %hi(0x1ffc0000), REG2; \ + sethi %hi(0xffe00000), REG2; \ sllx REG2, 1, REG2; \ brgez,pn REG1, FAIL_LABEL; \ andn REG1, REG2, REG1; \ -- 2.13.6 Patches currently in stable-queue which might be from nitin.m.gupta(a)oracle.com are queue-4.14/0001-sparc64-Fix-page-table-walk-for-PUD-hugepages.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] [PATCH for 4.4-stable] KVM: x86: fix singlestepping over syscall

by Paolo Bonzini

[ Upstream commit c8401dda2f0a00cd25c0af6a95ed50e478d25de4 ] TF is handled a bit differently for syscall and sysret, compared to the other instructions: TF is checked after the instruction completes, so that the OS can disable #DB at a syscall by adding TF to FMASK. When the sysret is executed the #DB is taken "as if" the syscall insn just completed. KVM emulates syscall so that it can trap 32-bit syscall on Intel processors. Fix the behavior, otherwise you could get #DB on a user stack which is not nice. This does not affect Linux guests, as they use an IST or task gate for #DB. This fixes CVE-2017-7518. Cc: stable(a)vger.kernel.org Reported-by: Andy Lutomirski <luto(a)kernel.org> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com> Conflicts: arch/x86/kvm/x86.c --- arch/x86/include/asm/kvm_emulate.h | 1 + arch/x86/kvm/emulate.c | 1 + arch/x86/kvm/x86.c | 52 ++++++++++++++++---------------------- 3 files changed, 24 insertions(+), 30 deletions(-) diff --git a/arch/x86/include/asm/kvm_emulate.h b/arch/x86/include/asm/kvm_emulate.h index 19d14ac23ef9..fc3c7e49c8e4 100644 --- a/arch/x86/include/asm/kvm_emulate.h +++ b/arch/x86/include/asm/kvm_emulate.h @@ -296,6 +296,7 @@ struct x86_emulate_ctxt { bool perm_ok; /* do not check permissions if true */ bool ud; /* inject an #UD if host doesn't support insn */ + bool tf; /* TF value before instruction (after for syscall/sysret) */ bool have_exception; struct x86_exception exception; diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c index 04b2f3cad7ba..684edebb4a0c 100644 --- a/arch/x86/kvm/emulate.c +++ b/arch/x86/kvm/emulate.c @@ -2726,6 +2726,7 @@ static int em_syscall(struct x86_emulate_ctxt *ctxt) ctxt->eflags &= ~(X86_EFLAGS_VM | X86_EFLAGS_IF); } + ctxt->tf = (ctxt->eflags & X86_EFLAGS_TF) != 0; return X86EMUL_CONTINUE; } diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 8e526c6fd784..3ffd5900da5b 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -5095,6 +5095,8 @@ static void init_emulate_ctxt(struct kvm_vcpu *vcpu) kvm_x86_ops->get_cs_db_l_bits(vcpu, &cs_db, &cs_l); ctxt->eflags = kvm_get_rflags(vcpu); + ctxt->tf = (ctxt->eflags & X86_EFLAGS_TF) != 0; + ctxt->eip = kvm_rip_read(vcpu); ctxt->mode = (!is_protmode(vcpu)) ? X86EMUL_MODE_REAL : (ctxt->eflags & X86_EFLAGS_VM) ? X86EMUL_MODE_VM86 : @@ -5315,37 +5317,26 @@ static int kvm_vcpu_check_hw_bp(unsigned long addr, u32 type, u32 dr7, return dr6; } -static void kvm_vcpu_check_singlestep(struct kvm_vcpu *vcpu, unsigned long rflags, int *r) +static void kvm_vcpu_do_singlestep(struct kvm_vcpu *vcpu, int *r) { struct kvm_run *kvm_run = vcpu->run; - /* - * rflags is the old, "raw" value of the flags. The new value has - * not been saved yet. - * - * This is correct even for TF set by the guest, because "the - * processor will not generate this exception after the instruction - * that sets the TF flag". - */ - if (unlikely(rflags & X86_EFLAGS_TF)) { - if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) { - kvm_run->debug.arch.dr6 = DR6_BS | DR6_FIXED_1 | - DR6_RTM; - kvm_run->debug.arch.pc = vcpu->arch.singlestep_rip; - kvm_run->debug.arch.exception = DB_VECTOR; - kvm_run->exit_reason = KVM_EXIT_DEBUG; - *r = EMULATE_USER_EXIT; - } else { - vcpu->arch.emulate_ctxt.eflags &= ~X86_EFLAGS_TF; - /* - * "Certain debug exceptions may clear bit 0-3. The - * remaining contents of the DR6 register are never - * cleared by the processor". - */ - vcpu->arch.dr6 &= ~15; - vcpu->arch.dr6 |= DR6_BS | DR6_RTM; - kvm_queue_exception(vcpu, DB_VECTOR); - } + if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP) { + kvm_run->debug.arch.dr6 = DR6_BS | DR6_FIXED_1 | DR6_RTM; + kvm_run->debug.arch.pc = vcpu->arch.singlestep_rip; + kvm_run->debug.arch.exception = DB_VECTOR; + kvm_run->exit_reason = KVM_EXIT_DEBUG; + *r = EMULATE_USER_EXIT; + } else { + vcpu->arch.emulate_ctxt.eflags &= ~X86_EFLAGS_TF; + /* + * "Certain debug exceptions may clear bit 0-3. The + * remaining contents of the DR6 register are never + * cleared by the processor". + */ + vcpu->arch.dr6 &= ~15; + vcpu->arch.dr6 |= DR6_BS | DR6_RTM; + kvm_queue_exception(vcpu, DB_VECTOR); } } @@ -5500,8 +5491,9 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, toggle_interruptibility(vcpu, ctxt->interruptibility); vcpu->arch.emulate_regs_need_sync_to_vcpu = false; kvm_rip_write(vcpu, ctxt->eip); - if (r == EMULATE_DONE) - kvm_vcpu_check_singlestep(vcpu, rflags, &r); + if (r == EMULATE_DONE && + (ctxt->tf || (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP))) + kvm_vcpu_do_singlestep(vcpu, &r); if (!ctxt->have_exception || exception_type(ctxt->exception.vector) == EXCPT_TRAP) __kvm_set_rflags(vcpu, ctxt->eflags); -- 1.8.3.1

7 years, 11 months

2
2
0 0

[Linux-stable-mirror] [PATCH] wcn36xx: fix iris child-node lookup

by Johan Hovold

Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent mmio node was also prematurely freed. Fixes: fd52bdae9ab0 ("wcn36xx: Disable 5GHz for wcn3620") Cc: stable <stable(a)vger.kernel.org> # 4.14 Cc: Loic Poulain <loic.poulain(a)linaro.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/net/wireless/ath/wcn36xx/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/wcn36xx/main.c b/drivers/net/wireless/ath/wcn36xx/main.c index 71812a2dd513..f7d228b5ba93 100644 --- a/drivers/net/wireless/ath/wcn36xx/main.c +++ b/drivers/net/wireless/ath/wcn36xx/main.c @@ -1233,7 +1233,7 @@ static int wcn36xx_platform_get_resources(struct wcn36xx *wcn, } /* External RF module */ - iris_node = of_find_node_by_name(mmio_node, "iris"); + iris_node = of_get_child_by_name(mmio_node, "iris"); if (iris_node) { if (of_device_is_compatible(iris_node, "qcom,wcn3620")) wcn->rf_id = RF_IRIS_WCN3620; -- 2.15.0

7 years, 11 months

2
3
0 0

Re: [Linux-stable-mirror] Linux 3.10.108 (EOL)

by Sebastian Gottschall

Am 05.11.2017 um 08:46 schrieb Willy Tarreau: > On Sun, Nov 05, 2017 at 06:59:48AM +0000, Harsh Shandilya wrote: >> Is this not pushed yet? I only see 3.10.107 > Now it is there. Please avoid to rely on it for too long and quickly > upgrade to 4.4 or any other maintained version that suits your needs. > > Willy > even if EOL has to come once for sure, its the last kernel which can be used on certain devices (embedded) since the kernel is growing bigger and bigger and wont run good anymore with limited resource Sebastian -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottschall(a)dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565

7 years, 11 months

4
9
0 0

[Linux-stable-mirror] Patch "sparc64: mmu_context: Add missing include files" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sparc64: mmu_context: Add missing include files to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sparc64-mmu_context-add-missing-include-files.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 01c3f0a42a2a0ff0c3fed80a1a25f2641ae72554 Mon Sep 17 00:00:00 2001 From: Guenter Roeck <linux(a)roeck-us.net> Date: Sun, 10 Sep 2017 13:44:47 -0700 Subject: sparc64: mmu_context: Add missing include files From: Guenter Roeck <linux(a)roeck-us.net> commit 01c3f0a42a2a0ff0c3fed80a1a25f2641ae72554 upstream. Fix the following build errors. In file included from arch/sparc/include/asm/mmu_context.h:4:0, from include/linux/mmu_context.h:4, from drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h:29, from drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c:23: arch/sparc/include/asm/mmu_context_64.h:22:37: error: unknown type name 'per_cpu_secondary_mm' arch/sparc/include/asm/mmu_context_64.h: In function 'switch_mm': arch/sparc/include/asm/mmu_context_64.h:79:2: error: implicit declaration of function 'smp_processor_id' Fixes: 70539bd79500 ("drm/amd: Update MEC HQD loading code for KFD") Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> Acked-by: Oded Gabbay <oded.gabbay(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/sparc/include/asm/mmu_context_64.h | 2 ++ 1 file changed, 2 insertions(+) --- a/arch/sparc/include/asm/mmu_context_64.h +++ b/arch/sparc/include/asm/mmu_context_64.h @@ -8,9 +8,11 @@ #include <linux/spinlock.h> #include <linux/mm_types.h> +#include <linux/smp.h> #include <asm/spitfire.h> #include <asm-generic/mm_hooks.h> +#include <asm/percpu.h> static inline void enter_lazy_tlb(struct mm_struct *mm, struct task_struct *tsk) { Patches currently in stable-queue which might be from linux(a)roeck-us.net are queue-4.14/sparc64-mmu_context-add-missing-include-files.patch queue-4.14/sparc32-add-cmpxchg64.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "sparc32: Add cmpxchg64()." has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled sparc32: Add cmpxchg64(). to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: sparc32-add-cmpxchg64.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 23198ddffb6cddb5d5824230af4dd4b46e4046a4 Mon Sep 17 00:00:00 2001 From: "David S. Miller" <davem(a)davemloft.net> Date: Wed, 27 Sep 2017 22:38:19 -0700 Subject: sparc32: Add cmpxchg64(). From: David S. Miller <davem(a)davemloft.net> commit 23198ddffb6cddb5d5824230af4dd4b46e4046a4 upstream. This fixes the build with i40e driver enabled. Reported-by: Guenter Roeck <linux(a)roeck-us.net> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/sparc/include/asm/cmpxchg_32.h | 3 +++ arch/sparc/lib/atomic32.c | 14 ++++++++++++++ 2 files changed, 17 insertions(+) --- a/arch/sparc/include/asm/cmpxchg_32.h +++ b/arch/sparc/include/asm/cmpxchg_32.h @@ -63,6 +63,9 @@ __cmpxchg(volatile void *ptr, unsigned l (unsigned long)_n_, sizeof(*(ptr))); \ }) +u64 __cmpxchg_u64(u64 *ptr, u64 old, u64 new); +#define cmpxchg64(ptr, old, new) __cmpxchg_u64(ptr, old, new) + #include <asm-generic/cmpxchg-local.h> /* --- a/arch/sparc/lib/atomic32.c +++ b/arch/sparc/lib/atomic32.c @@ -173,6 +173,20 @@ unsigned long __cmpxchg_u32(volatile u32 } EXPORT_SYMBOL(__cmpxchg_u32); +u64 __cmpxchg_u64(u64 *ptr, u64 old, u64 new) +{ + unsigned long flags; + u64 prev; + + spin_lock_irqsave(ATOMIC_HASH(ptr), flags); + if ((prev = *ptr) == old) + *ptr = new; + spin_unlock_irqrestore(ATOMIC_HASH(ptr), flags); + + return prev; +} +EXPORT_SYMBOL(__cmpxchg_u64); + unsigned long __xchg_u32(volatile u32 *ptr, u32 new) { unsigned long flags; Patches currently in stable-queue which might be from davem(a)davemloft.net are queue-4.14/sparc64-mmu_context-add-missing-include-files.patch queue-4.14/sparc32-add-cmpxchg64.patch

7 years, 11 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] net: mvneta: fix handling of the Tx descriptor counter

by David Laight

From: Simon Guinot > Sent: 13 November 2017 15:36 > To: David Miller > Cc: thomas.petazzoni(a)free-electrons.com; netdev(a)vger.kernel.org; musv(a)gmx.de; > andreas.tobler(a)cloudguard.ch; gregory.clement(a)free-electrons.com; antoine.tenart(a)free-electrons.com; > mw(a)semihalf.com; stable(a)vger.kernel.org > Subject: Re: [PATCH] net: mvneta: fix handling of the Tx descriptor counter > > On Mon, Nov 13, 2017 at 11:54:14PM +0900, David Miller wrote: > > From: Simon Guinot <simon.guinot(a)sequanux.org> > > Date: Mon, 13 Nov 2017 15:51:15 +0100 > > > > > IIUC the driver stops the queue if a threshold of 316 Tx descriptors is > > > reached (default and worst value). > > > > That's a lot of latency. > > OK, then I'll keep the "tx_pending > 255" flushing condition. But note > there is no other software mechanism to limit the Tx latency inside the > mvneta driver. Should we add something ? And is that not rather the job > of the network stack to keep track of the latency and to limit the txq > size ? This is 'first packet transmit latency'. If the 'doorbell write' is just a PCIe write then, on most systems, that is cheap and pipelined/posted. I'd almost be surprised if you see any 'improvement' from not doing it every packet. The overall tx queue size is a different issue - usually needs limiting by BQL if TSO is done. David

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Fwd: stable-rc/linux-4.4.y build: 182 builds: 60 failed, 122 passed, 60 errors, 60 warnings (v4.4.99-60-g803704b287d8)

by Arnd Bergmann

[Adding the others to cc] ---------- Forwarded message ---------- From: Arnd Bergmann <arnd(a)arndb.de> Date: Sun, Nov 19, 2017 at 9:53 PM Subject: Re: stable-rc/linux-4.4.y build: 182 builds: 60 failed, 122 passed, 60 errors, 60 warnings (v4.4.99-60-g803704b287d8) To: "kernelci.org bot" <bot(a)kernelci.org>, gregkh <gregkh(a)linuxfoundation.org> Cc: Tom Gall <tom.gall(a)linaro.org>, Sumit Semwal <sumit.semwal(a)linaro.org>, Amit Pundir <amit.pundir(a)linaro.org>, Arnd Bergmann <arnd.bergmann(a)linaro.org>, Anmar Oueja <anmar.oueja(a)linaro.org> On Sun, Nov 19, 2017 at 5:35 PM, kernelci.org bot <bot(a)kernelci.org> wrote: > stable-rc/linux-4.4.y build: 182 builds: 60 failed, 122 passed, 60 errors, 60 warnings (v4.4.99-60-g803704b287d8) > > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.99-60-g… > > Tree: stable-rc > Branch: linux-4.4.y > Git Describe: v4.4.99-60-g803704b287d8 > Git Commit: 803704b287d89efcd70fade9e650176282a1d766 > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > Built: 4 unique architectures > > Build Failures Detected: > > mips: gcc version 6.3.0 (GCC) > > allnoconfig: FAIL > ar7_defconfig: FAIL > ath79_defconfig: FAIL > bcm47xx_defconfig: FAIL > ... > > Errors summary: > > 60 arch/mips/kernel/setup.c:439:8: error: implicit declaration of function 'PHYS_PFN' [-Werror=implicit-function-declaration] All mips builds failed with this error, apparently caused by the backport of d9b5b658210f2 ("MIPS: init: Ensure bootmem does not corrupt reserved memory"). Arnd

7 years, 11 months

3
2
0 0

[Linux-stable-mirror] Patch "mm: add PHYS_PFN, use it in __phys_to_pfn()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm: add PHYS_PFN, use it in __phys_to_pfn() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mm-add-phys_pfn-use-it-in-__phys_to_pfn.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8f235d1a3eb7198affe7cadf676a10afb8a46a1a Mon Sep 17 00:00:00 2001 From: Chen Gang <xili_gchen_5257(a)hotmail.com> Date: Thu, 14 Jan 2016 15:18:33 -0800 Subject: mm: add PHYS_PFN, use it in __phys_to_pfn() From: Chen Gang <xili_gchen_5257(a)hotmail.com> commit 8f235d1a3eb7198affe7cadf676a10afb8a46a1a upstream. __phys_to_pfn and __pfn_to_phys are symmetric, PHYS_PFN and PFN_PHYS are semmetric: - y = (phys_addr_t)x << PAGE_SHIFT - y >> PAGE_SHIFT = (phys_add_t)x - (unsigned long)(y >> PAGE_SHIFT) = x [akpm(a)linux-foundation.org: use macro arg name `x'] [arnd(a)arndb.de: include linux/pfn.h for PHYS_PFN definition] Signed-off-by: Chen Gang <gang.chen.5i5j(a)gmail.com> Cc: Oleg Nesterov <oleg(a)redhat.com> Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Marcin Nowakowski <marcin.nowakowski(a)mips.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/asm-generic/memory_model.h | 4 +++- include/linux/pfn.h | 1 + 2 files changed, 4 insertions(+), 1 deletion(-) --- a/include/asm-generic/memory_model.h +++ b/include/asm-generic/memory_model.h @@ -1,6 +1,8 @@ #ifndef __ASM_MEMORY_MODEL_H #define __ASM_MEMORY_MODEL_H +#include <linux/pfn.h> + #ifndef __ASSEMBLY__ #if defined(CONFIG_FLATMEM) @@ -72,7 +74,7 @@ /* * Convert a physical address to a Page Frame Number and back */ -#define __phys_to_pfn(paddr) ((unsigned long)((paddr) >> PAGE_SHIFT)) +#define __phys_to_pfn(paddr) PHYS_PFN(paddr) #define __pfn_to_phys(pfn) PFN_PHYS(pfn) #define page_to_pfn __page_to_pfn --- a/include/linux/pfn.h +++ b/include/linux/pfn.h @@ -9,5 +9,6 @@ #define PFN_UP(x) (((x) + PAGE_SIZE-1) >> PAGE_SHIFT) #define PFN_DOWN(x) ((x) >> PAGE_SHIFT) #define PFN_PHYS(x) ((phys_addr_t)(x) << PAGE_SHIFT) +#define PHYS_PFN(x) ((unsigned long)((x) >> PAGE_SHIFT)) #endif Patches currently in stable-queue which might be from xili_gchen_5257(a)hotmail.com are queue-4.4/mm-add-phys_pfn-use-it-in-__phys_to_pfn.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Security fixes for 4.4

by Ben Hutchings

Please apply the attached backported patches to 4.4-stable. The upstream commits are: 06bd3c36a733 ext4: fix data exposure after a crash c8401dda2f0a KVM: x86: fix singlestepping over syscall 0d0e57697f16 bpf: don't let ldimm64 leak map addresses on unprivileged 089bc0143f48 xen-blkback: don't leak stack data via response ring df80cd9b28b9 sctp: do not peel off an assoc from one netns to another one 2cb80187ba06 net: cdc_ether: fix divide by 0 on bad descriptors 7fd078337201 net: qmi_wwan: fix divide by 0 on bad descriptors The last three are not in later stable branches yet. The USB net driver fixes are already in David Miller's queue for stable, and i have asked him to add the sctp fix. Ben. -- Ben Hutchings Software Developer, Codethink Ltd.

7 years, 11 months

5
14
0 0

[Linux-stable-mirror] [PATCH v2 15/17] lpfc: Fix driver handling of nvme resources during unload

by James Smart

During driver unload, the driver may crash due to NULL pointers. The NULL pointers were due to the driver not protecting itself sufficiently during some of the teardown paths. Additionally, the driver was not waiting for and cleanup up nvme io resources. As such, the driver wasn't making the callbacks to the transport, stalling the transports association teardown. This patch waits for io clean up before tearding down and adds checks for possible NULL pointers. Cc: <stable(a)vger.kernel.org> # 4.12+ Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com> Signed-off-by: James Smart <james.smart(a)broadcom.com> --- drivers/scsi/lpfc/lpfc_crtn.h | 2 + drivers/scsi/lpfc/lpfc_init.c | 18 ++++++++ drivers/scsi/lpfc/lpfc_nvme.c | 96 ++++++++++++++++++++++++++++++++++++++----- 3 files changed, 105 insertions(+), 11 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_crtn.h b/drivers/scsi/lpfc/lpfc_crtn.h index 7e300734b345..dac33900bf17 100644 --- a/drivers/scsi/lpfc/lpfc_crtn.h +++ b/drivers/scsi/lpfc/lpfc_crtn.h @@ -254,6 +254,8 @@ void lpfc_nvmet_ctxbuf_post(struct lpfc_hba *phba, struct lpfc_nvmet_ctxbuf *ctxp); int lpfc_nvmet_rcv_unsol_abort(struct lpfc_vport *vport, struct fc_frame_header *fc_hdr); +void lpfc_sli_flush_nvme_rings(struct lpfc_hba *phba); +void lpfc_nvme_wait_for_io_drain(struct lpfc_hba *phba); void lpfc_sli4_build_dflt_fcf_record(struct lpfc_hba *, struct fcf_record *, uint16_t); int lpfc_sli4_rq_put(struct lpfc_queue *hq, struct lpfc_queue *dq, diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c index 7a06f23a3baf..c466ceb43bc9 100644 --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -10136,6 +10136,16 @@ lpfc_sli4_xri_exchange_busy_wait(struct lpfc_hba *phba) int fcp_xri_cmpl = 1; int els_xri_cmpl = list_empty(&phba->sli4_hba.lpfc_abts_els_sgl_list); + /* Driver just aborted IOs during the hba_unset process. Pause + * here to give the HBA time to complete the IO and get entries + * into the abts lists. + */ + msleep(LPFC_XRI_EXCH_BUSY_WAIT_T1 * 5); + + /* Wait for NVME pending IO to flush back to transport. */ + if (phba->cfg_enable_fc4_type & LPFC_ENABLE_NVME) + lpfc_nvme_wait_for_io_drain(phba); + if (phba->cfg_enable_fc4_type & LPFC_ENABLE_FCP) fcp_xri_cmpl = list_empty(&phba->sli4_hba.lpfc_abts_scsi_buf_list); @@ -11659,6 +11669,10 @@ lpfc_sli4_prep_dev_for_reset(struct lpfc_hba *phba) /* Flush all driver's outstanding SCSI I/Os as we are to reset */ lpfc_sli_flush_fcp_rings(phba); + /* Flush the outstanding NVME IOs if fc4 type enabled. */ + if (phba->cfg_enable_fc4_type & LPFC_ENABLE_NVME) + lpfc_sli_flush_nvme_rings(phba); + /* stop all timers */ lpfc_stop_hba_timers(phba); @@ -11690,6 +11704,10 @@ lpfc_sli4_prep_dev_for_perm_failure(struct lpfc_hba *phba) /* Clean up all driver's outstanding SCSI I/Os */ lpfc_sli_flush_fcp_rings(phba); + + /* Flush the outstanding NVME IOs if fc4 type enabled. */ + if (phba->cfg_enable_fc4_type & LPFC_ENABLE_NVME) + lpfc_sli_flush_nvme_rings(phba); } /** diff --git a/drivers/scsi/lpfc/lpfc_nvme.c b/drivers/scsi/lpfc/lpfc_nvme.c index ea7a0e65bbfd..67bd0ff299d1 100644 --- a/drivers/scsi/lpfc/lpfc_nvme.c +++ b/drivers/scsi/lpfc/lpfc_nvme.c @@ -88,6 +88,9 @@ lpfc_nvme_create_queue(struct nvme_fc_local_port *pnvme_lport, struct lpfc_nvme_qhandle *qhandle; char *str; + if (!pnvme_lport->private) + return -ENOMEM; + lport = (struct lpfc_nvme_lport *)pnvme_lport->private; vport = lport->vport; qhandle = kzalloc(sizeof(struct lpfc_nvme_qhandle), GFP_KERNEL); @@ -140,6 +143,9 @@ lpfc_nvme_delete_queue(struct nvme_fc_local_port *pnvme_lport, struct lpfc_nvme_lport *lport; struct lpfc_vport *vport; + if (!pnvme_lport->private) + return; + lport = (struct lpfc_nvme_lport *)pnvme_lport->private; vport = lport->vport; @@ -1265,13 +1271,29 @@ lpfc_nvme_fcp_io_submit(struct nvme_fc_local_port *pnvme_lport, struct lpfc_nvme_buf *lpfc_ncmd; struct lpfc_nvme_rport *rport; struct lpfc_nvme_qhandle *lpfc_queue_info; - struct lpfc_nvme_fcpreq_priv *freqpriv = pnvme_fcreq->private; + struct lpfc_nvme_fcpreq_priv *freqpriv; #ifdef CONFIG_SCSI_LPFC_DEBUG_FS uint64_t start = 0; #endif + /* Validate pointers. LLDD fault handling with transport does + * have timing races. + */ lport = (struct lpfc_nvme_lport *)pnvme_lport->private; + if (unlikely(!lport)) { + ret = -EINVAL; + goto out_fail; + } + vport = lport->vport; + + if (unlikely(!hw_queue_handle)) { + lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_ABTS, + "6129 Fail Abort, NULL hw_queue_handle\n"); + ret = -EINVAL; + goto out_fail; + } + phba = vport->phba; if (vport->load_flag & FC_UNLOADING) { @@ -1284,13 +1306,9 @@ lpfc_nvme_fcp_io_submit(struct nvme_fc_local_port *pnvme_lport, goto out_fail; } - /* Validate pointers. */ - if (!pnvme_lport || !pnvme_rport || !freqpriv) { - lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_IOERR | LOG_NODE, - "6117 No Send:IO submit ptrs NULL, lport %p, " - "rport %p fcreq_priv %p\n", - pnvme_lport, pnvme_rport, freqpriv); - ret = -ENODEV; + freqpriv = pnvme_fcreq->private; + if (unlikely(!freqpriv)) { + ret = -EINVAL; goto out_fail; } @@ -1497,20 +1515,34 @@ lpfc_nvme_fcp_abort(struct nvme_fc_local_port *pnvme_lport, struct lpfc_nvme_lport *lport; struct lpfc_vport *vport; struct lpfc_hba *phba; - struct lpfc_nvme_rport *rport; struct lpfc_nvme_buf *lpfc_nbuf; struct lpfc_iocbq *abts_buf; struct lpfc_iocbq *nvmereq_wqe; - struct lpfc_nvme_fcpreq_priv *freqpriv = pnvme_fcreq->private; + struct lpfc_nvme_fcpreq_priv *freqpriv; union lpfc_wqe *abts_wqe; unsigned long flags; int ret_val; + /* Validate pointers. LLDD fault handling with transport does + * have timing races. + */ lport = (struct lpfc_nvme_lport *)pnvme_lport->private; - rport = (struct lpfc_nvme_rport *)pnvme_rport->private; + if (unlikely(!lport)) + return; + vport = lport->vport; + + if (unlikely(!hw_queue_handle)) { + lpfc_printf_vlog(vport, KERN_INFO, LOG_NVME_ABTS, + "6129 Fail Abort, HW Queue Handle NULL.\n"); + return; + } + phba = vport->phba; + freqpriv = pnvme_fcreq->private; + if (unlikely(!freqpriv)) + return; if (vport->load_flag & FC_UNLOADING) return; @@ -2678,3 +2710,45 @@ lpfc_sli4_nvme_xri_aborted(struct lpfc_hba *phba, "6312 XRI Aborted xri x%x not found\n", xri); } + +/** + * lpfc_nvme_wait_for_io_drain - Wait for all NVME wqes to complete + * @phba: Pointer to HBA context object. + * + * This function flushes all wqes in the nvme rings and frees all resources + * in the txcmplq. This function does not issue abort wqes for the IO + * commands in txcmplq, they will just be returned with + * IOERR_SLI_DOWN. This function is invoked with EEH when device's PCI + * slot has been permanently disabled. + **/ +void +lpfc_nvme_wait_for_io_drain(struct lpfc_hba *phba) +{ + struct lpfc_sli_ring *pring; + u32 i, wait_cnt = 0; + + if (phba->sli_rev < LPFC_SLI_REV4) + return; + + /* Cycle through all NVME rings and make sure all outstanding + * WQEs have been removed from the txcmplqs. + */ + for (i = 0; i < phba->cfg_nvme_io_channel; i++) { + pring = phba->sli4_hba.nvme_wq[i]->pring; + + /* Retrieve everything on the txcmplq */ + while (!list_empty(&pring->txcmplq)) { + msleep(LPFC_XRI_EXCH_BUSY_WAIT_T1); + wait_cnt++; + + /* The sleep is 10mS. Every ten seconds, + * dump a message. Something is wrong. + */ + if ((wait_cnt % 1000) == 0) { + lpfc_printf_log(phba, KERN_ERR, LOG_NVME_IOERR, + "6178 NVME IO not empty, " + "cnt %d\n", wait_cnt); + } + } + } +} -- 2.13.1

7 years, 11 months

2
1
0 0

[Linux-stable-mirror] [PATCH] arm64: KVM: fix VTTBR_BADDR_MASK BUG_ON off-by-one

by Kristina Martsenko

VTTBR_BADDR_MASK is used to sanity check the size and alignment of the VTTBR address. It seems to currently be off by one, thereby only allowing up to 47-bit addresses (instead of 48-bit) and also insufficiently checking the alignment. This patch fixes it. As an example, with 4k pages, before this patch we have: PHYS_MASK_SHIFT = 48 VTTBR_X = 37 - 24 = 13 VTTBR_BADDR_SHIFT = 13 - 1 = 12 VTTBR_BADDR_MASK = ((1 << 35) - 1) << 12 = 0x00007ffffffff000 Which is wrong, because the mask doesn't allow bit 47 of the VTTBR address to be set, and only requires the address to be 12-bit (4k) aligned, while it actually needs to be 13-bit (8k) aligned because we concatenate two 4k tables. With this patch, the mask becomes 0x0000ffffffffe000, which is what we want. Fixes: 0369f6a34b9f ("arm64: KVM: EL2 register definitions") Cc: <stable(a)vger.kernel.org> # 3.11.x Reviewed-by: Suzuki K Poulose <suzuki.poulose(a)arm.com> Signed-off-by: Kristina Martsenko <kristina.martsenko(a)arm.com> --- arch/arm64/include/asm/kvm_arm.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h index 61d694c2eae5..555d463c0eaa 100644 --- a/arch/arm64/include/asm/kvm_arm.h +++ b/arch/arm64/include/asm/kvm_arm.h @@ -170,8 +170,7 @@ #define VTCR_EL2_FLAGS (VTCR_EL2_COMMON_BITS | VTCR_EL2_TGRAN_FLAGS) #define VTTBR_X (VTTBR_X_TGRAN_MAGIC - VTCR_EL2_T0SZ_IPA) -#define VTTBR_BADDR_SHIFT (VTTBR_X - 1) -#define VTTBR_BADDR_MASK (((UL(1) << (PHYS_MASK_SHIFT - VTTBR_X)) - 1) << VTTBR_BADDR_SHIFT) +#define VTTBR_BADDR_MASK (((UL(1) << (PHYS_MASK_SHIFT - VTTBR_X)) - 1) << VTTBR_X) #define VTTBR_VMID_SHIFT (UL(48)) #define VTTBR_VMID_MASK(size) (_AT(u64, (1 << size) - 1) << VTTBR_VMID_SHIFT) -- 2.1.4

7 years, 11 months

2
1
0 0

[Linux-stable-mirror] [PATCH 1/3] backlight: as3711_bl: fix device-tree node lookup

by Johan Hovold

Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent mfd node was also prematurely freed. Note that the nodes returned from the two calls to of_parse_phandle() are also leaking, but fixing that is a bit more involved as pointers to node fields are being stored for later use. Fixes: 59eb2b5e57ea ("drivers/video/backlight/as3711_bl.c: add OF support") Cc: stable <stable(a)vger.kernel.org> # 3.10 Cc: Guennadi Liakhovetski <g.liakhovetski(a)gmx.de> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/video/backlight/as3711_bl.c | 35 +++++++++++++++++++++++++---------- 1 file changed, 25 insertions(+), 10 deletions(-) diff --git a/drivers/video/backlight/as3711_bl.c b/drivers/video/backlight/as3711_bl.c index 734a9158946b..21ce56053c88 100644 --- a/drivers/video/backlight/as3711_bl.c +++ b/drivers/video/backlight/as3711_bl.c @@ -262,15 +262,16 @@ static int as3711_bl_register(struct platform_device *pdev, static int as3711_backlight_parse_dt(struct device *dev) { struct as3711_bl_pdata *pdata = dev_get_platdata(dev); - struct device_node *bl = - of_find_node_by_name(dev->parent->of_node, "backlight"), *fb; + struct device_node *bl, *fb; int ret; + bl = of_get_child_by_name(dev->parent->of_node, "backlight"); if (!bl) { dev_dbg(dev, "backlight node not found\n"); return -ENODEV; } + /* FIXME: need to drop reference to returned node */ fb = of_parse_phandle(bl, "su1-dev", 0); if (fb) { pdata->su1_fb = fb->full_name; @@ -279,9 +280,10 @@ static int as3711_backlight_parse_dt(struct device *dev) if (pdata->su1_max_uA <= 0) ret = -EINVAL; if (ret < 0) - return ret; + goto err_put_bl; } + /* FIXME: need to drop reference to returned node */ fb = of_parse_phandle(bl, "su2-dev", 0); if (fb) { int count = 0; @@ -292,7 +294,7 @@ static int as3711_backlight_parse_dt(struct device *dev) if (pdata->su2_max_uA <= 0) ret = -EINVAL; if (ret < 0) - return ret; + goto err_put_bl; if (of_find_property(bl, "su2-feedback-voltage", NULL)) { pdata->su2_feedback = AS3711_SU2_VOLTAGE; @@ -314,8 +316,10 @@ static int as3711_backlight_parse_dt(struct device *dev) pdata->su2_feedback = AS3711_SU2_CURR_AUTO; count++; } - if (count != 1) - return -EINVAL; + if (count != 1) { + ret = -EINVAL; + goto err_put_bl; + } count = 0; if (of_find_property(bl, "su2-fbprot-lx-sd4", NULL)) { @@ -334,8 +338,10 @@ static int as3711_backlight_parse_dt(struct device *dev) pdata->su2_fbprot = AS3711_SU2_GPIO4; count++; } - if (count != 1) - return -EINVAL; + if (count != 1) { + ret = -EINVAL; + goto err_put_bl; + } count = 0; if (of_find_property(bl, "su2-auto-curr1", NULL)) { @@ -355,11 +361,20 @@ static int as3711_backlight_parse_dt(struct device *dev) * At least one su2-auto-curr* must be specified iff * AS3711_SU2_CURR_AUTO is used */ - if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO)) - return -EINVAL; + if (!count ^ (pdata->su2_feedback != AS3711_SU2_CURR_AUTO)) { + ret = -EINVAL; + goto err_put_bl; + } } + of_node_put(bl); + return 0; + +err_put_bl: + of_node_put(bl); + + return ret; } static int as3711_backlight_probe(struct platform_device *pdev) -- 2.15.0

7 years, 11 months

3
12
0 0

[Linux-stable-mirror] [PATCH] drm/i915: Fix init_clock_gating for resume

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Moving the init_clock_gating() call from intel_modeset_init_hw() to intel_modeset_gem_init() had an unintended effect of not applying some workarounds on resume. This, for example, cause some kind of corruption to appear at the top of my IVB Thinkpad X1 Carbon LVDS screen after hibernation. Fix the problem by explicitly calling init_clock_gating() from the resume path. I really hope this doesn't break something else again... Cc: stable(a)vger.kernel.org Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Fixes: 6ac43272768c ("drm/i915: Move init_clock_gating() back to where it was") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/i915/i915_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 9df7b5d59a94..0023fb17899f 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1707,6 +1707,7 @@ static int i915_drm_resume(struct drm_device *dev) intel_guc_resume(dev_priv); + intel_init_clock_gating(dev_priv); intel_modeset_init_hw(dev); spin_lock_irq(&dev_priv->irq_lock); -- 2.13.6

7 years, 11 months

4
6
0 0

[Linux-stable-mirror] [PATCH] fanotify: fix -EOVERFLOW with large files on 64-bit

by Stefan Nuernberger

From: Will Woods <wwoods(a)redhat.com> commit 1e2ee49f7f1b79f0b14884fe6a602f0411b39552 upstream. On 64-bit systems, O_LARGEFILE is automatically added to flags inside the open() syscall (also openat(), blkdev_open(), etc). Userspace therefore defines O_LARGEFILE to be 0 - you can use it, but it's a no-op. Everything should be O_LARGEFILE by default. But: when fanotify does create_fd() it uses dentry_open(), which skips all that. And userspace can't set O_LARGEFILE in fanotify_init() because it's defined to 0. So if fanotify gets an event regarding a large file, the read() will just fail with -EOVERFLOW. This patch adds O_LARGEFILE to fanotify_init()'s event_f_flags on 64-bit systems, using the same test as open()/openat()/etc. Addresses https://bugzilla.redhat.com/show_bug.cgi?id=696821 Signed-off-by: Will Woods <wwoods(a)redhat.com> Acked-by: Eric Paris <eparis(a)redhat.com> Reviewed-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> [snu: Backported to 3.2 / 3.10: adjusted context] Signed-off-by: Stefan Nuernberger <snu(a)amazon.com> Reviewed-by: Pawel Wieczorkiewicz <wipawel(a)amazon.de> Reviewed-by: Simon Veith <sveith(a)amazon.de> Cc: <stable(a)vger.kernel.org> # 3.2.x and 3.10.x --- fs/notify/fanotify/fanotify_user.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c index d57995e1cfd7..dd3d9d13a4c4 100644 --- a/fs/notify/fanotify/fanotify_user.c +++ b/fs/notify/fanotify/fanotify_user.c @@ -712,6 +712,9 @@ SYSCALL_DEFINE2(fanotify_init, unsigned int, flags, unsigned int, event_f_flags) group->fanotify_data.user = user; atomic_inc(&user->fanotify_listeners); + if (force_o_largefile()) + event_f_flags |= O_LARGEFILE; + group->fanotify_data.f_flags = event_f_flags; #ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS mutex_init(&group->fanotify_data.access_mutex); -- 2.15.0

7 years, 11 months

4
3
0 0

[Linux-stable-mirror] [PATCH v4 1/2] md/r5cache: move mddev_lock() out of r5c_journal_mode_set()

by Song Liu

r5c_journal_mode_set() is called by r5c_journal_mode_store() and raid_ctr() in dm-raid. We don't need mddev_lock() when calling from raid_ctr(). This patch fixes this by moves the mddev_lock() to r5c_journal_mode_store(). Cc: stable(a)vger.kernel.org (v4.13+) Signed-off-by: Song Liu <songliubraving(a)fb.com> --- drivers/md/raid5-cache.c | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c index f1c86d9..39f31f0 100644 --- a/drivers/md/raid5-cache.c +++ b/drivers/md/raid5-cache.c @@ -2577,31 +2577,22 @@ static ssize_t r5c_journal_mode_show(struct mddev *mddev, char *page) int r5c_journal_mode_set(struct mddev *mddev, int mode) { struct r5conf *conf; - int err; if (mode < R5C_JOURNAL_MODE_WRITE_THROUGH || mode > R5C_JOURNAL_MODE_WRITE_BACK) return -EINVAL; - err = mddev_lock(mddev); - if (err) - return err; conf = mddev->private; - if (!conf || !conf->log) { - mddev_unlock(mddev); + if (!conf || !conf->log) return -ENODEV; - } if (raid5_calc_degraded(conf) > 0 && - mode == R5C_JOURNAL_MODE_WRITE_BACK) { - mddev_unlock(mddev); + mode == R5C_JOURNAL_MODE_WRITE_BACK) return -EINVAL; - } mddev_suspend(mddev); conf->log->r5c_journal_mode = mode; mddev_resume(mddev); - mddev_unlock(mddev); pr_debug("md/raid:%s: setting r5c cache mode to %d: %s\n", mdname(mddev), mode, r5c_journal_mode_str[mode]); @@ -2614,6 +2605,7 @@ static ssize_t r5c_journal_mode_store(struct mddev *mddev, { int mode = ARRAY_SIZE(r5c_journal_mode_str); size_t len = length; + int ret; if (len < 2) return -EINVAL; @@ -2625,8 +2617,12 @@ static ssize_t r5c_journal_mode_store(struct mddev *mddev, if (strlen(r5c_journal_mode_str[mode]) == len && !strncmp(page, r5c_journal_mode_str[mode], len)) break; - - return r5c_journal_mode_set(mddev, mode) ?: length; + ret = mddev_lock(mddev); + if (ret) + return ret; + ret = r5c_journal_mode_set(mddev, mode); + mddev_unlock(mddev); + return ret ?: length; } struct md_sysfs_entry -- 2.9.5

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] [PATCH v3 1/2] md/r5cache: move mddev_lock() out of r5c_journal_mode_set()

by Song Liu

r5c_journal_mode_set() is called by r5c_journal_mode_store() and raid_ctr() in dm-raid. We don't need mddev_lock() when calling from raid_ctr(). This patch fixes this by moves the mddev_lock() to r5c_journal_mode_store(). Cc: stable(a)vger.kernel.org (v4.13+) Signed-off-by: Song Liu <songliubraving(a)fb.com> --- drivers/md/raid5-cache.c | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c index f1c86d9..e01f229 100644 --- a/drivers/md/raid5-cache.c +++ b/drivers/md/raid5-cache.c @@ -2583,25 +2583,19 @@ int r5c_journal_mode_set(struct mddev *mddev, int mode) mode > R5C_JOURNAL_MODE_WRITE_BACK) return -EINVAL; - err = mddev_lock(mddev); if (err) return err; conf = mddev->private; - if (!conf || !conf->log) { - mddev_unlock(mddev); + if (!conf || !conf->log) return -ENODEV; - } if (raid5_calc_degraded(conf) > 0 && - mode == R5C_JOURNAL_MODE_WRITE_BACK) { - mddev_unlock(mddev); + mode == R5C_JOURNAL_MODE_WRITE_BACK) return -EINVAL; - } mddev_suspend(mddev); conf->log->r5c_journal_mode = mode; mddev_resume(mddev); - mddev_unlock(mddev); pr_debug("md/raid:%s: setting r5c cache mode to %d: %s\n", mdname(mddev), mode, r5c_journal_mode_str[mode]); @@ -2614,6 +2608,7 @@ static ssize_t r5c_journal_mode_store(struct mddev *mddev, { int mode = ARRAY_SIZE(r5c_journal_mode_str); size_t len = length; + int ret; if (len < 2) return -EINVAL; @@ -2625,8 +2620,10 @@ static ssize_t r5c_journal_mode_store(struct mddev *mddev, if (strlen(r5c_journal_mode_str[mode]) == len && !strncmp(page, r5c_journal_mode_str[mode], len)) break; - - return r5c_journal_mode_set(mddev, mode) ?: length; + mddev_lock(mddev); + ret = r5c_journal_mode_set(mddev, mode); + mddev_unlock(mddev); + return ret ?: length; } struct md_sysfs_entry -- 2.9.5

7 years, 11 months

2
1
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] platform/x86: fujitsu-laptop: Don't oops when FUJ02E3 is not" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From cd6bf7741cf992306748db11e1888c741d16dd0f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Mon, 18 Sep 2017 23:00:59 +0300 Subject: [PATCH] platform/x86: fujitsu-laptop: Don't oops when FUJ02E3 is not presnt MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit My Fujitsu-Siemens Lifebook S6120 doesn't have the FUJ02E3 device, but it does have FUJ02B1. That means we do register the backlight device (and it even seems to work), but the code will oops as soon as we try to set the backlight brightness because it's trying to call call_fext_func() with a NULL device. Let's just skip those function calls when the FUJ02E3 device is not present. Cc: Jonathan Woithe <jwoithe(a)just42.net> Cc: Andy Shevchenko <andy(a)infradead.org> Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> # 4.13.x Signed-off-by: Darren Hart (VMware) <dvhart(a)infradead.org> diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c index 85de30f93a9c..56a8195096a2 100644 --- a/drivers/platform/x86/fujitsu-laptop.c +++ b/drivers/platform/x86/fujitsu-laptop.c @@ -254,10 +254,12 @@ static int bl_update_status(struct backlight_device *b) { struct acpi_device *device = bl_get_data(b); - if (b->props.power == FB_BLANK_POWERDOWN) - call_fext_func(fext, FUNC_BACKLIGHT, 0x1, 0x4, 0x3); - else - call_fext_func(fext, FUNC_BACKLIGHT, 0x1, 0x4, 0x0); + if (fext) { + if (b->props.power == FB_BLANK_POWERDOWN) + call_fext_func(fext, FUNC_BACKLIGHT, 0x1, 0x4, 0x3); + else + call_fext_func(fext, FUNC_BACKLIGHT, 0x1, 0x4, 0x0); + } return set_lcd_level(device, b->props.brightness); }

7 years, 11 months

2
1
0 0

[Linux-stable-mirror] Patch "staging: greybus: spilib: fix use-after-free after deregistration" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: greybus: spilib: fix use-after-free after deregistration to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-greybus-spilib-fix-use-after-free-after-deregistration.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 770b03c2ca4aa44d226cf248f86aa23e546147d0 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Sun, 29 Oct 2017 13:01:33 +0100 Subject: staging: greybus: spilib: fix use-after-free after deregistration From: Johan Hovold <johan(a)kernel.org> commit 770b03c2ca4aa44d226cf248f86aa23e546147d0 upstream. Remove erroneous spi_master_put() after controller deregistration which would access the already freed spi controller. Note that spi_unregister_master() drops our only controller reference. Fixes: ba3e67001b42 ("greybus: SPI: convert to a gpbridge driver") Signed-off-by: Johan Hovold <johan(a)kernel.org> Reviewed-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Acked-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/greybus/spilib.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/drivers/staging/greybus/spilib.c +++ b/drivers/staging/greybus/spilib.c @@ -544,12 +544,15 @@ int gb_spilib_master_init(struct gb_conn return 0; -exit_spi_unregister: - spi_unregister_master(master); exit_spi_put: spi_master_put(master); return ret; + +exit_spi_unregister: + spi_unregister_master(master); + + return ret; } EXPORT_SYMBOL_GPL(gb_spilib_master_init); @@ -558,7 +561,6 @@ void gb_spilib_master_exit(struct gb_con struct spi_master *master = gb_connection_get_data(connection); spi_unregister_master(master); - spi_master_put(master); } EXPORT_SYMBOL_GPL(gb_spilib_master_exit); Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.9/usb-serial-qcserial-add-pid-vid-for-sierra-wireless-em7355-fw-update.patch queue-4.9/staging-greybus-add-host-device-function-pointer-checks.patch queue-4.9/staging-greybus-spilib-fix-use-after-free-after-deregistration.patch queue-4.9/usb-serial-garmin_gps-fix-i-o-after-failed-probe-and-remove.patch queue-4.9/usb-serial-garmin_gps-fix-memory-leak-on-probe-errors.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: wilc1000: Fix bssid buffer offset in Txq" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: wilc1000: Fix bssid buffer offset in Txq to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-wilc1000-fix-bssid-buffer-offset-in-txq.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1bbf6a6d4091affb27ec0a19d7aa7887ce72f610 Mon Sep 17 00:00:00 2001 From: Aditya Shankar <aditya.shankar(a)microchip.com> Date: Fri, 3 Nov 2017 14:26:27 +0530 Subject: staging: wilc1000: Fix bssid buffer offset in Txq From: Aditya Shankar <aditya.shankar(a)microchip.com> commit 1bbf6a6d4091affb27ec0a19d7aa7887ce72f610 upstream. Commit 46949b48568b ("staging: wilc1000: New cfg packet format in handle_set_wfi_drv_handler") updated the frame format sent from host to the firmware. The code to update the bssid offset in the new frame was part of a second patch in the series which did not make it in and thus causes connection problems after associating to an AP. This fix adds the proper offset of the bssid value in the Tx queue buffer to fix the connection issues. Fixes: 46949b48568b ("staging: wilc1000: New cfg packet format in handle_set_wfi_drv_handler") Signed-off-by: Aditya Shankar <Aditya.Shankar(a)microchip.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/wilc1000/wilc_wlan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/staging/wilc1000/wilc_wlan.c +++ b/drivers/staging/wilc1000/wilc_wlan.c @@ -714,7 +714,7 @@ int wilc_wlan_handle_txq(struct net_devi char *bssid = ((struct tx_complete_data *)(tqe->priv))->bssid; buffer_offset = ETH_ETHERNET_HDR_OFFSET; - memcpy(&txb[offset + 4], bssid, 6); + memcpy(&txb[offset + 8], bssid, 6); } else { buffer_offset = HOST_HDR_OFFSET; } Patches currently in stable-queue which might be from aditya.shankar(a)microchip.com are queue-4.14/staging-wilc1000-fix-bssid-buffer-offset-in-txq.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: vboxvideo: Fix reporting invalid suggested-offset-properties" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: vboxvideo: Fix reporting invalid suggested-offset-properties to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-vboxvideo-fix-reporting-invalid-suggested-offset-properties.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ce10d7b4e8e3574b9616e54a09d64521b9aeb8b6 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Thu, 12 Oct 2017 20:10:25 +0200 Subject: staging: vboxvideo: Fix reporting invalid suggested-offset-properties From: Hans de Goede <hdegoede(a)redhat.com> commit ce10d7b4e8e3574b9616e54a09d64521b9aeb8b6 upstream. The x and y hints receives from the host are unsigned 32 bit integers and they get set to -1 (0xffffffff) when invalid. Before this commit the vboxvideo driver was storing them in an u16 causing the -1 to be truncated to 65535 which, once reported to userspace, was breaking gnome 3.26+ in Wayland mode. This commit stores the host values in 32 bit variables, removing the truncation and checks for -1, replacing it with 0 as -1 is not a valid suggested-offset-property value. Likewise the properties are now initialized to 0 instead of -1, since -1 is not a valid value. This fixes gnome 3.26+ in Wayland mode not working with the vboxvideo driver. Reported-by: Gianfranco Costamagna <locutusofborg(a)debian.org> Cc: Michael Thayer <michael.thayer(a)oracle.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/vboxvideo/vbox_drv.h | 8 ++++---- drivers/staging/vboxvideo/vbox_irq.c | 4 ++-- drivers/staging/vboxvideo/vbox_mode.c | 26 ++++++++++++++++++-------- 3 files changed, 24 insertions(+), 14 deletions(-) --- a/drivers/staging/vboxvideo/vbox_drv.h +++ b/drivers/staging/vboxvideo/vbox_drv.h @@ -137,8 +137,8 @@ struct vbox_connector { char name[32]; struct vbox_crtc *vbox_crtc; struct { - u16 width; - u16 height; + u32 width; + u32 height; bool disconnected; } mode_hint; }; @@ -150,8 +150,8 @@ struct vbox_crtc { unsigned int crtc_id; u32 fb_offset; bool cursor_enabled; - u16 x_hint; - u16 y_hint; + u32 x_hint; + u32 y_hint; }; struct vbox_encoder { --- a/drivers/staging/vboxvideo/vbox_irq.c +++ b/drivers/staging/vboxvideo/vbox_irq.c @@ -150,8 +150,8 @@ static void vbox_update_mode_hints(struc disconnected = !(hints->enabled); crtc_id = vbox_conn->vbox_crtc->crtc_id; - vbox_conn->mode_hint.width = hints->cx & 0x8fff; - vbox_conn->mode_hint.height = hints->cy & 0x8fff; + vbox_conn->mode_hint.width = hints->cx; + vbox_conn->mode_hint.height = hints->cy; vbox_conn->vbox_crtc->x_hint = hints->dx; vbox_conn->vbox_crtc->y_hint = hints->dy; vbox_conn->mode_hint.disconnected = disconnected; --- a/drivers/staging/vboxvideo/vbox_mode.c +++ b/drivers/staging/vboxvideo/vbox_mode.c @@ -553,12 +553,22 @@ static int vbox_get_modes(struct drm_con ++num_modes; } vbox_set_edid(connector, preferred_width, preferred_height); - drm_object_property_set_value( - &connector->base, vbox->dev->mode_config.suggested_x_property, - vbox_connector->vbox_crtc->x_hint); - drm_object_property_set_value( - &connector->base, vbox->dev->mode_config.suggested_y_property, - vbox_connector->vbox_crtc->y_hint); + + if (vbox_connector->vbox_crtc->x_hint != -1) + drm_object_property_set_value(&connector->base, + vbox->dev->mode_config.suggested_x_property, + vbox_connector->vbox_crtc->x_hint); + else + drm_object_property_set_value(&connector->base, + vbox->dev->mode_config.suggested_x_property, 0); + + if (vbox_connector->vbox_crtc->y_hint != -1) + drm_object_property_set_value(&connector->base, + vbox->dev->mode_config.suggested_y_property, + vbox_connector->vbox_crtc->y_hint); + else + drm_object_property_set_value(&connector->base, + vbox->dev->mode_config.suggested_y_property, 0); return num_modes; } @@ -640,9 +650,9 @@ static int vbox_connector_init(struct dr drm_mode_create_suggested_offset_properties(dev); drm_object_attach_property(&connector->base, - dev->mode_config.suggested_x_property, -1); + dev->mode_config.suggested_x_property, 0); drm_object_attach_property(&connector->base, - dev->mode_config.suggested_y_property, -1); + dev->mode_config.suggested_y_property, 0); drm_connector_register(connector); drm_mode_connector_attach_encoder(connector, encoder); Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.14/staging-rtl8188eu-revert-4-commits-breaking-arp.patch queue-4.14/platform-x86-peaq-wmi-add-dmi-check-before-binding-to-the-wmi-interface.patch queue-4.14/platform-x86-peaq_wmi-fix-missing-terminating-entry-for-peaq_dmi_table.patch queue-4.14/staging-vboxvideo-fix-reporting-invalid-suggested-offset-properties.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: sm750fb: Fix parameter mistake in poke32" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: sm750fb: Fix parameter mistake in poke32 to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-sm750fb-fix-parameter-mistake-in-poke32.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 16808dcf605e6302319a8c3266789b76d4c0983b Mon Sep 17 00:00:00 2001 From: Huacai Chen <chenhc(a)lemote.com> Date: Mon, 6 Nov 2017 08:43:03 +0800 Subject: staging: sm750fb: Fix parameter mistake in poke32 From: Huacai Chen <chenhc(a)lemote.com> commit 16808dcf605e6302319a8c3266789b76d4c0983b upstream. In commit c075b6f2d357ea9 ("staging: sm750fb: Replace POKE32 and PEEK32 by inline functions"), POKE32 has been replaced by the inline function poke32. But it exchange the "addr" and "data" parameters by mistake, so fix it. Fixes: c075b6f2d357ea9 ("staging: sm750fb: Replace POKE32 and PEEK32 by inline functions"), Signed-off-by: Huacai Chen <chenhc(a)lemote.com> Signed-off-by: Liangliang Huang <huangll(a)lemote.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/sm750fb/ddk750_chip.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/staging/sm750fb/ddk750_chip.h +++ b/drivers/staging/sm750fb/ddk750_chip.h @@ -18,7 +18,7 @@ static inline u32 peek32(u32 addr) return readl(addr + mmio750); } -static inline void poke32(u32 data, u32 addr) +static inline void poke32(u32 addr, u32 data) { writel(data, addr + mmio750); } Patches currently in stable-queue which might be from chenhc(a)lemote.com are queue-4.14/staging-sm750fb-fix-parameter-mistake-in-poke32.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: rtl8188eu: Revert 4 commits breaking ARP" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: rtl8188eu: Revert 4 commits breaking ARP to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-rtl8188eu-revert-4-commits-breaking-arp.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 66d32fdcbf03851724a8b551d490ae1ddfe6eef2 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Thu, 2 Nov 2017 10:30:13 +0100 Subject: staging: rtl8188eu: Revert 4 commits breaking ARP From: Hans de Goede <hdegoede(a)redhat.com> commit 66d32fdcbf03851724a8b551d490ae1ddfe6eef2 upstream. Commit 2ba8444c97b1 ("staging:r8188eu: move IV/ICV trimming into decrypt() and also place it after rtl88eu_mon_recv_hook()") breaks ARP. After this commit ssh-ing to a laptop with r8188eu wifi no longer works if the machine connecting has never communicated with the laptop before. This is 100% reproducable using "arp -d <ipv4> && ssh <ipv4>" to ssh to a laptop with r8188eu wifi. This commit reverts 4 commits in total: 1. Commit 79650ffde38e ("staging:r8188eu: trim IV/ICV fields in validate_recv_data_frame()") This commit depends on 2 of the other commits being reverted. 2. Commit 02b19b4c4920 ("staging:r8188eu: inline unprotect_frame() in mon_recv_decrypted_recv()") The inline code is wrong the un-inlined version contains: if (skb->len < hdr_len + iv_len + icv_len) return; ... Where as the inline-ed code introduced by this commit does: if (skb->len < hdr_len + iv_len + icv_len) { ... Note the same check, but now to actually continue doing ... instead of to not do it, so this commit is no good. 3. Commit d86e16da6a5d ("staging:r8188eu: use different mon_recv_decrypted() inside rtl88eu_mon_recv_hook() and rtl88eu_mon_xmit_hook().") This commit introduced a 1:1 copy of a function so that one of the 2 copies can be modified in the 2 commits we're already reverting. 4. Commit 2ba8444c97b1 ("staging:r8188eu: move IV/ICV trimming into decrypt() and also place it after rtl88eu_mon_recv_hook()") This is the commit actually breaking ARP. Note this commit is a straight-forward squash of the revert of these 4 commits, without any changes. Cc: Ivan Safonov <insafonov(a)gmail.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/rtl8188eu/core/rtw_recv.c | 83 ++++++++++++++++++------------ drivers/staging/rtl8188eu/os_dep/mon.c | 34 +----------- 2 files changed, 55 insertions(+), 62 deletions(-) --- a/drivers/staging/rtl8188eu/core/rtw_recv.c +++ b/drivers/staging/rtl8188eu/core/rtw_recv.c @@ -259,10 +259,12 @@ static int recvframe_chkmic(struct adapt } /* icv_len included the mic code */ - datalen = precvframe->pkt->len-prxattrib->hdrlen - 8; + datalen = precvframe->pkt->len-prxattrib->hdrlen - + prxattrib->iv_len-prxattrib->icv_len-8; pframe = precvframe->pkt->data; - payload = pframe+prxattrib->hdrlen; + payload = pframe+prxattrib->hdrlen+prxattrib->iv_len; + RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("\n prxattrib->iv_len=%d prxattrib->icv_len=%d\n", prxattrib->iv_len, prxattrib->icv_len)); rtw_seccalctkipmic(mickey, pframe, payload, datalen, &miccode[0], (unsigned char)prxattrib->priority); /* care the length of the data */ @@ -407,15 +409,9 @@ static struct recv_frame *decryptor(stru default: break; } - if (res != _FAIL) { - memmove(precv_frame->pkt->data + precv_frame->attrib.iv_len, precv_frame->pkt->data, precv_frame->attrib.hdrlen); - skb_pull(precv_frame->pkt, precv_frame->attrib.iv_len); - skb_trim(precv_frame->pkt, precv_frame->pkt->len - precv_frame->attrib.icv_len); - } } else if (prxattrib->bdecrypted == 1 && prxattrib->encrypt > 0 && - (psecuritypriv->busetkipkey == 1 || prxattrib->encrypt != _TKIP_)) { - psecuritypriv->hw_decrypted = true; - } + (psecuritypriv->busetkipkey == 1 || prxattrib->encrypt != _TKIP_)) + psecuritypriv->hw_decrypted = true; if (res == _FAIL) { rtw_free_recvframe(return_packet, &padapter->recvpriv.free_recv_queue); @@ -456,7 +452,7 @@ static struct recv_frame *portctrl(struc if (auth_alg == 2) { /* get ether_type */ - ptr = ptr + pfhdr->attrib.hdrlen + LLC_HEADER_SIZE; + ptr = ptr + pfhdr->attrib.hdrlen + LLC_HEADER_SIZE + pfhdr->attrib.iv_len; memcpy(&be_tmp, ptr, 2); ether_type = ntohs(be_tmp); @@ -1138,8 +1134,6 @@ static int validate_recv_data_frame(stru } if (pattrib->privacy) { - struct sk_buff *skb = precv_frame->pkt; - RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("validate_recv_data_frame:pattrib->privacy=%x\n", pattrib->privacy)); RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("\n ^^^^^^^^^^^IS_MCAST(pattrib->ra(0x%02x))=%d^^^^^^^^^^^^^^^6\n", pattrib->ra[0], IS_MCAST(pattrib->ra))); @@ -1148,13 +1142,6 @@ static int validate_recv_data_frame(stru RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("\n pattrib->encrypt=%d\n", pattrib->encrypt)); SET_ICE_IV_LEN(pattrib->iv_len, pattrib->icv_len, pattrib->encrypt); - - if (pattrib->bdecrypted == 1 && pattrib->encrypt > 0) { - memmove(skb->data + pattrib->iv_len, - skb->data, pattrib->hdrlen); - skb_pull(skb, pattrib->iv_len); - skb_trim(skb, skb->len - pattrib->icv_len); - } } else { pattrib->encrypt = 0; pattrib->iv_len = 0; @@ -1274,7 +1261,6 @@ static int validate_recv_frame(struct ad * Hence forward the frame to the monitor anyway to preserve the order * in which frames were received. */ - rtl88eu_mon_recv_hook(adapter->pmondev, precv_frame); exit: @@ -1296,8 +1282,11 @@ static int wlanhdr_to_ethhdr(struct recv u8 *ptr = precvframe->pkt->data; struct rx_pkt_attrib *pattrib = &precvframe->attrib; - psnap = (struct ieee80211_snap_hdr *)(ptr+pattrib->hdrlen); - psnap_type = ptr+pattrib->hdrlen + SNAP_SIZE; + if (pattrib->encrypt) + skb_trim(precvframe->pkt, precvframe->pkt->len - pattrib->icv_len); + + psnap = (struct ieee80211_snap_hdr *)(ptr+pattrib->hdrlen + pattrib->iv_len); + psnap_type = ptr+pattrib->hdrlen + pattrib->iv_len+SNAP_SIZE; /* convert hdr + possible LLC headers into Ethernet header */ if ((!memcmp(psnap, rtw_rfc1042_header, SNAP_SIZE) && (!memcmp(psnap_type, SNAP_ETH_TYPE_IPX, 2) == false) && @@ -1310,9 +1299,12 @@ static int wlanhdr_to_ethhdr(struct recv bsnaphdr = false; } - rmv_len = pattrib->hdrlen + (bsnaphdr ? SNAP_SIZE : 0); + rmv_len = pattrib->hdrlen + pattrib->iv_len + (bsnaphdr ? SNAP_SIZE : 0); len = precvframe->pkt->len - rmv_len; + RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, + ("\n===pattrib->hdrlen: %x, pattrib->iv_len:%x===\n\n", pattrib->hdrlen, pattrib->iv_len)); + memcpy(&be_tmp, ptr+rmv_len, 2); eth_type = ntohs(be_tmp); /* pattrib->ether_type */ pattrib->eth_type = eth_type; @@ -1337,6 +1329,7 @@ static struct recv_frame *recvframe_defr struct __queue *defrag_q) { struct list_head *plist, *phead; + u8 wlanhdr_offset; u8 curfragnum; struct recv_frame *pfhdr, *pnfhdr; struct recv_frame *prframe, *pnextrframe; @@ -1385,7 +1378,12 @@ static struct recv_frame *recvframe_defr /* copy the 2nd~n fragment frame's payload to the first fragment */ /* get the 2nd~last fragment frame's payload */ - skb_pull(pnextrframe->pkt, pnfhdr->attrib.hdrlen); + wlanhdr_offset = pnfhdr->attrib.hdrlen + pnfhdr->attrib.iv_len; + + skb_pull(pnextrframe->pkt, wlanhdr_offset); + + /* append to first fragment frame's tail (if privacy frame, pull the ICV) */ + skb_trim(prframe->pkt, prframe->pkt->len - pfhdr->attrib.icv_len); /* memcpy */ memcpy(skb_tail_pointer(pfhdr->pkt), pnfhdr->pkt->data, @@ -1393,7 +1391,7 @@ static struct recv_frame *recvframe_defr skb_put(prframe->pkt, pnfhdr->pkt->len); - pfhdr->attrib.icv_len = 0; + pfhdr->attrib.icv_len = pnfhdr->attrib.icv_len; plist = plist->next; } @@ -1519,6 +1517,11 @@ static int amsdu_to_msdu(struct adapter nr_subframes = 0; pattrib = &prframe->attrib; + skb_pull(prframe->pkt, prframe->attrib.hdrlen); + + if (prframe->attrib.iv_len > 0) + skb_pull(prframe->pkt, prframe->attrib.iv_len); + a_len = prframe->pkt->len; pdata = prframe->pkt->data; @@ -1887,6 +1890,24 @@ static int process_recv_indicatepkts(str return retval; } +static int recv_func_prehandle(struct adapter *padapter, + struct recv_frame *rframe) +{ + int ret = _SUCCESS; + struct __queue *pfree_recv_queue = &padapter->recvpriv.free_recv_queue; + + /* check the frame crtl field and decache */ + ret = validate_recv_frame(padapter, rframe); + if (ret != _SUCCESS) { + RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("recv_func: validate_recv_frame fail! drop pkt\n")); + rtw_free_recvframe(rframe, pfree_recv_queue);/* free this recv_frame */ + goto exit; + } + +exit: + return ret; +} + static int recv_func_posthandle(struct adapter *padapter, struct recv_frame *prframe) { @@ -1939,7 +1960,6 @@ static int recv_func(struct adapter *pad struct rx_pkt_attrib *prxattrib = &rframe->attrib; struct security_priv *psecuritypriv = &padapter->securitypriv; struct mlme_priv *mlmepriv = &padapter->mlmepriv; - struct __queue *pfree_recv_queue = &padapter->recvpriv.free_recv_queue; /* check if need to handle uc_swdec_pending_queue*/ if (check_fwstate(mlmepriv, WIFI_STATION_STATE) && psecuritypriv->busetkipkey) { @@ -1951,12 +1971,9 @@ static int recv_func(struct adapter *pad } } - /* check the frame crtl field and decache */ - ret = validate_recv_frame(padapter, rframe); - if (ret != _SUCCESS) { - RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("recv_func: validate_recv_frame fail! drop pkt\n")); - rtw_free_recvframe(rframe, pfree_recv_queue);/* free this recv_frame */ - } else { + ret = recv_func_prehandle(padapter, rframe); + + if (ret == _SUCCESS) { /* check if need to enqueue into uc_swdec_pending_queue*/ if (check_fwstate(mlmepriv, WIFI_STATION_STATE) && !IS_MCAST(prxattrib->ra) && prxattrib->encrypt > 0 && --- a/drivers/staging/rtl8188eu/os_dep/mon.c +++ b/drivers/staging/rtl8188eu/os_dep/mon.c @@ -66,34 +66,6 @@ static void mon_recv_decrypted(struct ne netif_rx(skb); } -static void mon_recv_decrypted_recv(struct net_device *dev, const u8 *data, - int data_len) -{ - struct sk_buff *skb; - struct ieee80211_hdr *hdr; - int hdr_len; - - skb = netdev_alloc_skb(dev, data_len); - if (!skb) - return; - memcpy(skb_put(skb, data_len), data, data_len); - - /* - * Frame data is not encrypted. Strip off protection so - * userspace doesn't think that it is. - */ - - hdr = (struct ieee80211_hdr *)skb->data; - hdr_len = ieee80211_hdrlen(hdr->frame_control); - - if (ieee80211_has_protected(hdr->frame_control)) - hdr->frame_control &= ~cpu_to_le16(IEEE80211_FCTL_PROTECTED); - - skb->ip_summed = CHECKSUM_UNNECESSARY; - skb->protocol = eth_type_trans(skb, dev); - netif_rx(skb); -} - static void mon_recv_encrypted(struct net_device *dev, const u8 *data, int data_len) { @@ -110,6 +82,7 @@ static void mon_recv_encrypted(struct ne void rtl88eu_mon_recv_hook(struct net_device *dev, struct recv_frame *frame) { struct rx_pkt_attrib *attr; + int iv_len, icv_len; int data_len; u8 *data; @@ -122,8 +95,11 @@ void rtl88eu_mon_recv_hook(struct net_de data = frame->pkt->data; data_len = frame->pkt->len; + /* Broadcast and multicast frames don't have attr->{iv,icv}_len set */ + SET_ICE_IV_LEN(iv_len, icv_len, attr->encrypt); + if (attr->bdecrypted) - mon_recv_decrypted_recv(dev, data, data_len); + mon_recv_decrypted(dev, data, data_len, iv_len, icv_len); else mon_recv_encrypted(dev, data, data_len); } Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.14/staging-rtl8188eu-revert-4-commits-breaking-arp.patch queue-4.14/platform-x86-peaq-wmi-add-dmi-check-before-binding-to-the-wmi-interface.patch queue-4.14/platform-x86-peaq_wmi-fix-missing-terminating-entry-for-peaq_dmi_table.patch queue-4.14/staging-vboxvideo-fix-reporting-invalid-suggested-offset-properties.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: greybus: spilib: fix use-after-free after deregistration" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: greybus: spilib: fix use-after-free after deregistration to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-greybus-spilib-fix-use-after-free-after-deregistration.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 770b03c2ca4aa44d226cf248f86aa23e546147d0 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Sun, 29 Oct 2017 13:01:33 +0100 Subject: staging: greybus: spilib: fix use-after-free after deregistration From: Johan Hovold <johan(a)kernel.org> commit 770b03c2ca4aa44d226cf248f86aa23e546147d0 upstream. Remove erroneous spi_master_put() after controller deregistration which would access the already freed spi controller. Note that spi_unregister_master() drops our only controller reference. Fixes: ba3e67001b42 ("greybus: SPI: convert to a gpbridge driver") Signed-off-by: Johan Hovold <johan(a)kernel.org> Reviewed-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Acked-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/greybus/spilib.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/drivers/staging/greybus/spilib.c +++ b/drivers/staging/greybus/spilib.c @@ -544,12 +544,15 @@ int gb_spilib_master_init(struct gb_conn return 0; -exit_spi_unregister: - spi_unregister_master(master); exit_spi_put: spi_master_put(master); return ret; + +exit_spi_unregister: + spi_unregister_master(master); + + return ret; } EXPORT_SYMBOL_GPL(gb_spilib_master_init); @@ -558,7 +561,6 @@ void gb_spilib_master_exit(struct gb_con struct spi_master *master = gb_connection_get_data(connection); spi_unregister_master(master); - spi_master_put(master); } EXPORT_SYMBOL_GPL(gb_spilib_master_exit); Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.14/usb-serial-qcserial-add-pid-vid-for-sierra-wireless-em7355-fw-update.patch queue-4.14/staging-greybus-spilib-fix-use-after-free-after-deregistration.patch queue-4.14/usb-serial-metro-usb-stop-i-o-after-failed-open.patch queue-4.14/usb-serial-change-dbc-debug-device-binding-id.patch queue-4.14/spi-fix-use-after-free-at-controller-deregistration.patch queue-4.14/usb-serial-garmin_gps-fix-i-o-after-failed-probe-and-remove.patch queue-4.14/usb-serial-garmin_gps-fix-memory-leak-on-probe-errors.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: ccree: fix 64 bit scatter/gather DMA ops" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: ccree: fix 64 bit scatter/gather DMA ops to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-ccree-fix-64-bit-scatter-gather-dma-ops.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e0b3f39092a1cff5548cbaf40096ec25e7721de6 Mon Sep 17 00:00:00 2001 From: Gilad Ben-Yossef <gilad(a)benyossef.com> Date: Mon, 30 Oct 2017 13:38:03 +0000 Subject: staging: ccree: fix 64 bit scatter/gather DMA ops From: Gilad Ben-Yossef <gilad(a)benyossef.com> commit e0b3f39092a1cff5548cbaf40096ec25e7721de6 upstream. Fix a wrong offset used in splitting a 64 DMA address to MSB/LSB parts needed for scatter/gather HW descriptors causing operations relying on them to fail on 64 bit platforms. Fixes: c6f7f2f4591f ("staging: ccree: refactor LLI access macros") Reported-by: Stuart Yoder <stuart.yoder(a)arm.com> Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/ccree/cc_lli_defs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/staging/ccree/cc_lli_defs.h +++ b/drivers/staging/ccree/cc_lli_defs.h @@ -59,7 +59,7 @@ static inline void cc_lli_set_addr(u32 * lli_p[LLI_WORD0_OFFSET] = (addr & U32_MAX); #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT lli_p[LLI_WORD1_OFFSET] &= ~LLI_HADDR_MASK; - lli_p[LLI_WORD1_OFFSET] |= FIELD_PREP(LLI_HADDR_MASK, (addr >> 16)); + lli_p[LLI_WORD1_OFFSET] |= FIELD_PREP(LLI_HADDR_MASK, (addr >> 32)); #endif /* CONFIG_ARCH_DMA_ADDR_T_64BIT */ } Patches currently in stable-queue which might be from gilad(a)benyossef.com are queue-4.14/staging-ccree-fix-64-bit-scatter-gather-dma-ops.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "spi: fix use-after-free at controller deregistration" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled spi: fix use-after-free at controller deregistration to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: spi-fix-use-after-free-at-controller-deregistration.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 67f7b2781fafcc0f52464880154b320fea1ae982 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Mon, 30 Oct 2017 11:35:25 +0100 Subject: spi: fix use-after-free at controller deregistration From: Johan Hovold <johan(a)kernel.org> commit 67f7b2781fafcc0f52464880154b320fea1ae982 upstream. The controller is typically freed as part of device_unregister() so store the bus id before deregistration to avoid use-after-free when the id is later released. Fixes: 9b61e302210e ("spi: Pick spi bus number from Linux idr or spi alias") Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/spi/spi.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -2245,11 +2245,12 @@ static int __unregister(struct device *d void spi_unregister_controller(struct spi_controller *ctlr) { struct spi_controller *found; + int id = ctlr->bus_num; int dummy; /* First make sure that this controller was ever added */ mutex_lock(&board_lock); - found = idr_find(&spi_master_idr, ctlr->bus_num); + found = idr_find(&spi_master_idr, id); mutex_unlock(&board_lock); if (found != ctlr) { dev_dbg(&ctlr->dev, @@ -2269,7 +2270,7 @@ void spi_unregister_controller(struct sp device_unregister(&ctlr->dev); /* free bus id */ mutex_lock(&board_lock); - idr_remove(&spi_master_idr, ctlr->bus_num); + idr_remove(&spi_master_idr, id); mutex_unlock(&board_lock); } EXPORT_SYMBOL_GPL(spi_unregister_controller); Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.14/usb-serial-qcserial-add-pid-vid-for-sierra-wireless-em7355-fw-update.patch queue-4.14/staging-greybus-spilib-fix-use-after-free-after-deregistration.patch queue-4.14/usb-serial-metro-usb-stop-i-o-after-failed-open.patch queue-4.14/usb-serial-change-dbc-debug-device-binding-id.patch queue-4.14/spi-fix-use-after-free-at-controller-deregistration.patch queue-4.14/usb-serial-garmin_gps-fix-i-o-after-failed-probe-and-remove.patch queue-4.14/usb-serial-garmin_gps-fix-memory-leak-on-probe-errors.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "rpmsg: glink: Add missing MODULE_LICENSE" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rpmsg: glink: Add missing MODULE_LICENSE to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rpmsg-glink-add-missing-module_license.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1e0d5615bbc37deb7732491798abccf8d3c3d244 Mon Sep 17 00:00:00 2001 From: Bjorn Andersson <bjorn.andersson(a)linaro.org> Date: Tue, 14 Nov 2017 21:45:34 -0800 Subject: rpmsg: glink: Add missing MODULE_LICENSE From: Bjorn Andersson <bjorn.andersson(a)linaro.org> commit 1e0d5615bbc37deb7732491798abccf8d3c3d244 upstream. The qcom_glink_native driver is missing a MODULE_LICENSE(), correct this. Fixes: 835764ddd9af ("rpmsg: glink: Move the common glink protocol implementation to glink_native.c") Reported-by: Randy Dunlap <rdunlap(a)infradead.org> Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/rpmsg/qcom_glink_native.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/rpmsg/qcom_glink_native.c +++ b/drivers/rpmsg/qcom_glink_native.c @@ -1616,3 +1616,6 @@ void qcom_glink_native_unregister(struct device_unregister(glink->dev); } EXPORT_SYMBOL_GPL(qcom_glink_native_unregister); + +MODULE_DESCRIPTION("Qualcomm GLINK driver"); +MODULE_LICENSE("GPL v2"); Patches currently in stable-queue which might be from bjorn.andersson(a)linaro.org are queue-4.14/rpmsg-glink-add-missing-module_license.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: wilc1000: Fix bssid buffer offset in Txq" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: wilc1000: Fix bssid buffer offset in Txq to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-wilc1000-fix-bssid-buffer-offset-in-txq.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1bbf6a6d4091affb27ec0a19d7aa7887ce72f610 Mon Sep 17 00:00:00 2001 From: Aditya Shankar <aditya.shankar(a)microchip.com> Date: Fri, 3 Nov 2017 14:26:27 +0530 Subject: staging: wilc1000: Fix bssid buffer offset in Txq From: Aditya Shankar <aditya.shankar(a)microchip.com> commit 1bbf6a6d4091affb27ec0a19d7aa7887ce72f610 upstream. Commit 46949b48568b ("staging: wilc1000: New cfg packet format in handle_set_wfi_drv_handler") updated the frame format sent from host to the firmware. The code to update the bssid offset in the new frame was part of a second patch in the series which did not make it in and thus causes connection problems after associating to an AP. This fix adds the proper offset of the bssid value in the Tx queue buffer to fix the connection issues. Fixes: 46949b48568b ("staging: wilc1000: New cfg packet format in handle_set_wfi_drv_handler") Signed-off-by: Aditya Shankar <Aditya.Shankar(a)microchip.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/wilc1000/wilc_wlan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/staging/wilc1000/wilc_wlan.c +++ b/drivers/staging/wilc1000/wilc_wlan.c @@ -714,7 +714,7 @@ int wilc_wlan_handle_txq(struct net_devi char *bssid = ((struct tx_complete_data *)(tqe->priv))->bssid; buffer_offset = ETH_ETHERNET_HDR_OFFSET; - memcpy(&txb[offset + 4], bssid, 6); + memcpy(&txb[offset + 8], bssid, 6); } else { buffer_offset = HOST_HDR_OFFSET; } Patches currently in stable-queue which might be from aditya.shankar(a)microchip.com are queue-4.13/staging-wilc1000-fix-bssid-buffer-offset-in-txq.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: vboxvideo: Fix reporting invalid suggested-offset-properties" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: vboxvideo: Fix reporting invalid suggested-offset-properties to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-vboxvideo-fix-reporting-invalid-suggested-offset-properties.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ce10d7b4e8e3574b9616e54a09d64521b9aeb8b6 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Thu, 12 Oct 2017 20:10:25 +0200 Subject: staging: vboxvideo: Fix reporting invalid suggested-offset-properties From: Hans de Goede <hdegoede(a)redhat.com> commit ce10d7b4e8e3574b9616e54a09d64521b9aeb8b6 upstream. The x and y hints receives from the host are unsigned 32 bit integers and they get set to -1 (0xffffffff) when invalid. Before this commit the vboxvideo driver was storing them in an u16 causing the -1 to be truncated to 65535 which, once reported to userspace, was breaking gnome 3.26+ in Wayland mode. This commit stores the host values in 32 bit variables, removing the truncation and checks for -1, replacing it with 0 as -1 is not a valid suggested-offset-property value. Likewise the properties are now initialized to 0 instead of -1, since -1 is not a valid value. This fixes gnome 3.26+ in Wayland mode not working with the vboxvideo driver. Reported-by: Gianfranco Costamagna <locutusofborg(a)debian.org> Cc: Michael Thayer <michael.thayer(a)oracle.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/vboxvideo/vbox_drv.h | 8 ++++---- drivers/staging/vboxvideo/vbox_irq.c | 4 ++-- drivers/staging/vboxvideo/vbox_mode.c | 26 ++++++++++++++++++-------- 3 files changed, 24 insertions(+), 14 deletions(-) --- a/drivers/staging/vboxvideo/vbox_drv.h +++ b/drivers/staging/vboxvideo/vbox_drv.h @@ -137,8 +137,8 @@ struct vbox_connector { char name[32]; struct vbox_crtc *vbox_crtc; struct { - u16 width; - u16 height; + u32 width; + u32 height; bool disconnected; } mode_hint; }; @@ -150,8 +150,8 @@ struct vbox_crtc { unsigned int crtc_id; u32 fb_offset; bool cursor_enabled; - u16 x_hint; - u16 y_hint; + u32 x_hint; + u32 y_hint; }; struct vbox_encoder { --- a/drivers/staging/vboxvideo/vbox_irq.c +++ b/drivers/staging/vboxvideo/vbox_irq.c @@ -150,8 +150,8 @@ static void vbox_update_mode_hints(struc disconnected = !(hints->enabled); crtc_id = vbox_conn->vbox_crtc->crtc_id; - vbox_conn->mode_hint.width = hints->cx & 0x8fff; - vbox_conn->mode_hint.height = hints->cy & 0x8fff; + vbox_conn->mode_hint.width = hints->cx; + vbox_conn->mode_hint.height = hints->cy; vbox_conn->vbox_crtc->x_hint = hints->dx; vbox_conn->vbox_crtc->y_hint = hints->dy; vbox_conn->mode_hint.disconnected = disconnected; --- a/drivers/staging/vboxvideo/vbox_mode.c +++ b/drivers/staging/vboxvideo/vbox_mode.c @@ -560,12 +560,22 @@ static int vbox_get_modes(struct drm_con ++num_modes; } vbox_set_edid(connector, preferred_width, preferred_height); - drm_object_property_set_value( - &connector->base, vbox->dev->mode_config.suggested_x_property, - vbox_connector->vbox_crtc->x_hint); - drm_object_property_set_value( - &connector->base, vbox->dev->mode_config.suggested_y_property, - vbox_connector->vbox_crtc->y_hint); + + if (vbox_connector->vbox_crtc->x_hint != -1) + drm_object_property_set_value(&connector->base, + vbox->dev->mode_config.suggested_x_property, + vbox_connector->vbox_crtc->x_hint); + else + drm_object_property_set_value(&connector->base, + vbox->dev->mode_config.suggested_x_property, 0); + + if (vbox_connector->vbox_crtc->y_hint != -1) + drm_object_property_set_value(&connector->base, + vbox->dev->mode_config.suggested_y_property, + vbox_connector->vbox_crtc->y_hint); + else + drm_object_property_set_value(&connector->base, + vbox->dev->mode_config.suggested_y_property, 0); return num_modes; } @@ -650,9 +660,9 @@ static int vbox_connector_init(struct dr drm_mode_create_suggested_offset_properties(dev); drm_object_attach_property(&connector->base, - dev->mode_config.suggested_x_property, -1); + dev->mode_config.suggested_x_property, 0); drm_object_attach_property(&connector->base, - dev->mode_config.suggested_y_property, -1); + dev->mode_config.suggested_y_property, 0); drm_connector_register(connector); drm_mode_connector_attach_encoder(connector, encoder); Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.13/staging-rtl8188eu-revert-4-commits-breaking-arp.patch queue-4.13/platform-x86-peaq-wmi-add-dmi-check-before-binding-to-the-wmi-interface.patch queue-4.13/platform-x86-peaq_wmi-fix-missing-terminating-entry-for-peaq_dmi_table.patch queue-4.13/staging-vboxvideo-fix-reporting-invalid-suggested-offset-properties.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: sm750fb: Fix parameter mistake in poke32" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: sm750fb: Fix parameter mistake in poke32 to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-sm750fb-fix-parameter-mistake-in-poke32.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 16808dcf605e6302319a8c3266789b76d4c0983b Mon Sep 17 00:00:00 2001 From: Huacai Chen <chenhc(a)lemote.com> Date: Mon, 6 Nov 2017 08:43:03 +0800 Subject: staging: sm750fb: Fix parameter mistake in poke32 From: Huacai Chen <chenhc(a)lemote.com> commit 16808dcf605e6302319a8c3266789b76d4c0983b upstream. In commit c075b6f2d357ea9 ("staging: sm750fb: Replace POKE32 and PEEK32 by inline functions"), POKE32 has been replaced by the inline function poke32. But it exchange the "addr" and "data" parameters by mistake, so fix it. Fixes: c075b6f2d357ea9 ("staging: sm750fb: Replace POKE32 and PEEK32 by inline functions"), Signed-off-by: Huacai Chen <chenhc(a)lemote.com> Signed-off-by: Liangliang Huang <huangll(a)lemote.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/sm750fb/ddk750_chip.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/staging/sm750fb/ddk750_chip.h +++ b/drivers/staging/sm750fb/ddk750_chip.h @@ -17,7 +17,7 @@ static inline u32 peek32(u32 addr) return readl(addr + mmio750); } -static inline void poke32(u32 data, u32 addr) +static inline void poke32(u32 addr, u32 data) { writel(data, addr + mmio750); } Patches currently in stable-queue which might be from chenhc(a)lemote.com are queue-4.13/staging-sm750fb-fix-parameter-mistake-in-poke32.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: rtl8188eu: Revert 4 commits breaking ARP" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: rtl8188eu: Revert 4 commits breaking ARP to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-rtl8188eu-revert-4-commits-breaking-arp.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 66d32fdcbf03851724a8b551d490ae1ddfe6eef2 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Thu, 2 Nov 2017 10:30:13 +0100 Subject: staging: rtl8188eu: Revert 4 commits breaking ARP From: Hans de Goede <hdegoede(a)redhat.com> commit 66d32fdcbf03851724a8b551d490ae1ddfe6eef2 upstream. Commit 2ba8444c97b1 ("staging:r8188eu: move IV/ICV trimming into decrypt() and also place it after rtl88eu_mon_recv_hook()") breaks ARP. After this commit ssh-ing to a laptop with r8188eu wifi no longer works if the machine connecting has never communicated with the laptop before. This is 100% reproducable using "arp -d <ipv4> && ssh <ipv4>" to ssh to a laptop with r8188eu wifi. This commit reverts 4 commits in total: 1. Commit 79650ffde38e ("staging:r8188eu: trim IV/ICV fields in validate_recv_data_frame()") This commit depends on 2 of the other commits being reverted. 2. Commit 02b19b4c4920 ("staging:r8188eu: inline unprotect_frame() in mon_recv_decrypted_recv()") The inline code is wrong the un-inlined version contains: if (skb->len < hdr_len + iv_len + icv_len) return; ... Where as the inline-ed code introduced by this commit does: if (skb->len < hdr_len + iv_len + icv_len) { ... Note the same check, but now to actually continue doing ... instead of to not do it, so this commit is no good. 3. Commit d86e16da6a5d ("staging:r8188eu: use different mon_recv_decrypted() inside rtl88eu_mon_recv_hook() and rtl88eu_mon_xmit_hook().") This commit introduced a 1:1 copy of a function so that one of the 2 copies can be modified in the 2 commits we're already reverting. 4. Commit 2ba8444c97b1 ("staging:r8188eu: move IV/ICV trimming into decrypt() and also place it after rtl88eu_mon_recv_hook()") This is the commit actually breaking ARP. Note this commit is a straight-forward squash of the revert of these 4 commits, without any changes. Cc: Ivan Safonov <insafonov(a)gmail.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/rtl8188eu/core/rtw_recv.c | 83 ++++++++++++++++++------------ drivers/staging/rtl8188eu/os_dep/mon.c | 34 +----------- 2 files changed, 55 insertions(+), 62 deletions(-) --- a/drivers/staging/rtl8188eu/core/rtw_recv.c +++ b/drivers/staging/rtl8188eu/core/rtw_recv.c @@ -259,10 +259,12 @@ static int recvframe_chkmic(struct adapt } /* icv_len included the mic code */ - datalen = precvframe->pkt->len-prxattrib->hdrlen - 8; + datalen = precvframe->pkt->len-prxattrib->hdrlen - + prxattrib->iv_len-prxattrib->icv_len-8; pframe = precvframe->pkt->data; - payload = pframe+prxattrib->hdrlen; + payload = pframe+prxattrib->hdrlen+prxattrib->iv_len; + RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("\n prxattrib->iv_len=%d prxattrib->icv_len=%d\n", prxattrib->iv_len, prxattrib->icv_len)); rtw_seccalctkipmic(mickey, pframe, payload, datalen, &miccode[0], (unsigned char)prxattrib->priority); /* care the length of the data */ @@ -407,15 +409,9 @@ static struct recv_frame *decryptor(stru default: break; } - if (res != _FAIL) { - memmove(precv_frame->pkt->data + precv_frame->attrib.iv_len, precv_frame->pkt->data, precv_frame->attrib.hdrlen); - skb_pull(precv_frame->pkt, precv_frame->attrib.iv_len); - skb_trim(precv_frame->pkt, precv_frame->pkt->len - precv_frame->attrib.icv_len); - } } else if (prxattrib->bdecrypted == 1 && prxattrib->encrypt > 0 && - (psecuritypriv->busetkipkey == 1 || prxattrib->encrypt != _TKIP_)) { - psecuritypriv->hw_decrypted = true; - } + (psecuritypriv->busetkipkey == 1 || prxattrib->encrypt != _TKIP_)) + psecuritypriv->hw_decrypted = true; if (res == _FAIL) { rtw_free_recvframe(return_packet, &padapter->recvpriv.free_recv_queue); @@ -456,7 +452,7 @@ static struct recv_frame *portctrl(struc if (auth_alg == 2) { /* get ether_type */ - ptr = ptr + pfhdr->attrib.hdrlen + LLC_HEADER_SIZE; + ptr = ptr + pfhdr->attrib.hdrlen + LLC_HEADER_SIZE + pfhdr->attrib.iv_len; memcpy(&be_tmp, ptr, 2); ether_type = ntohs(be_tmp); @@ -1138,8 +1134,6 @@ static int validate_recv_data_frame(stru } if (pattrib->privacy) { - struct sk_buff *skb = precv_frame->pkt; - RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("validate_recv_data_frame:pattrib->privacy=%x\n", pattrib->privacy)); RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("\n ^^^^^^^^^^^IS_MCAST(pattrib->ra(0x%02x))=%d^^^^^^^^^^^^^^^6\n", pattrib->ra[0], IS_MCAST(pattrib->ra))); @@ -1148,13 +1142,6 @@ static int validate_recv_data_frame(stru RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("\n pattrib->encrypt=%d\n", pattrib->encrypt)); SET_ICE_IV_LEN(pattrib->iv_len, pattrib->icv_len, pattrib->encrypt); - - if (pattrib->bdecrypted == 1 && pattrib->encrypt > 0) { - memmove(skb->data + pattrib->iv_len, - skb->data, pattrib->hdrlen); - skb_pull(skb, pattrib->iv_len); - skb_trim(skb, skb->len - pattrib->icv_len); - } } else { pattrib->encrypt = 0; pattrib->iv_len = 0; @@ -1274,7 +1261,6 @@ static int validate_recv_frame(struct ad * Hence forward the frame to the monitor anyway to preserve the order * in which frames were received. */ - rtl88eu_mon_recv_hook(adapter->pmondev, precv_frame); exit: @@ -1296,8 +1282,11 @@ static int wlanhdr_to_ethhdr(struct recv u8 *ptr = precvframe->pkt->data; struct rx_pkt_attrib *pattrib = &precvframe->attrib; - psnap = (struct ieee80211_snap_hdr *)(ptr+pattrib->hdrlen); - psnap_type = ptr+pattrib->hdrlen + SNAP_SIZE; + if (pattrib->encrypt) + skb_trim(precvframe->pkt, precvframe->pkt->len - pattrib->icv_len); + + psnap = (struct ieee80211_snap_hdr *)(ptr+pattrib->hdrlen + pattrib->iv_len); + psnap_type = ptr+pattrib->hdrlen + pattrib->iv_len+SNAP_SIZE; /* convert hdr + possible LLC headers into Ethernet header */ if ((!memcmp(psnap, rtw_rfc1042_header, SNAP_SIZE) && (!memcmp(psnap_type, SNAP_ETH_TYPE_IPX, 2) == false) && @@ -1310,9 +1299,12 @@ static int wlanhdr_to_ethhdr(struct recv bsnaphdr = false; } - rmv_len = pattrib->hdrlen + (bsnaphdr ? SNAP_SIZE : 0); + rmv_len = pattrib->hdrlen + pattrib->iv_len + (bsnaphdr ? SNAP_SIZE : 0); len = precvframe->pkt->len - rmv_len; + RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, + ("\n===pattrib->hdrlen: %x, pattrib->iv_len:%x===\n\n", pattrib->hdrlen, pattrib->iv_len)); + memcpy(&be_tmp, ptr+rmv_len, 2); eth_type = ntohs(be_tmp); /* pattrib->ether_type */ pattrib->eth_type = eth_type; @@ -1337,6 +1329,7 @@ static struct recv_frame *recvframe_defr struct __queue *defrag_q) { struct list_head *plist, *phead; + u8 wlanhdr_offset; u8 curfragnum; struct recv_frame *pfhdr, *pnfhdr; struct recv_frame *prframe, *pnextrframe; @@ -1385,7 +1378,12 @@ static struct recv_frame *recvframe_defr /* copy the 2nd~n fragment frame's payload to the first fragment */ /* get the 2nd~last fragment frame's payload */ - skb_pull(pnextrframe->pkt, pnfhdr->attrib.hdrlen); + wlanhdr_offset = pnfhdr->attrib.hdrlen + pnfhdr->attrib.iv_len; + + skb_pull(pnextrframe->pkt, wlanhdr_offset); + + /* append to first fragment frame's tail (if privacy frame, pull the ICV) */ + skb_trim(prframe->pkt, prframe->pkt->len - pfhdr->attrib.icv_len); /* memcpy */ memcpy(skb_tail_pointer(pfhdr->pkt), pnfhdr->pkt->data, @@ -1393,7 +1391,7 @@ static struct recv_frame *recvframe_defr skb_put(prframe->pkt, pnfhdr->pkt->len); - pfhdr->attrib.icv_len = 0; + pfhdr->attrib.icv_len = pnfhdr->attrib.icv_len; plist = plist->next; } @@ -1519,6 +1517,11 @@ static int amsdu_to_msdu(struct adapter nr_subframes = 0; pattrib = &prframe->attrib; + skb_pull(prframe->pkt, prframe->attrib.hdrlen); + + if (prframe->attrib.iv_len > 0) + skb_pull(prframe->pkt, prframe->attrib.iv_len); + a_len = prframe->pkt->len; pdata = prframe->pkt->data; @@ -1887,6 +1890,24 @@ static int process_recv_indicatepkts(str return retval; } +static int recv_func_prehandle(struct adapter *padapter, + struct recv_frame *rframe) +{ + int ret = _SUCCESS; + struct __queue *pfree_recv_queue = &padapter->recvpriv.free_recv_queue; + + /* check the frame crtl field and decache */ + ret = validate_recv_frame(padapter, rframe); + if (ret != _SUCCESS) { + RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("recv_func: validate_recv_frame fail! drop pkt\n")); + rtw_free_recvframe(rframe, pfree_recv_queue);/* free this recv_frame */ + goto exit; + } + +exit: + return ret; +} + static int recv_func_posthandle(struct adapter *padapter, struct recv_frame *prframe) { @@ -1939,7 +1960,6 @@ static int recv_func(struct adapter *pad struct rx_pkt_attrib *prxattrib = &rframe->attrib; struct security_priv *psecuritypriv = &padapter->securitypriv; struct mlme_priv *mlmepriv = &padapter->mlmepriv; - struct __queue *pfree_recv_queue = &padapter->recvpriv.free_recv_queue; /* check if need to handle uc_swdec_pending_queue*/ if (check_fwstate(mlmepriv, WIFI_STATION_STATE) && psecuritypriv->busetkipkey) { @@ -1951,12 +1971,9 @@ static int recv_func(struct adapter *pad } } - /* check the frame crtl field and decache */ - ret = validate_recv_frame(padapter, rframe); - if (ret != _SUCCESS) { - RT_TRACE(_module_rtl871x_recv_c_, _drv_info_, ("recv_func: validate_recv_frame fail! drop pkt\n")); - rtw_free_recvframe(rframe, pfree_recv_queue);/* free this recv_frame */ - } else { + ret = recv_func_prehandle(padapter, rframe); + + if (ret == _SUCCESS) { /* check if need to enqueue into uc_swdec_pending_queue*/ if (check_fwstate(mlmepriv, WIFI_STATION_STATE) && !IS_MCAST(prxattrib->ra) && prxattrib->encrypt > 0 && --- a/drivers/staging/rtl8188eu/os_dep/mon.c +++ b/drivers/staging/rtl8188eu/os_dep/mon.c @@ -66,34 +66,6 @@ static void mon_recv_decrypted(struct ne netif_rx(skb); } -static void mon_recv_decrypted_recv(struct net_device *dev, const u8 *data, - int data_len) -{ - struct sk_buff *skb; - struct ieee80211_hdr *hdr; - int hdr_len; - - skb = netdev_alloc_skb(dev, data_len); - if (!skb) - return; - memcpy(skb_put(skb, data_len), data, data_len); - - /* - * Frame data is not encrypted. Strip off protection so - * userspace doesn't think that it is. - */ - - hdr = (struct ieee80211_hdr *)skb->data; - hdr_len = ieee80211_hdrlen(hdr->frame_control); - - if (ieee80211_has_protected(hdr->frame_control)) - hdr->frame_control &= ~cpu_to_le16(IEEE80211_FCTL_PROTECTED); - - skb->ip_summed = CHECKSUM_UNNECESSARY; - skb->protocol = eth_type_trans(skb, dev); - netif_rx(skb); -} - static void mon_recv_encrypted(struct net_device *dev, const u8 *data, int data_len) { @@ -110,6 +82,7 @@ static void mon_recv_encrypted(struct ne void rtl88eu_mon_recv_hook(struct net_device *dev, struct recv_frame *frame) { struct rx_pkt_attrib *attr; + int iv_len, icv_len; int data_len; u8 *data; @@ -122,8 +95,11 @@ void rtl88eu_mon_recv_hook(struct net_de data = frame->pkt->data; data_len = frame->pkt->len; + /* Broadcast and multicast frames don't have attr->{iv,icv}_len set */ + SET_ICE_IV_LEN(iv_len, icv_len, attr->encrypt); + if (attr->bdecrypted) - mon_recv_decrypted_recv(dev, data, data_len); + mon_recv_decrypted(dev, data, data_len, iv_len, icv_len); else mon_recv_encrypted(dev, data, data_len); } Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.13/staging-rtl8188eu-revert-4-commits-breaking-arp.patch queue-4.13/platform-x86-peaq-wmi-add-dmi-check-before-binding-to-the-wmi-interface.patch queue-4.13/platform-x86-peaq_wmi-fix-missing-terminating-entry-for-peaq_dmi_table.patch queue-4.13/staging-vboxvideo-fix-reporting-invalid-suggested-offset-properties.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: greybus: spilib: fix use-after-free after deregistration" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: greybus: spilib: fix use-after-free after deregistration to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-greybus-spilib-fix-use-after-free-after-deregistration.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 770b03c2ca4aa44d226cf248f86aa23e546147d0 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Sun, 29 Oct 2017 13:01:33 +0100 Subject: staging: greybus: spilib: fix use-after-free after deregistration From: Johan Hovold <johan(a)kernel.org> commit 770b03c2ca4aa44d226cf248f86aa23e546147d0 upstream. Remove erroneous spi_master_put() after controller deregistration which would access the already freed spi controller. Note that spi_unregister_master() drops our only controller reference. Fixes: ba3e67001b42 ("greybus: SPI: convert to a gpbridge driver") Signed-off-by: Johan Hovold <johan(a)kernel.org> Reviewed-by: Rui Miguel Silva <rmfrfs(a)gmail.com> Acked-by: Viresh Kumar <viresh.kumar(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/greybus/spilib.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- a/drivers/staging/greybus/spilib.c +++ b/drivers/staging/greybus/spilib.c @@ -544,12 +544,15 @@ int gb_spilib_master_init(struct gb_conn return 0; -exit_spi_unregister: - spi_unregister_master(master); exit_spi_put: spi_master_put(master); return ret; + +exit_spi_unregister: + spi_unregister_master(master); + + return ret; } EXPORT_SYMBOL_GPL(gb_spilib_master_init); @@ -558,7 +561,6 @@ void gb_spilib_master_exit(struct gb_con struct spi_master *master = gb_connection_get_data(connection); spi_unregister_master(master); - spi_master_put(master); } EXPORT_SYMBOL_GPL(gb_spilib_master_exit); Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.13/usb-serial-qcserial-add-pid-vid-for-sierra-wireless-em7355-fw-update.patch queue-4.13/staging-greybus-spilib-fix-use-after-free-after-deregistration.patch queue-4.13/usb-serial-metro-usb-stop-i-o-after-failed-open.patch queue-4.13/usb-serial-change-dbc-debug-device-binding-id.patch queue-4.13/usb-serial-garmin_gps-fix-i-o-after-failed-probe-and-remove.patch queue-4.13/usb-serial-garmin_gps-fix-memory-leak-on-probe-errors.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "staging: ccree: fix 64 bit scatter/gather DMA ops" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: ccree: fix 64 bit scatter/gather DMA ops to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: staging-ccree-fix-64-bit-scatter-gather-dma-ops.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e0b3f39092a1cff5548cbaf40096ec25e7721de6 Mon Sep 17 00:00:00 2001 From: Gilad Ben-Yossef <gilad(a)benyossef.com> Date: Mon, 30 Oct 2017 13:38:03 +0000 Subject: staging: ccree: fix 64 bit scatter/gather DMA ops From: Gilad Ben-Yossef <gilad(a)benyossef.com> commit e0b3f39092a1cff5548cbaf40096ec25e7721de6 upstream. Fix a wrong offset used in splitting a 64 DMA address to MSB/LSB parts needed for scatter/gather HW descriptors causing operations relying on them to fail on 64 bit platforms. Fixes: c6f7f2f4591f ("staging: ccree: refactor LLI access macros") Reported-by: Stuart Yoder <stuart.yoder(a)arm.com> Signed-off-by: Gilad Ben-Yossef <gilad(a)benyossef.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/ccree/cc_lli_defs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/staging/ccree/cc_lli_defs.h +++ b/drivers/staging/ccree/cc_lli_defs.h @@ -59,7 +59,7 @@ static inline void cc_lli_set_addr(u32 * lli_p[LLI_WORD0_OFFSET] = (addr & U32_MAX); #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT lli_p[LLI_WORD1_OFFSET] &= ~LLI_HADDR_MASK; - lli_p[LLI_WORD1_OFFSET] |= FIELD_PREP(LLI_HADDR_MASK, (addr >> 16)); + lli_p[LLI_WORD1_OFFSET] |= FIELD_PREP(LLI_HADDR_MASK, (addr >> 32)); #endif /* CONFIG_ARCH_DMA_ADDR_T_64BIT */ } Patches currently in stable-queue which might be from gilad(a)benyossef.com are queue-4.13/staging-ccree-fix-64-bit-scatter-gather-dma-ops.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "brcmfmac: don't preset all channels as disabled" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled brcmfmac: don't preset all channels as disabled to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: brcmfmac-don-t-preset-all-channels-as-disabled.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 9ea0c307609fd20e03f53546b9cefbb20b96785d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <rafal(a)milecki.pl> Date: Sat, 7 Jan 2017 21:36:04 +0100 Subject: brcmfmac: don't preset all channels as disabled MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Rafał Miłecki <rafal(a)milecki.pl> commit 9ea0c307609fd20e03f53546b9cefbb20b96785d upstream. During init we take care of regulatory stuff by disabling all unavailable channels (see brcmf_construct_chaninfo) so this predisabling them is not really required (and this patch won't change any behavior). It will on the other hand allow more detailed runtime control over channels which is the main reason for this change. Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Cc: Lambdadroid <lambdadroid(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 2 -- 1 file changed, 2 deletions(-) --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c @@ -147,7 +147,6 @@ static struct ieee80211_rate __wl_rates[ .band = NL80211_BAND_2GHZ, \ .center_freq = (_freq), \ .hw_value = (_channel), \ - .flags = IEEE80211_CHAN_DISABLED, \ .max_antenna_gain = 0, \ .max_power = 30, \ } @@ -156,7 +155,6 @@ static struct ieee80211_rate __wl_rates[ .band = NL80211_BAND_5GHZ, \ .center_freq = 5000 + (5 * (_channel)), \ .hw_value = (_channel), \ - .flags = IEEE80211_CHAN_DISABLED, \ .max_antenna_gain = 0, \ .max_power = 30, \ } Patches currently in stable-queue which might be from rafal(a)milecki.pl are queue-4.9/brcmfmac-don-t-preset-all-channels-as-disabled.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] 4.9.62 breaks brcmfmac WiFi network scan

by Lambdadroid

Hi, I just upgraded from 4.9.61 to 4.9.63 and noticed that there are no longer any WiFi networks found after upgrading. After looking through the patches, it seems to be this brcmfmac commit from 4.9.62. Reverting it fixes the WiFi network scan. be5125d4fa9e: brcmfmac: setup wiphy bands after registering it first However, looking further at the patch, it seems like it was submitted together with another patch that wasn't applied to 4.9: 9ea0c307609f: brcmfmac: don't preset all channels as disabled Applying this patch additionally instead of reverting the broken patch seems to fix the issue as well. Either way works. I'm not sure why only one of the patches were applied to stable. They were submitted together on linux-wireless: http://www.spinics.net/lists/linux-wireless/msg157813.html For reference, I tested with a BCM43362 on Android and Arch Linux. Both didn't show any WiFi networks anymore after the update to 4.9.62+. Thanks!

7 years, 11 months

2
1
0 0

[Linux-stable-mirror] Patch "x86/MCE/AMD: Always give panic severity for UC errors in kernel context" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/MCE/AMD: Always give panic severity for UC errors in kernel context to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-mce-amd-always-give-panic-severity-for-uc-errors-in-kernel-context.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d65dfc81bb3894fdb68cbc74bbf5fb48d2354071 Mon Sep 17 00:00:00 2001 From: Yazen Ghannam <yazen.ghannam(a)amd.com> Date: Mon, 6 Nov 2017 18:46:32 +0100 Subject: x86/MCE/AMD: Always give panic severity for UC errors in kernel context From: Yazen Ghannam <yazen.ghannam(a)amd.com> commit d65dfc81bb3894fdb68cbc74bbf5fb48d2354071 upstream. The AMD severity grading function was introduced in kernel 4.1. The current logic can possibly give MCE_AR_SEVERITY for uncorrectable errors in kernel context. The system may then get stuck in a loop as memory_failure() will try to handle the bad kernel memory and find it busy. Return MCE_PANIC_SEVERITY for all UC errors IN_KERNEL context on AMD systems. After: b2f9d678e28c ("x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries") was accepted in v4.6, this issue was masked because of the tail-end attempt at kernel mode recovery in the #MC handler. However, uncorrectable errors IN_KERNEL context should always be considered unrecoverable and cause a panic. Signed-off-by: Yazen Ghannam <yazen.ghannam(a)amd.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Tony Luck <tony.luck(a)intel.com> Cc: linux-edac <linux-edac(a)vger.kernel.org> Fixes: bf80bbd7dcf5 (x86/mce: Add an AMD severities-grading function) Link: http://lkml.kernel.org/r/20171106174633.13576-1-bp@alien8.de Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/mcheck/mce-severity.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) --- a/arch/x86/kernel/cpu/mcheck/mce-severity.c +++ b/arch/x86/kernel/cpu/mcheck/mce-severity.c @@ -245,6 +245,9 @@ static int mce_severity_amd(struct mce * if (m->status & MCI_STATUS_UC) { + if (ctx == IN_KERNEL) + return MCE_PANIC_SEVERITY; + /* * On older systems where overflow_recov flag is not present, we * should simply panic if an error overflow occurs. If @@ -255,10 +258,6 @@ static int mce_severity_amd(struct mce * if (mce_flags.smca) return mce_severity_amd_smca(m, ctx); - /* software can try to contain */ - if (!(m->mcgstatus & MCG_STATUS_RIPV) && (ctx == IN_KERNEL)) - return MCE_PANIC_SEVERITY; - /* kill current process */ return MCE_AR_SEVERITY; } else { Patches currently in stable-queue which might be from yazen.ghannam(a)amd.com are queue-4.14/x86-mce-amd-always-give-panic-severity-for-uc-errors-in-kernel-context.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "selftests/x86/protection_keys: Fix syscall NR redefinition warnings" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/x86/protection_keys: Fix syscall NR redefinition warnings to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-x86-protection_keys-fix-syscall-nr-redefinition-warnings.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 693cb5580fdb026922363aa103add64b3ecd572e Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Sat, 4 Nov 2017 04:19:48 -0700 Subject: selftests/x86/protection_keys: Fix syscall NR redefinition warnings From: Andy Lutomirski <luto(a)kernel.org> commit 693cb5580fdb026922363aa103add64b3ecd572e upstream. On new enough glibc, the pkey syscalls numbers are available. Check first before defining them to avoid warnings like: protection_keys.c:198:0: warning: "SYS_pkey_alloc" redefined Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bpetkov(a)suse.de> Cc: Dave Hansen <dave.hansen(a)intel.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Link: http://lkml.kernel.org/r/1fbef53a9e6befb7165ff855fc1a7d4788a191d6.150979432… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/x86/protection_keys.c | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) --- a/tools/testing/selftests/x86/protection_keys.c +++ b/tools/testing/selftests/x86/protection_keys.c @@ -189,17 +189,29 @@ void lots_o_noops_around_write(int *writ #define u64 uint64_t #ifdef __i386__ -#define SYS_mprotect_key 380 -#define SYS_pkey_alloc 381 -#define SYS_pkey_free 382 + +#ifndef SYS_mprotect_key +# define SYS_mprotect_key 380 +#endif +#ifndef SYS_pkey_alloc +# define SYS_pkey_alloc 381 +# define SYS_pkey_free 382 +#endif #define REG_IP_IDX REG_EIP #define si_pkey_offset 0x14 + #else -#define SYS_mprotect_key 329 -#define SYS_pkey_alloc 330 -#define SYS_pkey_free 331 + +#ifndef SYS_mprotect_key +# define SYS_mprotect_key 329 +#endif +#ifndef SYS_pkey_alloc +# define SYS_pkey_alloc 330 +# define SYS_pkey_free 331 +#endif #define REG_IP_IDX REG_RIP #define si_pkey_offset 0x20 + #endif void dump_mem(void *dumpme, int len_bytes) Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.14/selftests-x86-protection_keys-fix-syscall-nr-redefinition-warnings.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "platform/x86: peaq_wmi: Fix missing terminating entry for peaq_dmi_table" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled platform/x86: peaq_wmi: Fix missing terminating entry for peaq_dmi_table to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: platform-x86-peaq_wmi-fix-missing-terminating-entry-for-peaq_dmi_table.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d6fa71f1c003fb2bc824276bb424a4171f9a717f Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Mon, 30 Oct 2017 14:07:37 +0100 Subject: platform/x86: peaq_wmi: Fix missing terminating entry for peaq_dmi_table From: Hans de Goede <hdegoede(a)redhat.com> commit d6fa71f1c003fb2bc824276bb424a4171f9a717f upstream. Add missing terminating entry to peaq_dmi_table. Fixes: 3b95206110a2 ("platform/x86: peaq-wmi: Add DMI check before ...") Reported-by: Fengguang Wu <fengguang.wu(a)intel.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/peaq-wmi.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/platform/x86/peaq-wmi.c +++ b/drivers/platform/x86/peaq-wmi.c @@ -73,6 +73,7 @@ static const struct dmi_system_id peaq_d DMI_MATCH(DMI_PRODUCT_NAME, "PEAQ PMM C1010 MD99187"), }, }, + {} }; static int __init peaq_wmi_init(void) Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.14/platform-x86-peaq-wmi-add-dmi-check-before-binding-to-the-wmi-interface.patch queue-4.14/platform-x86-peaq_wmi-fix-missing-terminating-entry-for-peaq_dmi_table.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "platform/x86: peaq-wmi: Add DMI check before binding to the WMI interface" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled platform/x86: peaq-wmi: Add DMI check before binding to the WMI interface to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: platform-x86-peaq-wmi-add-dmi-check-before-binding-to-the-wmi-interface.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3b95206110a2c13076c3a7fa8ddeae36c2dbcf42 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Thu, 5 Oct 2017 20:04:04 +0200 Subject: platform/x86: peaq-wmi: Add DMI check before binding to the WMI interface From: Hans de Goede <hdegoede(a)redhat.com> commit 3b95206110a2c13076c3a7fa8ddeae36c2dbcf42 upstream. It seems that the WMI GUID used by the PEAQ 2-in-1 WMI hotkeys is not as unique as a GUID should be and is used on some other devices too. This is causing spurious key-press reports on these other devices. This commits adds a DMI check to the PEAQ 2-in-1 WMI hotkeys driver to ensure that it is actually running on a PEAQ 2-in-1, fixing the spurious key-presses on these other devices. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1497861 BugLink: https://bugzilla.suse.com/attachment.cgi?id=743182 Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/peaq-wmi.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- a/drivers/platform/x86/peaq-wmi.c +++ b/drivers/platform/x86/peaq-wmi.c @@ -8,6 +8,7 @@ */ #include <linux/acpi.h> +#include <linux/dmi.h> #include <linux/input-polldev.h> #include <linux/kernel.h> #include <linux/module.h> @@ -64,8 +65,22 @@ static void peaq_wmi_poll(struct input_p } } +/* Some other devices (Shuttle XS35) use the same WMI GUID for other purposes */ +static const struct dmi_system_id peaq_dmi_table[] = { + { + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "PEAQ"), + DMI_MATCH(DMI_PRODUCT_NAME, "PEAQ PMM C1010 MD99187"), + }, + }, +}; + static int __init peaq_wmi_init(void) { + /* WMI GUID is not unique, also check for a DMI match */ + if (!dmi_check_system(peaq_dmi_table)) + return -ENODEV; + if (!wmi_has_guid(PEAQ_DOLBY_BUTTON_GUID)) return -ENODEV; @@ -86,6 +101,9 @@ static int __init peaq_wmi_init(void) static void __exit peaq_wmi_exit(void) { + if (!dmi_check_system(peaq_dmi_table)) + return; + if (!wmi_has_guid(PEAQ_DOLBY_BUTTON_GUID)) return; Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.14/platform-x86-peaq-wmi-add-dmi-check-before-binding-to-the-wmi-interface.patch queue-4.14/platform-x86-peaq_wmi-fix-missing-terminating-entry-for-peaq_dmi_table.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "HID: wacom: generic: Recognize WACOM_HID_WD_PEN as a type of pen collection" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled HID: wacom: generic: Recognize WACOM_HID_WD_PEN as a type of pen collection to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hid-wacom-generic-recognize-wacom_hid_wd_pen-as-a-type-of-pen-collection.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 885e89f601a52cc6fb025b009df58ba83d142734 Mon Sep 17 00:00:00 2001 From: Jason Gerecke <killertofu(a)gmail.com> Date: Wed, 18 Oct 2017 08:27:13 -0700 Subject: HID: wacom: generic: Recognize WACOM_HID_WD_PEN as a type of pen collection From: Jason Gerecke <killertofu(a)gmail.com> commit 885e89f601a52cc6fb025b009df58ba83d142734 upstream. The WACOM_PEN_FIELD macro is used to determine if a given HID field should be associated with pen input. This field includes several known collection types that Wacom pen data is contained in, but the WACOM_HID_WD_PEN application collection type is notably missing. This can result in fields within this kind of collection being completely ignored by the `wacom_usage_mapping` function, preventing the later '*_event' functions from being notified about changes to their value. Fixes: c9c095874a ("HID: wacom: generic: Support and use 'Custom HID' mode and usages") Fixes: ac2423c975 ("HID: wacom: generic: add vendor defined touch") Reviewed-by: Ping Cheng <ping.cheng(a)wacom.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com> Signed-off-by: Jason Gerecke <jason.gerecke(a)wacom.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hid/wacom_wac.h | 1 + 1 file changed, 1 insertion(+) --- a/drivers/hid/wacom_wac.h +++ b/drivers/hid/wacom_wac.h @@ -166,6 +166,7 @@ ((f)->physical == HID_DG_PEN) || \ ((f)->application == HID_DG_PEN) || \ ((f)->application == HID_DG_DIGITIZER) || \ + ((f)->application == WACOM_HID_WD_PEN) || \ ((f)->application == WACOM_HID_WD_DIGITIZER) || \ ((f)->application == WACOM_HID_G9_PEN) || \ ((f)->application == WACOM_HID_G11_PEN)) Patches currently in stable-queue which might be from killertofu(a)gmail.com are queue-4.14/hid-wacom-generic-recognize-wacom_hid_wd_pen-as-a-type-of-pen-collection.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "HID: cp2112: add HIDRAW dependency" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled HID: cp2112: add HIDRAW dependency to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hid-cp2112-add-hidraw-dependency.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From cde3076bdc38bf436e517a379759a9092c6ffd4f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Szymanski?= <sebastien.szymanski(a)armadeus.com> Date: Thu, 2 Nov 2017 12:12:43 +0100 Subject: HID: cp2112: add HIDRAW dependency MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Sébastien Szymanski <sebastien.szymanski(a)armadeus.com> commit cde3076bdc38bf436e517a379759a9092c6ffd4f upstream. Otherwise, with HIDRAW=n, the probe function crashes because of null dereference of hdev->hidraw. Fixes: 42cb6b35b9e6 ("HID: cp2112: use proper hidraw name with minor number") Signed-off-by: Sébastien Szymanski <sebastien.szymanski(a)armadeus.com> Acked-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hid/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -230,7 +230,7 @@ config HID_CMEDIA config HID_CP2112 tristate "Silicon Labs CP2112 HID USB-to-SMBus Bridge support" - depends on USB_HID && I2C && GPIOLIB + depends on USB_HID && HIDRAW && I2C && GPIOLIB select GPIOLIB_IRQCHIP ---help--- Support for Silicon Labs CP2112 HID USB to SMBus Master Bridge. Patches currently in stable-queue which might be from sebastien.szymanski(a)armadeus.com are queue-4.14/hid-cp2112-add-hidraw-dependency.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/MCE/AMD: Always give panic severity for UC errors in kernel context" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/MCE/AMD: Always give panic severity for UC errors in kernel context to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-mce-amd-always-give-panic-severity-for-uc-errors-in-kernel-context.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d65dfc81bb3894fdb68cbc74bbf5fb48d2354071 Mon Sep 17 00:00:00 2001 From: Yazen Ghannam <yazen.ghannam(a)amd.com> Date: Mon, 6 Nov 2017 18:46:32 +0100 Subject: x86/MCE/AMD: Always give panic severity for UC errors in kernel context From: Yazen Ghannam <yazen.ghannam(a)amd.com> commit d65dfc81bb3894fdb68cbc74bbf5fb48d2354071 upstream. The AMD severity grading function was introduced in kernel 4.1. The current logic can possibly give MCE_AR_SEVERITY for uncorrectable errors in kernel context. The system may then get stuck in a loop as memory_failure() will try to handle the bad kernel memory and find it busy. Return MCE_PANIC_SEVERITY for all UC errors IN_KERNEL context on AMD systems. After: b2f9d678e28c ("x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries") was accepted in v4.6, this issue was masked because of the tail-end attempt at kernel mode recovery in the #MC handler. However, uncorrectable errors IN_KERNEL context should always be considered unrecoverable and cause a panic. Signed-off-by: Yazen Ghannam <yazen.ghannam(a)amd.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Tony Luck <tony.luck(a)intel.com> Cc: linux-edac <linux-edac(a)vger.kernel.org> Fixes: bf80bbd7dcf5 (x86/mce: Add an AMD severities-grading function) Link: http://lkml.kernel.org/r/20171106174633.13576-1-bp@alien8.de Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/mcheck/mce-severity.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) --- a/arch/x86/kernel/cpu/mcheck/mce-severity.c +++ b/arch/x86/kernel/cpu/mcheck/mce-severity.c @@ -245,6 +245,9 @@ static int mce_severity_amd(struct mce * if (m->status & MCI_STATUS_UC) { + if (ctx == IN_KERNEL) + return MCE_PANIC_SEVERITY; + /* * On older systems where overflow_recov flag is not present, we * should simply panic if an error overflow occurs. If @@ -255,10 +258,6 @@ static int mce_severity_amd(struct mce * if (mce_flags.smca) return mce_severity_amd_smca(m, ctx); - /* software can try to contain */ - if (!(m->mcgstatus & MCG_STATUS_RIPV) && (ctx == IN_KERNEL)) - return MCE_PANIC_SEVERITY; - /* kill current process */ return MCE_AR_SEVERITY; } else { Patches currently in stable-queue which might be from yazen.ghannam(a)amd.com are queue-4.13/x86-mce-amd-always-give-panic-severity-for-uc-errors-in-kernel-context.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "selftests/x86/protection_keys: Fix syscall NR redefinition warnings" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/x86/protection_keys: Fix syscall NR redefinition warnings to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-x86-protection_keys-fix-syscall-nr-redefinition-warnings.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 693cb5580fdb026922363aa103add64b3ecd572e Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Sat, 4 Nov 2017 04:19:48 -0700 Subject: selftests/x86/protection_keys: Fix syscall NR redefinition warnings From: Andy Lutomirski <luto(a)kernel.org> commit 693cb5580fdb026922363aa103add64b3ecd572e upstream. On new enough glibc, the pkey syscalls numbers are available. Check first before defining them to avoid warnings like: protection_keys.c:198:0: warning: "SYS_pkey_alloc" redefined Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bpetkov(a)suse.de> Cc: Dave Hansen <dave.hansen(a)intel.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Link: http://lkml.kernel.org/r/1fbef53a9e6befb7165ff855fc1a7d4788a191d6.150979432… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/x86/protection_keys.c | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) --- a/tools/testing/selftests/x86/protection_keys.c +++ b/tools/testing/selftests/x86/protection_keys.c @@ -188,17 +188,29 @@ void lots_o_noops_around_write(int *writ #define u64 uint64_t #ifdef __i386__ -#define SYS_mprotect_key 380 -#define SYS_pkey_alloc 381 -#define SYS_pkey_free 382 + +#ifndef SYS_mprotect_key +# define SYS_mprotect_key 380 +#endif +#ifndef SYS_pkey_alloc +# define SYS_pkey_alloc 381 +# define SYS_pkey_free 382 +#endif #define REG_IP_IDX REG_EIP #define si_pkey_offset 0x14 + #else -#define SYS_mprotect_key 329 -#define SYS_pkey_alloc 330 -#define SYS_pkey_free 331 + +#ifndef SYS_mprotect_key +# define SYS_mprotect_key 329 +#endif +#ifndef SYS_pkey_alloc +# define SYS_pkey_alloc 330 +# define SYS_pkey_free 331 +#endif #define REG_IP_IDX REG_RIP #define si_pkey_offset 0x20 + #endif void dump_mem(void *dumpme, int len_bytes) Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.13/selftests-x86-protection_keys-fix-syscall-nr-redefinition-warnings.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "platform/x86: peaq_wmi: Fix missing terminating entry for peaq_dmi_table" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled platform/x86: peaq_wmi: Fix missing terminating entry for peaq_dmi_table to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: platform-x86-peaq_wmi-fix-missing-terminating-entry-for-peaq_dmi_table.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d6fa71f1c003fb2bc824276bb424a4171f9a717f Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Mon, 30 Oct 2017 14:07:37 +0100 Subject: platform/x86: peaq_wmi: Fix missing terminating entry for peaq_dmi_table From: Hans de Goede <hdegoede(a)redhat.com> commit d6fa71f1c003fb2bc824276bb424a4171f9a717f upstream. Add missing terminating entry to peaq_dmi_table. Fixes: 3b95206110a2 ("platform/x86: peaq-wmi: Add DMI check before ...") Reported-by: Fengguang Wu <fengguang.wu(a)intel.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/peaq-wmi.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/platform/x86/peaq-wmi.c +++ b/drivers/platform/x86/peaq-wmi.c @@ -73,6 +73,7 @@ static const struct dmi_system_id peaq_d DMI_MATCH(DMI_PRODUCT_NAME, "PEAQ PMM C1010 MD99187"), }, }, + {} }; static int __init peaq_wmi_init(void) Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.13/platform-x86-peaq-wmi-add-dmi-check-before-binding-to-the-wmi-interface.patch queue-4.13/platform-x86-peaq_wmi-fix-missing-terminating-entry-for-peaq_dmi_table.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "platform/x86: peaq-wmi: Add DMI check before binding to the WMI interface" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled platform/x86: peaq-wmi: Add DMI check before binding to the WMI interface to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: platform-x86-peaq-wmi-add-dmi-check-before-binding-to-the-wmi-interface.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3b95206110a2c13076c3a7fa8ddeae36c2dbcf42 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Thu, 5 Oct 2017 20:04:04 +0200 Subject: platform/x86: peaq-wmi: Add DMI check before binding to the WMI interface From: Hans de Goede <hdegoede(a)redhat.com> commit 3b95206110a2c13076c3a7fa8ddeae36c2dbcf42 upstream. It seems that the WMI GUID used by the PEAQ 2-in-1 WMI hotkeys is not as unique as a GUID should be and is used on some other devices too. This is causing spurious key-press reports on these other devices. This commits adds a DMI check to the PEAQ 2-in-1 WMI hotkeys driver to ensure that it is actually running on a PEAQ 2-in-1, fixing the spurious key-presses on these other devices. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1497861 BugLink: https://bugzilla.suse.com/attachment.cgi?id=743182 Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/peaq-wmi.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) --- a/drivers/platform/x86/peaq-wmi.c +++ b/drivers/platform/x86/peaq-wmi.c @@ -8,6 +8,7 @@ */ #include <linux/acpi.h> +#include <linux/dmi.h> #include <linux/input-polldev.h> #include <linux/kernel.h> #include <linux/module.h> @@ -64,8 +65,22 @@ static void peaq_wmi_poll(struct input_p } } +/* Some other devices (Shuttle XS35) use the same WMI GUID for other purposes */ +static const struct dmi_system_id peaq_dmi_table[] = { + { + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "PEAQ"), + DMI_MATCH(DMI_PRODUCT_NAME, "PEAQ PMM C1010 MD99187"), + }, + }, +}; + static int __init peaq_wmi_init(void) { + /* WMI GUID is not unique, also check for a DMI match */ + if (!dmi_check_system(peaq_dmi_table)) + return -ENODEV; + if (!wmi_has_guid(PEAQ_DOLBY_BUTTON_GUID)) return -ENODEV; @@ -86,6 +101,9 @@ static int __init peaq_wmi_init(void) static void __exit peaq_wmi_exit(void) { + if (!dmi_check_system(peaq_dmi_table)) + return; + if (!wmi_has_guid(PEAQ_DOLBY_BUTTON_GUID)) return; Patches currently in stable-queue which might be from hdegoede(a)redhat.com are queue-4.13/platform-x86-peaq-wmi-add-dmi-check-before-binding-to-the-wmi-interface.patch queue-4.13/platform-x86-peaq_wmi-fix-missing-terminating-entry-for-peaq_dmi_table.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "HID: wacom: generic: Recognize WACOM_HID_WD_PEN as a type of pen collection" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled HID: wacom: generic: Recognize WACOM_HID_WD_PEN as a type of pen collection to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hid-wacom-generic-recognize-wacom_hid_wd_pen-as-a-type-of-pen-collection.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 885e89f601a52cc6fb025b009df58ba83d142734 Mon Sep 17 00:00:00 2001 From: Jason Gerecke <killertofu(a)gmail.com> Date: Wed, 18 Oct 2017 08:27:13 -0700 Subject: HID: wacom: generic: Recognize WACOM_HID_WD_PEN as a type of pen collection From: Jason Gerecke <killertofu(a)gmail.com> commit 885e89f601a52cc6fb025b009df58ba83d142734 upstream. The WACOM_PEN_FIELD macro is used to determine if a given HID field should be associated with pen input. This field includes several known collection types that Wacom pen data is contained in, but the WACOM_HID_WD_PEN application collection type is notably missing. This can result in fields within this kind of collection being completely ignored by the `wacom_usage_mapping` function, preventing the later '*_event' functions from being notified about changes to their value. Fixes: c9c095874a ("HID: wacom: generic: Support and use 'Custom HID' mode and usages") Fixes: ac2423c975 ("HID: wacom: generic: add vendor defined touch") Reviewed-by: Ping Cheng <ping.cheng(a)wacom.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com> Signed-off-by: Jason Gerecke <jason.gerecke(a)wacom.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hid/wacom_wac.h | 1 + 1 file changed, 1 insertion(+) --- a/drivers/hid/wacom_wac.h +++ b/drivers/hid/wacom_wac.h @@ -166,6 +166,7 @@ ((f)->physical == HID_DG_PEN) || \ ((f)->application == HID_DG_PEN) || \ ((f)->application == HID_DG_DIGITIZER) || \ + ((f)->application == WACOM_HID_WD_PEN) || \ ((f)->application == WACOM_HID_WD_DIGITIZER) || \ ((f)->application == WACOM_HID_G9_PEN) || \ ((f)->application == WACOM_HID_G11_PEN)) Patches currently in stable-queue which might be from killertofu(a)gmail.com are queue-4.13/hid-wacom-generic-recognize-wacom_hid_wd_pen-as-a-type-of-pen-collection.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "HID: cp2112: add HIDRAW dependency" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled HID: cp2112: add HIDRAW dependency to the 4.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: hid-cp2112-add-hidraw-dependency.patch and it can be found in the queue-4.13 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From cde3076bdc38bf436e517a379759a9092c6ffd4f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=A9bastien=20Szymanski?= <sebastien.szymanski(a)armadeus.com> Date: Thu, 2 Nov 2017 12:12:43 +0100 Subject: HID: cp2112: add HIDRAW dependency MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Sébastien Szymanski <sebastien.szymanski(a)armadeus.com> commit cde3076bdc38bf436e517a379759a9092c6ffd4f upstream. Otherwise, with HIDRAW=n, the probe function crashes because of null dereference of hdev->hidraw. Fixes: 42cb6b35b9e6 ("HID: cp2112: use proper hidraw name with minor number") Signed-off-by: Sébastien Szymanski <sebastien.szymanski(a)armadeus.com> Acked-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com> Signed-off-by: Jiri Kosina <jkosina(a)suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/hid/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -230,7 +230,7 @@ config HID_CMEDIA config HID_CP2112 tristate "Silicon Labs CP2112 HID USB-to-SMBus Bridge support" - depends on USB_HID && I2C && GPIOLIB + depends on USB_HID && HIDRAW && I2C && GPIOLIB select GPIOLIB_IRQCHIP ---help--- Support for Silicon Labs CP2112 HID USB to SMBus Master Bridge. Patches currently in stable-queue which might be from sebastien.szymanski(a)armadeus.com are queue-4.13/hid-cp2112-add-hidraw-dependency.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] platform/x86: fujitsu-laptop: Don't oops when FUJ02E3 is not" failed to apply to 4.13-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.13-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From cd6bf7741cf992306748db11e1888c741d16dd0f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com> Date: Mon, 18 Sep 2017 23:00:59 +0300 Subject: [PATCH] platform/x86: fujitsu-laptop: Don't oops when FUJ02E3 is not presnt MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit My Fujitsu-Siemens Lifebook S6120 doesn't have the FUJ02E3 device, but it does have FUJ02B1. That means we do register the backlight device (and it even seems to work), but the code will oops as soon as we try to set the backlight brightness because it's trying to call call_fext_func() with a NULL device. Let's just skip those function calls when the FUJ02E3 device is not present. Cc: Jonathan Woithe <jwoithe(a)just42.net> Cc: Andy Shevchenko <andy(a)infradead.org> Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> # 4.13.x Signed-off-by: Darren Hart (VMware) <dvhart(a)infradead.org> diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c index 85de30f93a9c..56a8195096a2 100644 --- a/drivers/platform/x86/fujitsu-laptop.c +++ b/drivers/platform/x86/fujitsu-laptop.c @@ -254,10 +254,12 @@ static int bl_update_status(struct backlight_device *b) { struct acpi_device *device = bl_get_data(b); - if (b->props.power == FB_BLANK_POWERDOWN) - call_fext_func(fext, FUNC_BACKLIGHT, 0x1, 0x4, 0x3); - else - call_fext_func(fext, FUNC_BACKLIGHT, 0x1, 0x4, 0x0); + if (fext) { + if (b->props.power == FB_BLANK_POWERDOWN) + call_fext_func(fext, FUNC_BACKLIGHT, 0x1, 0x4, 0x3); + else + call_fext_func(fext, FUNC_BACKLIGHT, 0x1, 0x4, 0x0); + } return set_lcd_level(device, b->props.brightness); }

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/MCE/AMD: Always give panic severity for UC errors in kernel context" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/MCE/AMD: Always give panic severity for UC errors in kernel context to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-mce-amd-always-give-panic-severity-for-uc-errors-in-kernel-context.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d65dfc81bb3894fdb68cbc74bbf5fb48d2354071 Mon Sep 17 00:00:00 2001 From: Yazen Ghannam <yazen.ghannam(a)amd.com> Date: Mon, 6 Nov 2017 18:46:32 +0100 Subject: x86/MCE/AMD: Always give panic severity for UC errors in kernel context From: Yazen Ghannam <yazen.ghannam(a)amd.com> commit d65dfc81bb3894fdb68cbc74bbf5fb48d2354071 upstream. The AMD severity grading function was introduced in kernel 4.1. The current logic can possibly give MCE_AR_SEVERITY for uncorrectable errors in kernel context. The system may then get stuck in a loop as memory_failure() will try to handle the bad kernel memory and find it busy. Return MCE_PANIC_SEVERITY for all UC errors IN_KERNEL context on AMD systems. After: b2f9d678e28c ("x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries") was accepted in v4.6, this issue was masked because of the tail-end attempt at kernel mode recovery in the #MC handler. However, uncorrectable errors IN_KERNEL context should always be considered unrecoverable and cause a panic. Signed-off-by: Yazen Ghannam <yazen.ghannam(a)amd.com> Signed-off-by: Borislav Petkov <bp(a)suse.de> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Tony Luck <tony.luck(a)intel.com> Cc: linux-edac <linux-edac(a)vger.kernel.org> Fixes: bf80bbd7dcf5 (x86/mce: Add an AMD severities-grading function) Link: http://lkml.kernel.org/r/20171106174633.13576-1-bp@alien8.de Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/mcheck/mce-severity.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) --- a/arch/x86/kernel/cpu/mcheck/mce-severity.c +++ b/arch/x86/kernel/cpu/mcheck/mce-severity.c @@ -245,6 +245,9 @@ static int mce_severity_amd(struct mce * if (m->status & MCI_STATUS_UC) { + if (ctx == IN_KERNEL) + return MCE_PANIC_SEVERITY; + /* * On older systems where overflow_recov flag is not present, we * should simply panic if an error overflow occurs. If @@ -255,10 +258,6 @@ static int mce_severity_amd(struct mce * if (mce_flags.smca) return mce_severity_amd_smca(m, ctx); - /* software can try to contain */ - if (!(m->mcgstatus & MCG_STATUS_RIPV) && (ctx == IN_KERNEL)) - return MCE_PANIC_SEVERITY; - /* kill current process */ return MCE_AR_SEVERITY; } else { Patches currently in stable-queue which might be from yazen.ghannam(a)amd.com are queue-4.9/x86-mce-amd-always-give-panic-severity-for-uc-errors-in-kernel-context.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: usbfs: compute urb->actual_length for isochronous" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: usbfs: compute urb->actual_length for isochronous to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-usbfs-compute-urb-actual_length-for-isochronous.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 2ef47001b3ee3ded579b7532ebdcf8680e4d8c54 Mon Sep 17 00:00:00 2001 From: Alan Stern <stern(a)rowland.harvard.edu> Date: Wed, 8 Nov 2017 12:23:17 -0500 Subject: USB: usbfs: compute urb->actual_length for isochronous From: Alan Stern <stern(a)rowland.harvard.edu> commit 2ef47001b3ee3ded579b7532ebdcf8680e4d8c54 upstream. The USB kerneldoc says that the actual_length field "is read in non-iso completion functions", but the usbfs driver uses it for all URB types in processcompl(). Since not all of the host controller drivers set actual_length for isochronous URBs, programs using usbfs with some host controllers don't work properly. For example, Minas reports that a USB camera controlled by libusb doesn't work properly with a dwc2 controller. It doesn't seem worthwhile to change the HCDs and the documentation, since the in-kernel USB class drivers evidently don't rely on actual_length for isochronous transfers. The easiest solution is for usbfs to calculate the actual_length value for itself, by adding up the lengths of the individual packets in an isochronous transfer. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> CC: Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com> Reported-and-tested-by: wlf <wulf(a)rock-chips.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/devio.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/drivers/usb/core/devio.c +++ b/drivers/usb/core/devio.c @@ -1838,6 +1838,18 @@ static int proc_unlinkurb(struct usb_dev return 0; } +static void compute_isochronous_actual_length(struct urb *urb) +{ + unsigned int i; + + if (urb->number_of_packets > 0) { + urb->actual_length = 0; + for (i = 0; i < urb->number_of_packets; i++) + urb->actual_length += + urb->iso_frame_desc[i].actual_length; + } +} + static int processcompl(struct async *as, void __user * __user *arg) { struct urb *urb = as->urb; @@ -1845,6 +1857,7 @@ static int processcompl(struct async *as void __user *addr = as->userurb; unsigned int i; + compute_isochronous_actual_length(urb); if (as->userbuffer && urb->actual_length) { if (copy_urb_data_to_user(as->userbuffer, urb)) goto err_out; @@ -2019,6 +2032,7 @@ static int processcompl_compat(struct as void __user *addr = as->userurb; unsigned int i; + compute_isochronous_actual_length(urb); if (as->userbuffer && urb->actual_length) { if (copy_urb_data_to_user(as->userbuffer, urb)) return -EFAULT; Patches currently in stable-queue which might be from stern(a)rowland.harvard.edu are queue-4.9/usb-usbfs-compute-urb-actual_length-for-isochronous.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-serial-qcserial-add-pid-vid-for-sierra-wireless-em7355-fw-update.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 771394a54148f18926ca86414e51c69eda27d0cd Mon Sep 17 00:00:00 2001 From: Douglas Fischer <douglas.fischer(a)outlook.com> Date: Sun, 29 Oct 2017 23:29:55 +0000 Subject: USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update From: Douglas Fischer <douglas.fischer(a)outlook.com> commit 771394a54148f18926ca86414e51c69eda27d0cd upstream. Add USB PID/VID for Sierra Wireless EM7355 LTE modem QDL firmware update mode. Signed-off-by: Douglas Fischer <douglas.fischer(a)outlook.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/qcserial.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/serial/qcserial.c +++ b/drivers/usb/serial/qcserial.c @@ -148,6 +148,7 @@ static const struct usb_device_id id_tab {DEVICE_SWI(0x1199, 0x68a2)}, /* Sierra Wireless MC7710 */ {DEVICE_SWI(0x1199, 0x68c0)}, /* Sierra Wireless MC7304/MC7354 */ {DEVICE_SWI(0x1199, 0x901c)}, /* Sierra Wireless EM7700 */ + {DEVICE_SWI(0x1199, 0x901e)}, /* Sierra Wireless EM7355 QDL */ {DEVICE_SWI(0x1199, 0x901f)}, /* Sierra Wireless EM7355 */ {DEVICE_SWI(0x1199, 0x9040)}, /* Sierra Wireless Modem */ {DEVICE_SWI(0x1199, 0x9041)}, /* Sierra Wireless MC7305/MC7355 */ Patches currently in stable-queue which might be from douglas.fischer(a)outlook.com are queue-4.9/usb-serial-qcserial-add-pid-vid-for-sierra-wireless-em7355-fw-update.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: garmin_gps: fix memory leak on probe errors" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: garmin_gps: fix memory leak on probe errors to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-serial-garmin_gps-fix-memory-leak-on-probe-errors.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 74d471b598444b7f2d964930f7234779c80960a0 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Wed, 11 Oct 2017 14:02:58 +0200 Subject: USB: serial: garmin_gps: fix memory leak on probe errors From: Johan Hovold <johan(a)kernel.org> commit 74d471b598444b7f2d964930f7234779c80960a0 upstream. Make sure to free the port private data before returning after a failed probe attempt. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/garmin_gps.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/usb/serial/garmin_gps.c +++ b/drivers/usb/serial/garmin_gps.c @@ -1413,6 +1413,12 @@ static int garmin_port_probe(struct usb_ usb_set_serial_port_data(port, garmin_data_p); status = garmin_init_session(port); + if (status) + goto err_free; + + return 0; +err_free: + kfree(garmin_data_p); return status; } Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.9/usb-serial-qcserial-add-pid-vid-for-sierra-wireless-em7355-fw-update.patch queue-4.9/staging-greybus-add-host-device-function-pointer-checks.patch queue-4.9/usb-serial-garmin_gps-fix-i-o-after-failed-probe-and-remove.patch queue-4.9/usb-serial-garmin_gps-fix-memory-leak-on-probe-errors.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: garmin_gps: fix I/O after failed probe and remove" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: garmin_gps: fix I/O after failed probe and remove to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-serial-garmin_gps-fix-i-o-after-failed-probe-and-remove.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 19a565d9af6e0d828bd0d521d3bafd5017f4ce52 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Wed, 11 Oct 2017 14:02:57 +0200 Subject: USB: serial: garmin_gps: fix I/O after failed probe and remove From: Johan Hovold <johan(a)kernel.org> commit 19a565d9af6e0d828bd0d521d3bafd5017f4ce52 upstream. Make sure to stop any submitted interrupt and bulk-out URBs before returning after failed probe and when the port is being unbound to avoid later NULL-pointer dereferences in the completion callbacks. Also fix up the related and broken I/O cancellation on failed open and on close. (Note that port->write_urb was never submitted.) Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/garmin_gps.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) --- a/drivers/usb/serial/garmin_gps.c +++ b/drivers/usb/serial/garmin_gps.c @@ -138,6 +138,7 @@ struct garmin_data { __u8 privpkt[4*6]; spinlock_t lock; struct list_head pktlist; + struct usb_anchor write_urbs; }; @@ -905,7 +906,7 @@ static int garmin_init_session(struct us sizeof(GARMIN_START_SESSION_REQ), 0); if (status < 0) - break; + goto err_kill_urbs; } if (status > 0) @@ -913,6 +914,12 @@ static int garmin_init_session(struct us } return status; + +err_kill_urbs: + usb_kill_anchored_urbs(&garmin_data_p->write_urbs); + usb_kill_urb(port->interrupt_in_urb); + + return status; } @@ -930,7 +937,6 @@ static int garmin_open(struct tty_struct spin_unlock_irqrestore(&garmin_data_p->lock, flags); /* shutdown any bulk reads that might be going on */ - usb_kill_urb(port->write_urb); usb_kill_urb(port->read_urb); if (garmin_data_p->state == STATE_RESET) @@ -953,7 +959,7 @@ static void garmin_close(struct usb_seri /* shutdown our urbs */ usb_kill_urb(port->read_urb); - usb_kill_urb(port->write_urb); + usb_kill_anchored_urbs(&garmin_data_p->write_urbs); /* keep reset state so we know that we must start a new session */ if (garmin_data_p->state != STATE_RESET) @@ -1037,12 +1043,14 @@ static int garmin_write_bulk(struct usb_ } /* send it down the pipe */ + usb_anchor_urb(urb, &garmin_data_p->write_urbs); status = usb_submit_urb(urb, GFP_ATOMIC); if (status) { dev_err(&port->dev, "%s - usb_submit_urb(write bulk) failed with status = %d\n", __func__, status); count = status; + usb_unanchor_urb(urb); kfree(buffer); } @@ -1401,6 +1409,7 @@ static int garmin_port_probe(struct usb_ garmin_data_p->state = 0; garmin_data_p->flags = 0; garmin_data_p->count = 0; + init_usb_anchor(&garmin_data_p->write_urbs); usb_set_serial_port_data(port, garmin_data_p); status = garmin_init_session(port); @@ -1413,6 +1422,7 @@ static int garmin_port_remove(struct usb { struct garmin_data *garmin_data_p = usb_get_serial_port_data(port); + usb_kill_anchored_urbs(&garmin_data_p->write_urbs); usb_kill_urb(port->interrupt_in_urb); del_timer_sync(&garmin_data_p->timer); kfree(garmin_data_p); Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.9/usb-serial-qcserial-add-pid-vid-for-sierra-wireless-em7355-fw-update.patch queue-4.9/staging-greybus-add-host-device-function-pointer-checks.patch queue-4.9/usb-serial-garmin_gps-fix-i-o-after-failed-probe-and-remove.patch queue-4.9/usb-serial-garmin_gps-fix-memory-leak-on-probe-errors.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: gadget: f_fs: Fix use-after-free in ffs_free_inst" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: gadget: f_fs: Fix use-after-free in ffs_free_inst to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-gadget-f_fs-fix-use-after-free-in-ffs_free_inst.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From cdafb6d8b8da7fde266f79b3287ac221aa841879 Mon Sep 17 00:00:00 2001 From: Andrew Gabbasov <andrew_gabbasov(a)mentor.com> Date: Wed, 8 Nov 2017 10:13:15 -0700 Subject: usb: gadget: f_fs: Fix use-after-free in ffs_free_inst From: Andrew Gabbasov <andrew_gabbasov(a)mentor.com> commit cdafb6d8b8da7fde266f79b3287ac221aa841879 upstream. KASAN enabled configuration reports an error BUG: KASAN: use-after-free in ffs_free_inst+... [usb_f_fs] at addr ... Write of size 8 by task ... This is observed after "ffs-test" is run and interrupted. If after that functionfs is unmounted and g_ffs module is unloaded, that use-after-free occurs during g_ffs module removal. Although the report indicates ffs_free_inst() function, the actual use-after-free condition occurs in _ffs_free_dev() function, which is probably inlined into ffs_free_inst(). This happens due to keeping the ffs_data reference in device structure during functionfs unmounting, while ffs_data itself is freed as no longer needed. The fix is to clear that reference in ffs_closed() function, which is a counterpart of ffs_ready(), where the reference is stored. Fixes: 3262ad824307 ("usb: gadget: f_fs: Stop ffs_closed NULL pointer dereference") Signed-off-by: Andrew Gabbasov <andrew_gabbasov(a)mentor.com> Acked-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/function/f_fs.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/gadget/function/f_fs.c +++ b/drivers/usb/gadget/function/f_fs.c @@ -3698,6 +3698,7 @@ static void ffs_closed(struct ffs_data * goto done; ffs_obj->desc_ready = false; + ffs_obj->ffs_data = NULL; if (test_and_clear_bit(FFS_FL_CALL_CLOSED_CALLBACK, &ffs->flags) && ffs_obj->ffs_closed_callback) Patches currently in stable-queue which might be from andrew_gabbasov(a)mentor.com are queue-4.9/usb-gadget-f_fs-fix-use-after-free-in-ffs_free_inst.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: Add delay-init quirk for Corsair K70 LUX keyboards" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: Add delay-init quirk for Corsair K70 LUX keyboards to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-add-delay-init-quirk-for-corsair-k70-lux-keyboards.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a0fea6027f19c62727315aba1a7fae75a9caa842 Mon Sep 17 00:00:00 2001 From: Bernhard Rosenkraenzer <bernhard.rosenkranzer(a)linaro.org> Date: Fri, 3 Nov 2017 16:46:02 +0100 Subject: USB: Add delay-init quirk for Corsair K70 LUX keyboards From: Bernhard Rosenkraenzer <bernhard.rosenkranzer(a)linaro.org> commit a0fea6027f19c62727315aba1a7fae75a9caa842 upstream. Without this patch, K70 LUX keyboards don't work, saying usb 3-3: unable to read config index 0 descriptor/all usb 3-3: can't read configurations, error -110 usb usb3-port3: unable to enumerate USB device Signed-off-by: Bernhard Rosenkraenzer <Bernhard.Rosenkranzer(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/quirks.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/usb/core/quirks.c +++ b/drivers/usb/core/quirks.c @@ -221,6 +221,9 @@ static const struct usb_device_id usb_qu /* Corsair Strafe RGB */ { USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT }, + /* Corsair K70 LUX */ + { USB_DEVICE(0x1b1c, 0x1b36), .driver_info = USB_QUIRK_DELAY_INIT }, + /* MIDI keyboard WORLDE MINI */ { USB_DEVICE(0x1c75, 0x0204), .driver_info = USB_QUIRK_CONFIG_INTF_STRINGS }, Patches currently in stable-queue which might be from bernhard.rosenkranzer(a)linaro.org are queue-4.9/usb-add-delay-init-quirk-for-corsair-k70-lux-keyboards.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: dh - Don't permit 'p' to be 0" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: dh - Don't permit 'p' to be 0 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-dh-don-t-permit-p-to-be-0.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 199512b1234f09e44d592153ec82b44212b2f0c4 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Sun, 5 Nov 2017 18:30:45 -0800 Subject: crypto: dh - Don't permit 'p' to be 0 From: Eric Biggers <ebiggers(a)google.com> commit 199512b1234f09e44d592153ec82b44212b2f0c4 upstream. If 'p' is 0 for the software Diffie-Hellman implementation, then dh_max_size() returns 0. In the case of KEYCTL_DH_COMPUTE, this causes ZERO_SIZE_PTR to be passed to sg_init_one(), which with CONFIG_DEBUG_SG=y triggers the 'BUG_ON(!virt_addr_valid(buf));' in sg_set_buf(). Fix this by making crypto_dh_decode_key() reject 0 for 'p'. p=0 makes no sense for any DH implementation because 'p' is supposed to be a prime number. Moreover, 'mod 0' is not mathematically defined. Bug report: kernel BUG at ./include/linux/scatterlist.h:140! invalid opcode: 0000 [#1] SMP KASAN CPU: 0 PID: 27112 Comm: syz-executor2 Not tainted 4.14.0-rc7-00010-gf5dbb5d0ce32-dirty #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.3-20171021_125229-anatol 04/01/2014 task: ffff88006caac0c0 task.stack: ffff88006c7c8000 RIP: 0010:sg_set_buf include/linux/scatterlist.h:140 [inline] RIP: 0010:sg_init_one+0x1b3/0x240 lib/scatterlist.c:156 RSP: 0018:ffff88006c7cfb08 EFLAGS: 00010216 RAX: 0000000000010000 RBX: ffff88006c7cfe30 RCX: 00000000000064ee RDX: ffffffff81cf64c3 RSI: ffffc90000d72000 RDI: ffffffff92e937e0 RBP: ffff88006c7cfb30 R08: ffffed000d8f9fab R09: ffff88006c7cfd30 R10: 0000000000000005 R11: ffffed000d8f9faa R12: ffff88006c7cfd30 R13: 0000000000000000 R14: 0000000000000010 R15: ffff88006c7cfc50 FS: 00007fce190fa700(0000) GS:ffff88003ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fffc6b33db8 CR3: 000000003cf64000 CR4: 00000000000006f0 Call Trace: __keyctl_dh_compute+0xa95/0x19b0 security/keys/dh.c:360 keyctl_dh_compute+0xac/0x100 security/keys/dh.c:434 SYSC_keyctl security/keys/keyctl.c:1745 [inline] SyS_keyctl+0x72/0x2c0 security/keys/keyctl.c:1641 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x4585c9 RSP: 002b:00007fce190f9bd8 EFLAGS: 00000216 ORIG_RAX: 00000000000000fa RAX: ffffffffffffffda RBX: 0000000000738020 RCX: 00000000004585c9 RDX: 000000002000d000 RSI: 0000000020000ff4 RDI: 0000000000000017 RBP: 0000000000000046 R08: 0000000020008000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000216 R12: 00007fff6e610cde R13: 00007fff6e610cdf R14: 00007fce190fa700 R15: 0000000000000000 Code: 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 33 5b 45 89 6c 24 14 41 5c 41 5d 41 5e 41 5f 5d c3 e8 fd 8f 68 ff <0f> 0b e8 f6 8f 68 ff 0f 0b e8 ef 8f 68 ff 0f 0b e8 e8 8f 68 ff 20 RIP: sg_set_buf include/linux/scatterlist.h:140 [inline] RSP: ffff88006c7cfb08 RIP: sg_init_one+0x1b3/0x240 lib/scatterlist.c:156 RSP: ffff88006c7cfb08 Fixes: 802c7f1c84e4 ("crypto: dh - Add DH software implementation") Reviewed-by: Tudor Ambarus <tudor.ambarus(a)microchip.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/dh_helper.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/crypto/dh_helper.c +++ b/crypto/dh_helper.c @@ -90,6 +90,14 @@ int crypto_dh_decode_key(const char *buf params->p = (void *)(ptr + params->key_size); params->g = (void *)(ptr + params->key_size + params->p_size); + /* + * Don't permit 'p' to be 0. It's not a prime number, and it's subject + * to corner cases such as 'mod 0' being undefined or + * crypto_kpp_maxsize() returning 0. + */ + if (memchr_inv(params->p, 0, params->p_size) == NULL) + return -EINVAL; + return 0; } EXPORT_SYMBOL_GPL(crypto_dh_decode_key); Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.9/crypto-dh-don-t-permit-key-or-g-size-longer-than-p.patch queue-4.9/arm-crypto-reduce-priority-of-bit-sliced-aes-cipher.patch queue-4.9/crypto-dh-don-t-permit-p-to-be-0.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: dh - Don't permit 'key' or 'g' size longer than 'p'" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: dh - Don't permit 'key' or 'g' size longer than 'p' to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: crypto-dh-don-t-permit-key-or-g-size-longer-than-p.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From ccd9888f14a8019c0bbdeeae758aba1f58693712 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Sun, 5 Nov 2017 18:30:46 -0800 Subject: crypto: dh - Don't permit 'key' or 'g' size longer than 'p' From: Eric Biggers <ebiggers(a)google.com> commit ccd9888f14a8019c0bbdeeae758aba1f58693712 upstream. The "qat-dh" DH implementation assumes that 'key' and 'g' can be copied into a buffer with size 'p_size'. However it was never checked that that was actually the case, which most likely allowed users to cause a buffer underflow via KEYCTL_DH_COMPUTE. Fix this by updating crypto_dh_decode_key() to verify this precondition for all DH implementations. Fixes: c9839143ebbf ("crypto: qat - Add DH support") Signed-off-by: Eric Biggers <ebiggers(a)google.com> Reviewed-by: Tudor Ambarus <tudor.ambarus(a)microchip.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/dh_helper.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/crypto/dh_helper.c +++ b/crypto/dh_helper.c @@ -83,6 +83,14 @@ int crypto_dh_decode_key(const char *buf if (secret.len != crypto_dh_key_len(params)) return -EINVAL; + /* + * Don't permit the buffer for 'key' or 'g' to be larger than 'p', since + * some drivers assume otherwise. + */ + if (params->key_size > params->p_size || + params->g_size > params->p_size) + return -EINVAL; + /* Don't allocate memory. Set pointers to data within * the given buffer */ Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.9/crypto-dh-don-t-permit-key-or-g-size-longer-than-p.patch queue-4.9/arm-crypto-reduce-priority-of-bit-sliced-aes-cipher.patch queue-4.9/crypto-dh-don-t-permit-p-to-be-0.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: usbfs: compute urb->actual_length for isochronous" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: usbfs: compute urb->actual_length for isochronous to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-usbfs-compute-urb-actual_length-for-isochronous.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 2ef47001b3ee3ded579b7532ebdcf8680e4d8c54 Mon Sep 17 00:00:00 2001 From: Alan Stern <stern(a)rowland.harvard.edu> Date: Wed, 8 Nov 2017 12:23:17 -0500 Subject: USB: usbfs: compute urb->actual_length for isochronous From: Alan Stern <stern(a)rowland.harvard.edu> commit 2ef47001b3ee3ded579b7532ebdcf8680e4d8c54 upstream. The USB kerneldoc says that the actual_length field "is read in non-iso completion functions", but the usbfs driver uses it for all URB types in processcompl(). Since not all of the host controller drivers set actual_length for isochronous URBs, programs using usbfs with some host controllers don't work properly. For example, Minas reports that a USB camera controlled by libusb doesn't work properly with a dwc2 controller. It doesn't seem worthwhile to change the HCDs and the documentation, since the in-kernel USB class drivers evidently don't rely on actual_length for isochronous transfers. The easiest solution is for usbfs to calculate the actual_length value for itself, by adding up the lengths of the individual packets in an isochronous transfer. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> CC: Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com> Reported-and-tested-by: wlf <wulf(a)rock-chips.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/devio.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/drivers/usb/core/devio.c +++ b/drivers/usb/core/devio.c @@ -1653,6 +1653,18 @@ static int proc_unlinkurb(struct usb_dev return 0; } +static void compute_isochronous_actual_length(struct urb *urb) +{ + unsigned int i; + + if (urb->number_of_packets > 0) { + urb->actual_length = 0; + for (i = 0; i < urb->number_of_packets; i++) + urb->actual_length += + urb->iso_frame_desc[i].actual_length; + } +} + static int processcompl(struct async *as, void __user * __user *arg) { struct urb *urb = as->urb; @@ -1660,6 +1672,7 @@ static int processcompl(struct async *as void __user *addr = as->userurb; unsigned int i; + compute_isochronous_actual_length(urb); if (as->userbuffer && urb->actual_length) { if (copy_urb_data_to_user(as->userbuffer, urb)) goto err_out; @@ -1829,6 +1842,7 @@ static int processcompl_compat(struct as void __user *addr = as->userurb; unsigned int i; + compute_isochronous_actual_length(urb); if (as->userbuffer && urb->actual_length) { if (copy_urb_data_to_user(as->userbuffer, urb)) return -EFAULT; Patches currently in stable-queue which might be from stern(a)rowland.harvard.edu are queue-4.4/usb-usbfs-compute-urb-actual_length-for-isochronous.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-serial-qcserial-add-pid-vid-for-sierra-wireless-em7355-fw-update.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 771394a54148f18926ca86414e51c69eda27d0cd Mon Sep 17 00:00:00 2001 From: Douglas Fischer <douglas.fischer(a)outlook.com> Date: Sun, 29 Oct 2017 23:29:55 +0000 Subject: USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update From: Douglas Fischer <douglas.fischer(a)outlook.com> commit 771394a54148f18926ca86414e51c69eda27d0cd upstream. Add USB PID/VID for Sierra Wireless EM7355 LTE modem QDL firmware update mode. Signed-off-by: Douglas Fischer <douglas.fischer(a)outlook.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/qcserial.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/serial/qcserial.c +++ b/drivers/usb/serial/qcserial.c @@ -148,6 +148,7 @@ static const struct usb_device_id id_tab {DEVICE_SWI(0x1199, 0x68a2)}, /* Sierra Wireless MC7710 */ {DEVICE_SWI(0x1199, 0x68c0)}, /* Sierra Wireless MC7304/MC7354 */ {DEVICE_SWI(0x1199, 0x901c)}, /* Sierra Wireless EM7700 */ + {DEVICE_SWI(0x1199, 0x901e)}, /* Sierra Wireless EM7355 QDL */ {DEVICE_SWI(0x1199, 0x901f)}, /* Sierra Wireless EM7355 */ {DEVICE_SWI(0x1199, 0x9040)}, /* Sierra Wireless Modem */ {DEVICE_SWI(0x1199, 0x9041)}, /* Sierra Wireless MC7305/MC7355 */ Patches currently in stable-queue which might be from douglas.fischer(a)outlook.com are queue-4.4/usb-serial-qcserial-add-pid-vid-for-sierra-wireless-em7355-fw-update.patch

7 years, 11 months

1
0
0 0

[Linux-stable-mirror] Patch "USB: serial: garmin_gps: fix memory leak on probe errors" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: serial: garmin_gps: fix memory leak on probe errors to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-serial-garmin_gps-fix-memory-leak-on-probe-errors.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 74d471b598444b7f2d964930f7234779c80960a0 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Wed, 11 Oct 2017 14:02:58 +0200 Subject: USB: serial: garmin_gps: fix memory leak on probe errors From: Johan Hovold <johan(a)kernel.org> commit 74d471b598444b7f2d964930f7234779c80960a0 upstream. Make sure to free the port private data before returning after a failed probe attempt. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/serial/garmin_gps.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/drivers/usb/serial/garmin_gps.c +++ b/drivers/usb/serial/garmin_gps.c @@ -1414,6 +1414,12 @@ static int garmin_port_probe(struct usb_ usb_set_serial_port_data(port, garmin_data_p); status = garmin_init_session(port); + if (status) + goto err_free; + + return 0; +err_free: + kfree(garmin_data_p); return status; } Patches currently in stable-queue which might be from johan(a)kernel.org are queue-4.4/usb-serial-qcserial-add-pid-vid-for-sierra-wireless-em7355-fw-update.patch queue-4.4/usb-serial-garmin_gps-fix-i-o-after-failed-probe-and-remove.patch queue-4.4/usb-serial-garmin_gps-fix-memory-leak-on-probe-errors.patch

7 years, 11 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror