from:"Luis Henriques"

CVE-2014-9900 fix is not upstream

2016-08-23 Thread Luis Henriques

Hi!

Digging through some old CVEs I came across this one that doesn't seem be
in mainline.  Was there a good reason for not being sent upstream?  Maybe it was
rejected for some reason and I failed to find the discussion.

References:
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-9900
 http://source.android.com/security/bulletin/2016-08-01.html
 
https://source.codeaurora.org/quic/la/kernel/msm-3.10/commit/?id=63c317dbee97983004dffdd9f742a20d17150071

Cheers,
--
Luís

net: Zeroing the structure ethtool_wolinfo in ethtool_get_wol()

2016-08-23 Thread Luis Henriques

From: Avijit Kanti Das 

memset() the structure ethtool_wolinfo that has padded bytes
but the padded bytes have not been zeroed out.

Change-Id: If3fd2d872a1b1ab9521d937b86a29fc468a8bbfe
Signed-off-by: Avijit Kanti Das 
---
 net/core/ethtool.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 977489820eb9..6bf6362e8114 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1435,11 +1435,13 @@ static int ethtool_reset(struct net_device *dev, char 
__user *useraddr)
 
 static int ethtool_get_wol(struct net_device *dev, char __user *useraddr)
 {
-   struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL };
+   struct ethtool_wolinfo wol;
 
if (!dev->ethtool_ops->get_wol)
return -EOPNOTSUPP;
 
+   memset(, 0, sizeof(struct ethtool_wolinfo));
+   wol.cmd = ETHTOOL_GWOL;
dev->ethtool_ops->get_wol(dev, );
 
if (copy_to_user(useraddr, , sizeof(wol)))

[3.16.y-ckt stable] Patch "=?UTF-8?q?veth:=20don=E2=80=99t=20modify=20ip=5Fsummed;=20doing?= =?UTF-8?q?=20so=20treats=20packets=20with=20bad=20checksums=20as=20good.?=" has been added to the 3.16.y-ck

2016-02-03 Thread Luis Henriques

This is a note to let you know that I have just added a patch titled

=?UTF-8?q?veth:=20don=E2=80=99t=20modify=20ip=5Fsummed;=20doing?= 
=?UTF-8?q?=20so=20treats=20packets=20with=20bad=20checksums=20as=20good.?=

to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree 
which can be found at:

http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.16.y-queue

This patch is scheduled to be released in version 3.16.7-ckt24.

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.16.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Luis

---8<

>From 3be302bd22c56fe6a9a1c6de7e14661f0d3defc1 Mon Sep 17 00:00:00 2001
From: Vijay Pandurangan <vij...@vijayp.ca>
Date: Fri, 18 Dec 2015 14:34:59 -0500
Subject: =?UTF-8?q?veth:=20don=E2=80=99t=20modify=20ip=5Fsummed;=20doing?=
 =?UTF-8?q?=20so=20treats=20packets=20with=20bad=20checksums=20as=20good.?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

commit ce8c839b74e3017996fad4e1b7ba2e2625ede82f upstream.

Packets that arrive from real hardware devices have ip_summed ==
CHECKSUM_UNNECESSARY if the hardware verified the checksums, or
CHECKSUM_NONE if the packet is bad or it was unable to verify it. The
current version of veth will replace CHECKSUM_NONE with
CHECKSUM_UNNECESSARY, which causes corrupt packets routed from hardware to
a veth device to be delivered to the application. This caused applications
at Twitter to receive corrupt data when network hardware was corrupting
packets.

We believe this was added as an optimization to skip computing and
verifying checksums for communication between containers. However, locally
generated packets have ip_summed == CHECKSUM_PARTIAL, so the code as
written does nothing for them. As far as we can tell, after removing this
code, these packets are transmitted from one stack to another unmodified
(tcpdump shows invalid checksums on both sides, as expected), and they are
delivered correctly to applications. We didn’t test every possible network
configuration, but we tried a few common ones such as bridging containers,
using NAT between the host and a container, and routing from hardware
devices to containers. We have effectively deployed this in production at
Twitter (by disabling RX checksum offloading on veth devices).

This code dates back to the first version of the driver, commit
 ("[NET]: Virtual ethernet device driver"), so I
suspect this bug occurred mostly because the driver API has evolved
significantly since then. Commit <0b7967503dc97864f283a> ("net/veth: Fix
packet checksumming") (in December 2010) fixed this for packets that get
created locally and sent to hardware devices, by not changing
CHECKSUM_PARTIAL. However, the same issue still occurs for packets coming
in from hardware devices.

Co-authored-by: Evan Jones <e...@evanjones.ca>
Signed-off-by: Evan Jones <e...@evanjones.ca>
Cc: Nicolas Dichtel <nicolas.dich...@6wind.com>
Cc: Phil Sutter <p...@nwl.cc>
Cc: Toshiaki Makita <makita.toshi...@lab.ntt.co.jp>
Cc: netdev@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Vijay Pandurangan <vij...@vijayp.ca>
Acked-by: Cong Wang <cw...@twopensource.com>
Signed-off-by: David S. Miller <da...@davemloft.net>
Signed-off-by: Luis Henriques <luis.henriq...@canonical.com>
---
 drivers/net/veth.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index b4a10bcb66a0..e3a0e674136f 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -117,12 +117,6 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct 
net_device *dev)
kfree_skb(skb);
goto drop;
}
-   /* don't change ip_summed == CHECKSUM_PARTIAL, as that
-* will cause bad checksum on forwarded packets
-*/
-   if (skb->ip_summed == CHECKSUM_NONE &&
-   rcv->features & NETIF_F_RXCSUM)
-   skb->ip_summed = CHECKSUM_UNNECESSARY;

if (likely(dev_forward_skb(rcv, skb) == NET_RX_SUCCESS)) {
struct pcpu_vstats *stats = this_cpu_ptr(dev->vstats);

[PATCH 3.16.y-ckt 002/180] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

2016-02-03 Thread Luis Henriques

3.16.7-ckt24 -stable review patch.  If anyone has any objections, please let me 
know.

---8<

From: Vijay Pandurangan <vij...@vijayp.ca>

commit ce8c839b74e3017996fad4e1b7ba2e2625ede82f upstream.

Packets that arrive from real hardware devices have ip_summed ==
CHECKSUM_UNNECESSARY if the hardware verified the checksums, or
CHECKSUM_NONE if the packet is bad or it was unable to verify it. The
current version of veth will replace CHECKSUM_NONE with
CHECKSUM_UNNECESSARY, which causes corrupt packets routed from hardware to
a veth device to be delivered to the application. This caused applications
at Twitter to receive corrupt data when network hardware was corrupting
packets.

We believe this was added as an optimization to skip computing and
verifying checksums for communication between containers. However, locally
generated packets have ip_summed == CHECKSUM_PARTIAL, so the code as
written does nothing for them. As far as we can tell, after removing this
code, these packets are transmitted from one stack to another unmodified
(tcpdump shows invalid checksums on both sides, as expected), and they are
delivered correctly to applications. We didn’t test every possible network
configuration, but we tried a few common ones such as bridging containers,
using NAT between the host and a container, and routing from hardware
devices to containers. We have effectively deployed this in production at
Twitter (by disabling RX checksum offloading on veth devices).

This code dates back to the first version of the driver, commit
 ("[NET]: Virtual ethernet device driver"), so I
suspect this bug occurred mostly because the driver API has evolved
significantly since then. Commit <0b7967503dc97864f283a> ("net/veth: Fix
packet checksumming") (in December 2010) fixed this for packets that get
created locally and sent to hardware devices, by not changing
CHECKSUM_PARTIAL. However, the same issue still occurs for packets coming
in from hardware devices.

Co-authored-by: Evan Jones <e...@evanjones.ca>
Signed-off-by: Evan Jones <e...@evanjones.ca>
Cc: Nicolas Dichtel <nicolas.dich...@6wind.com>
Cc: Phil Sutter <p...@nwl.cc>
Cc: Toshiaki Makita <makita.toshi...@lab.ntt.co.jp>
Cc: netdev@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Vijay Pandurangan <vij...@vijayp.ca>
Acked-by: Cong Wang <cw...@twopensource.com>
Signed-off-by: David S. Miller <da...@davemloft.net>
Signed-off-by: Luis Henriques <luis.henriq...@canonical.com>
---
 drivers/net/veth.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/net/veth.c b/drivers/net/veth.c
index b4a10bcb66a0..e3a0e674136f 100644
--- a/drivers/net/veth.c
+++ b/drivers/net/veth.c
@@ -117,12 +117,6 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct 
net_device *dev)
kfree_skb(skb);
goto drop;
}
-   /* don't change ip_summed == CHECKSUM_PARTIAL, as that
-* will cause bad checksum on forwarded packets
-*/
-   if (skb->ip_summed == CHECKSUM_NONE &&
-   rcv->features & NETIF_F_RXCSUM)
-   skb->ip_summed = CHECKSUM_UNNECESSARY;
 
if (likely(dev_forward_skb(rcv, skb) == NET_RX_SUCCESS)) {
struct pcpu_vstats *stats = this_cpu_ptr(dev->vstats);

[PATCH 3.16.y-ckt 047/126] can: Use correct type in sizeof() in nla_put()

2015-12-09 Thread Luis Henriques

3.16.7-ckt21 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Marek Vasut <ma...@denx.de>

commit 562b103a21974c2f9cd67514d110f918bb3e1796 upstream.

The sizeof() is invoked on an incorrect variable, likely due to some
copy-paste error, and this might result in memory corruption. Fix this.

Signed-off-by: Marek Vasut <ma...@denx.de>
Cc: Wolfgang Grandegger <w...@grandegger.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <m...@pengutronix.de>
Signed-off-by: Luis Henriques <luis.henriq...@canonical.com>
---
 drivers/net/can/dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index c543c3aaee4d..5635c6e7af57 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -835,7 +835,7 @@ static int can_fill_info(struct sk_buff *skb, const struct 
net_device *dev)
 nla_put(skb, IFLA_CAN_BITTIMING_CONST,
 sizeof(*priv->bittiming_const), priv->bittiming_const)) ||
 
-   nla_put(skb, IFLA_CAN_CLOCK, sizeof(cm), >clock) ||
+   nla_put(skb, IFLA_CAN_CLOCK, sizeof(priv->clock), >clock) ||
nla_put_u32(skb, IFLA_CAN_STATE, state) ||
nla_put(skb, IFLA_CAN_CTRLMODE, sizeof(cm), ) ||
nla_put_u32(skb, IFLA_CAN_RESTART_MS, priv->restart_ms) ||
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[3.16.y-ckt stable] Patch "can: Use correct type in sizeof() in nla_put()" has been added to staging queue

2015-11-30 Thread Luis Henriques

This is a note to let you know that I have just added a patch titled

can: Use correct type in sizeof() in nla_put()

to the linux-3.16.y-queue branch of the 3.16.y-ckt extended stable tree 
which can be found at:

http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-3.16.y-queue

This patch is scheduled to be released in version 3.16.7-ckt21.

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.16.y-ckt tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Luis

--

>From 38c6b0cfa61cf90117c73fba15a90478085d9e48 Mon Sep 17 00:00:00 2001
From: Marek Vasut <ma...@denx.de>
Date: Fri, 30 Oct 2015 13:48:19 +0100
Subject: can: Use correct type in sizeof() in nla_put()

commit 562b103a21974c2f9cd67514d110f918bb3e1796 upstream.

The sizeof() is invoked on an incorrect variable, likely due to some
copy-paste error, and this might result in memory corruption. Fix this.

Signed-off-by: Marek Vasut <ma...@denx.de>
Cc: Wolfgang Grandegger <w...@grandegger.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <m...@pengutronix.de>
Signed-off-by: Luis Henriques <luis.henriq...@canonical.com>
---
 drivers/net/can/dev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index c543c3aaee4d..5635c6e7af57 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -835,7 +835,7 @@ static int can_fill_info(struct sk_buff *skb, const struct 
net_device *dev)
 nla_put(skb, IFLA_CAN_BITTIMING_CONST,
 sizeof(*priv->bittiming_const), priv->bittiming_const)) ||

-   nla_put(skb, IFLA_CAN_CLOCK, sizeof(cm), >clock) ||
+   nla_put(skb, IFLA_CAN_CLOCK, sizeof(priv->clock), >clock) ||
nla_put_u32(skb, IFLA_CAN_STATE, state) ||
nla_put(skb, IFLA_CAN_CTRLMODE, sizeof(cm), ) ||
nla_put_u32(skb, IFLA_CAN_RESTART_MS, priv->restart_ms) ||
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH stable<3.19] net: handle null iovec pointer in skb_copy_and_csum_datagram_iovec()

2015-10-26 Thread Luis Henriques

On Fri, Oct 23, 2015 at 11:39:46AM +0200, Michal Kubecek wrote:
> On Fri, Oct 23, 2015 at 11:22:19AM +0200, Sabrina Dubroca wrote:
> > Hello Michal,
> > 
> > 2015-10-23, 10:46:09 +0200, Michal Kubecek wrote:
> > > Mainline commit 89c22d8c3b27 ("net: Fix skb csum races when peeking")
> > > backport into pre-3.19 stable kernels introduces a regression causing
> > > null pointer dererefence in skb_copy_and_csum_datagram_iovec().
> > > 
> > > This commit only sets CHECKSUM_UNNECESSARY for non-shared skb, allowing
> > > udp_recvmsg() to take the "else" branch of if (skb_csum_unnecessary(skb))
> > > when called with null iovec (and len=0, e.g. when peeking for datagram
> > > size first). The problem is that unlike skb_copy_and_csum_datagram_msg()
> > > called in this path since 3.19, skb_copy_and_csum_datagram_iovec() does
> > > not handle null iov parameter and always dereferences iov->iov_len. This
> > > is especially harmful when udp_recvmsg() is called in kernel context,
> > > e.g. from kernel nfsd.
> > > 
> > > Band-aid skb_copy_and_csum_datagram_iovec() by testing iov for null and
> > > only checking the checksum in this case.
> > > 
> > > Signed-off-by: Michal Kubecek 
> > > ---
> > 
> > I ran into this problem too and that was my initial solution to this
> > problem as well, but actually, we need a more complete fix, like the
> > one I submitted a few days ago:
> > 
> > http://patchwork.ozlabs.org/patch/530642/
> > 
> > With your solution, userspace can still receive bogus EFAULT, or the
> > kernel ends up writing data to an unwanted memory location.
> 
> I must admit I wondered why skb_copy_and_csum_datagram_iovec() doesn't
> get (and check) read length and why it cannot overfill the buffer. But
> then I saw the comment "Caller _must_ check that skb will fit to this
> iovec", stopped thinking and assumed it's OK. I guess I should be less
> trusting... :-(
> 
> Thank you for the warning.
> 
> Michal Kubecek

I can confirm that we had this issue reported in our kernels too
(https://bugs.launchpad.net/bugs/1508510).  I'll queue Sabrina's patch for
the next 3.16 stable kernel release.  Thanks a lot!


Cheers,
--
Luís
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3.19 and earlier] fib_rules: Fix dump_rules() not to exit early

2015-10-19 Thread Luis Henriques

On Mon, Oct 05, 2015 at 10:29:28AM -0700, Roland Dreier wrote:
> From: Roland Dreier 
> 
> Backports of 41fc014332d9 ("fib_rules: fix fib rule dumps across
> multiple skbs") introduced a regression in "ip rule show" - it ends up
> dumping the first rule over and over and never exiting, because 3.19
> and earlier are missing commit 053c095a82cf ("netlink: make
> nlmsg_end() and genlmsg_end() void"), so fib_nl_fill_rule() ends up
> returning skb->len (i.e. > 0) in the success case.
> 
> Fix this by checking the return code for < 0 instead of != 0.
> 
> Signed-off-by: Roland Dreier 
> ---
> Hi, this is needed for all stable trees earlier than 4.0 that have
> picked up 41fc014332d9; so far looks like at least 3.10.y and 3.14.y
> have made such releases.
>

Thanks Roland, I'm queuing this fix for the 3.16 kernel as well.

Cheers,
--
Luís


>  net/core/fib_rules.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
> index 627e517077e4..84340a2605ed 100644
> --- a/net/core/fib_rules.c
> +++ b/net/core/fib_rules.c
> @@ -606,7 +606,7 @@ static int dump_rules(struct sk_buff *skb, struct 
> netlink_callback *cb,
>   err = fib_nl_fill_rule(skb, rule, NETLINK_CB(cb->skb).portid,
>  cb->nlh->nlmsg_seq, RTM_NEWRULE,
>  NLM_F_MULTI, ops);
> - if (err)
> + if (err < 0)
>   break;
>  skip:
>   idx++;
> -- 
> 2.5.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [STABLE] Please backport asix (USB Ethernet) fixes

2015-10-19 Thread Luis Henriques

On Mon, Oct 05, 2015 at 05:09:36PM +0100, Ian Campbell wrote:
> Hi David + stable@,
> 
> Please could these two be backported:
> 3cc81d85ee01 "asix: Don't reset PHY on if_up for ASIX 88772"
> 436c2a5036b6 "asix: Do full reset during ax88772_bind"
> 
> 3cc81d85ee01 was in v3.18-rc1 while 436c2a5036b6 was in v3.18-rc5 so both
> should be backported to anything older which still has active longterm
> support, please.
> 
> Our automated test is occasionally tripping over a failure to achieve link
> on the arndale board with 3.16 (both the Debian Jessie kernel used at host
> install time and the 3.16 kernel under test), reporting lots of this:
> Oct  4 02:01:17.077037 [  411.069293] asix 2-3.2.4:1.0 eth0: link down
> Oct  4 02:01:21.037081 [  414.525294] asix 2-3.2.4:1.0 eth0: link down
> Oct  4 02:01:24.493057 [  419.773293] asix 2-3.2.4:1.0 eth0: link down
> Oct  4 02:01:29.741083 [  423.229292] asix 2-3.2.4:1.0 eth0: link down
> Oct  4 02:01:33.197066 [  426.685292] asix 2-3.2.4:1.0 eth0: link down
> Oct  4 02:01:36.653128 [  430.141291] asix 2-3.2.4:1.0 eth0: link down
> Oct  4 02:01:40.109050 [  440.765293] asix 2-3.2.4:1.0 eth0: link down
> Oct  4 02:01:50.733034 [  446.141292] asix 2-3.2.4:1.0 eth0: link down
> Oct  4 02:01:56.109092 [  471.614170] asix 2-3.2.4:1.0 eth0: link up, 
> 100Mbps, full-duplex, lpa 0xC1E1
> Oct  4 02:02:21.581182 [  486.973293] asix 2-3.2.4:1.0 eth0: link down
> Oct  4 02:02:36.941033 [  803.390169] asix 2-3.2.4:1.0 eth0: link up, 
> 100Mbps, full-duplex, lpa 0xC1E1
> Oct  4 02:07:53.353184 [  805.182045] asix 2-3.2.4:1.0 eth0: link up, 
> 100Mbps, full-duplex, lpa 0xC1E1
> Oct  4 02:07:55.145152 [  818.109291] asix 2-3.2.4:1.0 eth0: link down
> Oct  4 02:08:08.073064 [  825.149291] asix 2-3.2.4:1.0 eth0: link down
> 
> It appears that we no longer see this in 3.18 (although they still use
> Debian's 3.16 at install time, which obscures things a little in the data
> mining). These are the only commits to this driver between 3.16 and 3.18
> and they sound like they might plausibly fix this.
>

Thanks Ian, I'm queuing these 2 commits for the 3.16 kernel.

Cheers,
--
Luís


> Thanks,
> 
> Ian.
> 
> commit 3cc81d85ee01e5a0b7ea2f4190e2ed1165f53c31
> Author: Michel Stam 
> Date:   Thu Oct 2 10:22:02 2014 +0200
> 
> asix: Don't reset PHY on if_up for ASIX 88772
> 
> I've noticed every time the interface is set to 'up,', the kernel
> reports that the link speed is set to 100 Mbps/Full Duplex, even
> when ethtool is used to set autonegotiation to 'off', half
> duplex, 10 Mbps.
> It can be tested by:
>  ifconfig eth0 down
>  ethtool -s eth0 autoneg off speed 10 duplex half
>  ifconfig eth0 up
> 
> Then checking 'dmesg' for the link speed.
> 
> Signed-off-by: Michel Stam 
> Signed-off-by: David S. Miller 
> 
> diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
> index 5d19409..2c05f6c 100644
> --- a/drivers/net/usb/asix_devices.c
> +++ b/drivers/net/usb/asix_devices.c
> @@ -890,7 +890,7 @@ static const struct driver_info ax88772_info = {
>   .unbind = ax88772_unbind,
>   .status = asix_status,
>   .link_reset = ax88772_link_reset,
> - .reset = ax88772_reset,
> + .reset = ax88772_link_reset,
>   .flags = FLAG_ETHER | FLAG_FRAMING_AX | FLAG_LINK_INTR | 
> FLAG_MULTI_PACKET,
>   .rx_fixup = asix_rx_fixup_common,
>   .tx_fixup = asix_tx_fixup,
> 
> commit 436c2a5036b6ffe813310df2cf327d3b69be0734
> Author: Charles Keepax 
> Date:   Thu Nov 6 15:49:41 2014 +
> 
> asix: Do full reset during ax88772_bind
> 
> commit 3cc81d85ee01 ("asix: Don't reset PHY on if_up for ASIX 88772")
> causes the ethernet on Arndale to no longer function. This appears to
> be because the Arndale ethernet requires a full reset before it will
> function correctly, however simply reverting the above patch causes
> problems with ethtool settings getting reset.
> 
> It seems the problem is that the ethernet is not properly reset during
> bind, and indeed the code in ax88772_bind that resets the device is a
> very small subset of the actual ax88772_reset function. This patch uses
> ax88772_reset in place of the existing reset code in ax88772_bind which
> removes some code duplication and fixes the ethernet on Arndale.
> 
> It is still possible that the original patch causes some issues with
> suspend and resume but that seems like a separate issue and I haven't
> had a chance to test that yet.
> 
> Signed-off-by: Charles Keepax 
> Tested-by: Riku Voipio 
> Signed-off-by: David S. Miller 
> 
> diff --git a/drivers/net/usb/asix_devices.c b/drivers/net/usb/asix_devices.c
> index 2c05f6c..816d511

Re: [RFC] [PATCH] net: socket: Fix the wrong returns for recvmsg and sendmsg

2015-06-02 Thread Luis Henriques

On Tue, Jun 02, 2015 at 03:05:57PM +0800, Junling Zheng wrote:
 On 2015/6/2 14:52, Willy Tarreau wrote:
  On Tue, Jun 02, 2015 at 02:43:54PM +0800, Junling Zheng wrote:
  On 2015/6/2 14:27, Greg KH wrote:
  On Mon, Jun 01, 2015 at 10:23:57PM -0700, David Miller wrote:
  From: Junling Zheng zhengjunl...@huawei.com
  Date: Tue, 2 Jun 2015 12:05:32 +0800

  So, the problem commit is 281c9c36 (net: compat: Update
  get_compat_msghdr() to match copy_msghdr_from_user() behaviour),
  which fixes db31c55a6fb2 and brings the get_compat_msghdr() in line
  with copy_msghdr_from_user().

  Upstream this got fixed by:

  08adb7dabd4874cc5666b4490653b26534702ce0

  So the part that makes us not unconditionally return -EFAULT needs
  to be backported, and that's probably equivalent to the patch
  your proposed which therefore should be applied.

  Ok, thanks, now applied.

  Maybe other stable version also needs this fix:)

  Yes, from what I'm seeing, at least 3.2 and 2.6.32 need it as well.

 Yeah, all other stable versions *except 3.19 and 4.0* may need this fix:)

This seems to be correct.  I am queuing this fix for the 3.16 kernel
as well.  Thank you!

Cheers,
--
Luís
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3.16.y-ckt 093/144] net: ethernet: pcnet32: Setup the SRAM and NOUFLO on Am79C97{3, 5}

2015-04-21 Thread Luis Henriques

3.16.7-ckt10 -stable review patch.  If anyone has any objections, please let me 
know.

--

From: Markos Chandras markos.chand...@imgtec.com

commit 87f966d97b89774162df04d2106c6350c8fe4cb3 upstream.

On a MIPS Malta board, tons of fifo underflow errors have been observed
when using u-boot as bootloader instead of YAMON. The reason for that
is that YAMON used to set the pcnet device to SRAM mode but u-boot does
not. As a result, the default Tx threshold (64 bytes) is now too small to
keep the fifo relatively used and it can result to Tx fifo underflow errors.
As a result of which, it's best to setup the SRAM on supported controllers
so we can always use the NOUFLO bit.

Cc: netdev@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Don Fry pcne...@frontier.com
Signed-off-by: Markos Chandras markos.chand...@imgtec.com
Signed-off-by: David S. Miller da...@davemloft.net
Signed-off-by: Luis Henriques luis.henriq...@canonical.com
---
 drivers/net/ethernet/amd/pcnet32.c | 31 +--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/amd/pcnet32.c 
b/drivers/net/ethernet/amd/pcnet32.c
index e7cc9174e364..02d3b7975835 100644
--- a/drivers/net/ethernet/amd/pcnet32.c
+++ b/drivers/net/ethernet/amd/pcnet32.c
@@ -1552,7 +1552,7 @@ pcnet32_probe1(unsigned long ioaddr, int shared, struct 
pci_dev *pdev)
 {
struct pcnet32_private *lp;
int i, media;
-   int fdx, mii, fset, dxsuflo;
+   int fdx, mii, fset, dxsuflo, sram;
int chip_version;
char *chipname;
struct net_device *dev;
@@ -1589,7 +1589,7 @@ pcnet32_probe1(unsigned long ioaddr, int shared, struct 
pci_dev *pdev)
}
 
/* initialize variables */
-   fdx = mii = fset = dxsuflo = 0;
+   fdx = mii = fset = dxsuflo = sram = 0;
chip_version = (chip_version  12)  0x;
 
switch (chip_version) {
@@ -1622,6 +1622,7 @@ pcnet32_probe1(unsigned long ioaddr, int shared, struct 
pci_dev *pdev)
chipname = PCnet/FAST III 79C973; /* PCI */
fdx = 1;
mii = 1;
+   sram = 1;
break;
case 0x2626:
chipname = PCnet/Home 79C978; /* PCI */
@@ -1645,6 +1646,7 @@ pcnet32_probe1(unsigned long ioaddr, int shared, struct 
pci_dev *pdev)
chipname = PCnet/FAST III 79C975; /* PCI */
fdx = 1;
mii = 1;
+   sram = 1;
break;
case 0x2628:
chipname = PCnet/PRO 79C976;
@@ -1673,6 +1675,31 @@ pcnet32_probe1(unsigned long ioaddr, int shared, struct 
pci_dev *pdev)
dxsuflo = 1;
}
 
+   /*
+* The Am79C973/Am79C975 controllers come with 12K of SRAM
+* which we can use for the Tx/Rx buffers but most importantly,
+* the use of SRAM allow us to use the BCR18:NOUFLO bit to avoid
+* Tx fifo underflows.
+*/
+   if (sram) {
+   /*
+* The SRAM is being configured in two steps. First we
+* set the SRAM size in the BCR25:SRAM_SIZE bits. According
+* to the datasheet, each bit corresponds to a 512-byte
+* page so we can have at most 24 pages. The SRAM_SIZE
+* holds the value of the upper 8 bits of the 16-bit SRAM size.
+* The low 8-bits start at 0x00 and end at 0xff. So the
+* address range is from 0x up to 0x17ff. Therefore,
+* the SRAM_SIZE is set to 0x17. The next step is to set
+* the BCR26:SRAM_BND midway through so the Tx and Rx
+* buffers can share the SRAM equally.
+*/
+   a-write_bcr(ioaddr, 25, 0x17);
+   a-write_bcr(ioaddr, 26, 0xc);
+   /* And finally enable the NOUFLO bit */
+   a-write_bcr(ioaddr, 18, a-read_bcr(ioaddr, 18) | (1  11));
+   }
+
dev = alloc_etherdev(sizeof(*lp));
if (!dev) {
ret = -ENOMEM;
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH stable 3.10-3.16] tcp: Fix crash in TCP Fast Open

2015-04-16 Thread Luis Henriques

On Wed, Apr 15, 2015 at 07:00:32PM +0100, Ben Hutchings wrote:
 Commit 355a901e6cf1 (tcp: make connect() mem charging friendly)
 changed tcp_send_syn_data() to perform an open-coded copy of the 'syn'
 skb rather than using skb_copy_expand().
 
 The open-coded copy does not cover the skb_shared_info::gso_segs
 field, so in the new skb it is left set to 0.  When this commit was
 backported into stable branches between 3.10.y and 3.16.7-ckty
 inclusive, it triggered the BUG() in tcp_transmit_skb().
 
 Since Linux 3.18 the GSO segment count is kept in the
 tcp_skb_cb::tcp_gso_segs field and tcp_send_syn_data() does copy the
 tcp_skb_cb structure to the new skb, so mainline and newer stable
 branches are not affected.
 
 Set skb_shared_info::gso_segs to the correct value of 1.
 
 Signed-off-by: Ben Hutchings b...@decadent.org.uk

Thanks a lot, Ben.  I'll queue this for the next 3.16 kernel release.

Cheers,
--
Luís

 ---
  net/ipv4/tcp_output.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
 index d5457e4..1ea0a07 100644
 --- a/net/ipv4/tcp_output.c
 +++ b/net/ipv4/tcp_output.c
 @@ -2992,6 +2992,7 @@ static int tcp_send_syn_data(struct sock *sk, struct 
 sk_buff *syn)
   goto fallback;
   syn_data-ip_summed = CHECKSUM_PARTIAL;
   memcpy(syn_data-cb, syn-cb, sizeof(syn-cb));
 + skb_shinfo(syn_data)-gso_segs = 1;
   if (unlikely(memcpy_fromiovecend(skb_put(syn_data, space),
fo-data-msg_iov, 0, space))) {
   kfree_skb(syn_data);
 
 -- 
 Ben Hutchings
 Editing code like this is akin to sticking plasters on the bleeding stump
 of a severed limb. - me, 29 June 1999

--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

CVE-2014-9900 fix is not upstream

net: Zeroing the structure ethtool_wolinfo in ethtool_get_wol()

[3.16.y-ckt stable] Patch "=?UTF-8?q?veth:=20don=E2=80=99t=20modify=20ip=5Fsummed;=20doing?= =?UTF-8?q?=20so=20treats=20packets=20with=20bad=20checksums=20as=20good.?=" has been added to the 3.16.y-ck

[PATCH 3.16.y-ckt 002/180] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

[PATCH 3.16.y-ckt 047/126] can: Use correct type in sizeof() in nla_put()

[3.16.y-ckt stable] Patch "can: Use correct type in sizeof() in nla_put()" has been added to staging queue

Re: [PATCH stable<3.19] net: handle null iovec pointer in skb_copy_and_csum_datagram_iovec()

Re: [PATCH 3.19 and earlier] fib_rules: Fix dump_rules() not to exit early

Re: [STABLE] Please backport asix (USB Ethernet) fixes

Re: [RFC] [PATCH] net: socket: Fix the wrong returns for recvmsg and sendmsg

[PATCH 3.16.y-ckt 093/144] net: ethernet: pcnet32: Setup the SRAM and NOUFLO on Am79C97{3, 5}

Re: [PATCH stable 3.10-3.16] tcp: Fix crash in TCP Fast Open

12 matches

Site Navigation

Mail list logo

Footer information