* Re: [PATCH] HID: Bluetooth: hidp: buffer overflow in hidp_process_report
From: Greg KH @ 2018-08-01 17:09 UTC (permalink / raw)
To: Mark Salyzyn
Cc: linux-kernel, Marcel Holtmann, Johan Hedberg, David S. Miller,
Kees Cook, Benjamin Tissoires, linux-bluetooth, netdev, stable,
kernel-team, Jiri Kosina
In-Reply-To: <6f6c3e63-0847-b0b6-98a3-7ad62fd2697c@android.com>
On Wed, Aug 01, 2018 at 09:41:04AM -0700, Mark Salyzyn wrote:
> On 08/01/2018 09:37 AM, Greg KH wrote:
> > On Tue, Jul 31, 2018 at 03:02:13PM -0700, Mark Salyzyn wrote:
> > > CVE-2018-9363
> > >
> > > The buffer length is unsigned at all layers, but gets cast to int and
> > > checked in hidp_process_report and can lead to a buffer overflow.
> > > Switch len parameter to unsigned int to resolve issue.
> > >
> > > This affects 3.18 and newer kernels.
> > >
> > > Signed-off-by: Mark Salyzyn <salyzyn@android.com>
> > > Fixes: a4b1b5877b514b276f0f31efe02388a9c2836728 ("HID: Bluetooth: hidp: make sure input buffers are big enough")
> > > Cc: Marcel Holtmann <marcel@holtmann.org>
> > > Cc: Johan Hedberg <johan.hedberg@gmail.com>
> > > Cc: "David S. Miller" <davem@davemloft.net>
> > > Cc: Kees Cook <keescook@chromium.org>
> > > Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> > > Cc: linux-bluetooth@vger.kernel.org
> > > Cc: netdev@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org
> > > Cc: security@kernel.org
> > > Cc: kernel-team@android.com
> > Nit, you only need to bother security@ if you do not have a fix and need
> > to figure out one.
>
> Thanks, I thought anything with a CVE was to go there according to netdev
> FAQ (dropped security from response list).
> > Also, you forgot to cc: stable@vger.kernel.org to be included in older
> > kernel releases :(
> netdev FAQ said to _not_ copy stable, I am so confused ;-{ (added stable to
> response list b/c patch is now taken into bluetooth-next)
Ah, well, bluetooth is a bit not normal here, usually stuff that ends up
in a subsystem tree before netdev needs to have a cc: stable on it for
me to catch it. Hopefully the bluetooth maintainers are on it :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH bpf] selftests/bpf: update test_lwt_seg6local.sh according to iproute2
From: Y Song @ 2018-08-01 15:15 UTC (permalink / raw)
To: Mathieu Xhonneux; +Cc: netdev, Daniel Borkmann, Alexei Starovoitov
In-Reply-To: <20180801153454.20755-1-m.xhonneux@gmail.com>
On Wed, Aug 1, 2018 at 8:34 AM, Mathieu Xhonneux <m.xhonneux@gmail.com> wrote:
> The shell file for test_lwt_seg6local contains an early iproute2 syntax
> for installing a seg6local End.BPF route. iproute2 support for this
> feature has recently been upstreamed, but with an additional keyword
> required. This patch updates test_lwt_seg6local.sh to the definitive
> iproute2 syntax
>
> Signed-off-by: Mathieu Xhonneux <m.xhonneux@gmail.com>
Acked-by: Yonghong Song <yhs@fb.com>
^ permalink raw reply
* Re: [PATCH net-next] rds: remove redundant variable 'rds_ibdev'
From: David Miller @ 2018-08-01 17:01 UTC (permalink / raw)
To: yuehaibing; +Cc: santosh.shilimkar, linux-kernel, netdev, linux-rdma, rds-devel
In-Reply-To: <20180801071407.22044-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Wed, 1 Aug 2018 15:14:07 +0800
> Variable 'rds_ibdev' is being assigned but never used,
> so can be removed.
>
> fix this clang warning:
> net/rds/ib_send.c:762:24: warning: variable ‘rds_ibdev’ set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] strparser: remove redundant variable 'rd_desc'
From: David Miller @ 2018-08-01 17:00 UTC (permalink / raw)
To: yuehaibing
Cc: doronrk, tom, vakul.garg, davejwatson, ebiggers, john.fastabend,
linux-kernel, netdev
In-Reply-To: <20180801071037.12508-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Wed, 1 Aug 2018 15:10:37 +0800
> Variable 'rd_desc' is being assigned but never used,
> so can be removed.
>
> fix this clang warning:
> net/strparser/strparser.c:411:20: warning: variable ‘rd_desc’ set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ip_gre: remove redundant variables t_hlen
From: David Miller @ 2018-08-01 16:58 UTC (permalink / raw)
To: yuehaibing; +Cc: kuznet, yoshfuji, linux-kernel, netdev
In-Reply-To: <20180801020402.16448-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Wed, 1 Aug 2018 10:04:02 +0800
> After commit ffc2b6ee4174 ("ip_gre: fix IFLA_MTU ignored on NEWLINK")
> variable t_hlen is assigned values that are never read,
> hence they are redundant and can be removed.
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH v6 bpf-next 4/9] veth: Handle xdp_frames in xdp napi ring
From: Jesper Dangaard Brouer @ 2018-08-01 15:09 UTC (permalink / raw)
To: Toshiaki Makita, Alexei Starovoitov
Cc: Daniel Borkmann, netdev, Jakub Kicinski, John Fastabend,
Karlsson, Magnus, Björn Töpel, brouer
In-Reply-To: <90f355ef-1e56-5f12-ab78-a19c83fc9253@lab.ntt.co.jp>
On Wed, 1 Aug 2018 14:41:08 +0900
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
> On 2018/07/31 21:46, Jesper Dangaard Brouer wrote:
> > On Tue, 31 Jul 2018 19:40:08 +0900
> > Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
> >
> >> On 2018/07/31 19:26, Jesper Dangaard Brouer wrote:
> >>>
> >>> Context needed from: [PATCH v6 bpf-next 2/9] veth: Add driver XDP
> >>>
> >>> On Mon, 30 Jul 2018 19:43:44 +0900
> >>> Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> wrote:
> >>>
[...]
> >>>
> >>> Here you are adding an assumption that struct xdp_frame is always
> >>> located in-the-top of the packet-data area. I tried hard not to add
> >>> such a dependency! You can calculate the beginning of the frame from
> >>> the xdp_frame->data pointer.
> >>>
> >>> Why not add such a dependency? Because for AF_XDP zero-copy, we cannot
> >>> make such an assumption.
> >>>
> >>> Currently, when an RX-queue is in AF-XDP-ZC mode (MEM_TYPE_ZERO_COPY)
> >>> the packet will get dropped when calling convert_to_xdp_frame(), but as
> >>> the TODO comment indicated in convert_to_xdp_frame() this is not the
> >>> end-goal.
> >>>
> >>> The comment in convert_to_xdp_frame(), indicate we need a full
> >>> alloc+copy, but that is actually not necessary, if we can just use
> >>> another memory area for struct xdp_frame, and a pointer to data. Thus,
> >>> allowing devmap-redir to work-ZC and allow cpumap-redir to do the copy
> >>> on the remote CPU.
> >>
> >> Thanks for pointing this out.
> >> Seems you are saying xdp_frame area is not reusable. That means we
> >> reduce usable headroom on every REDIRECT. I wanted to avoid this but
> >> actually it is impossible, right?
> >
> > I'm not sure I understand fully... has this something to do, with the
> > below memset?
>
> Sorry for not being so clear...
> It has something to do with the memset as well but mainly I was talking
> about XDP_TX and REDIRECT introduced in patch 8. On REDIRECT,
> dev_map_enqueue() calls convert_to_xdp_frame() so we use the headroom
> for struct xdp_frame on REDIRECT. If we don't reuse xdp_frame region of
> the original xdp packet, we reduce the headroom size each time on
> REDIRECT. When ZC is used, in the future xdp_frame can be non-contiguous
> to the buffer, so we cannot reuse the xdp_frame region in
> convert_to_xdp_frame()? But current convert_to_xdp_frame()
> implementation requires xdp_frame region in headroom so I think I cannot
> avoid this dependency now.
>
> SKB has a similar problem if we cannot reuse it. It can be passed to a
> bridge and redirected to another veth which has driver XDP. In that case
> we need to reallocate the page if we have reduced the headroom because
> sufficient headroom is required for XDP processing for now (can we
> remove this requirement actually?).
Okay, now I understand. Your changes allow multiple levels of
XDP_REDIRECT between/into other veth net_devices. This is very
interesting and exciting stuff, but also a bit scary, when thinking
about if we got he life-time correct for the different memory objects.
You have convinced me. We should not sacrifice/reduce the headroom
this way. I'll also fix up cpumap.
To avoid the performance penalty of the memset, I propose that we just
clear the xdp_frame->data pointer. But lets implement it via a common
sanitize/scrub function.
> > When cpumap generate an SKB for the netstack, then we sacrifice/reduce
> > the SKB headroom available, by in convert_to_xdp_frame() reducing the
> > headroom by xdp_frame size.
> >
> > xdp_frame->headroom = headroom - sizeof(*xdp_frame)
> >
> > In-order to avoid doing such memset of this area. We are actually only
> > worried about exposing the 'data' pointer, thus we could just clear
> > that. (See commit 6dfb970d3dbd, this is because Alexei is planing to
> > move from CAP_SYS_ADMIN to lesser privileged mode CAP_NET_ADMIN)
> >
> > See commits:
> > 97e19cce05e5 ("bpf: reserve xdp_frame size in xdp headroom")
> > 6dfb970d3dbd ("xdp: avoid leaking info stored in frame data on page reuse")
>
> We have talked about that...
> https://patchwork.ozlabs.org/patch/903536/
>
> The memset is introduced as per your feedback, but I'm still not sure if
> we need this. In general the headroom is not cleared after allocation in
> drivers, so anyway unprivileged users should not see it no matter if it
> contains xdp_frame or not...
I actually got this request from Alexei. That is why I implemented it.
Personally I don't think this clearing is really needed, until someone
actually makes the TC/cls_act BPF hook CAP_NET_ADMIN.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH net] net: dsa: Do not suspend/resume closed slave_dev
From: David Miller @ 2018-08-01 16:55 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20180801001253.16312-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Tue, 31 Jul 2018 17:12:52 -0700
> If a DSA slave network device was previously disabled, there is no need
> to suspend or resume it.
>
> Fixes: 2446254915a7 ("net: dsa: allow switch drivers to implement suspend/resume hooks")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next 5/9] net: stmmac: Add MDIO related functions for XGMAC2
From: Andrew Lunn @ 2018-08-01 15:08 UTC (permalink / raw)
To: Jose Abreu
Cc: netdev, David S. Miller, Joao Pinto, Giuseppe Cavallaro,
Alexandre Torgue
In-Reply-To: <5a7f4264b01f863dbf79b4f6d5e62cd2a55c758f.1533125016.git.joabreu@synopsys.com>
Hi Jose
> +static int stmmac_xgmac2_mdio_read(struct stmmac_priv *priv, int phyaddr,
> + int phyreg)
> +{
> + unsigned int mii_address = priv->hw->mii.addr;
> + unsigned int mii_data = priv->hw->mii.data;
> + u32 tmp, addr, value = MII_XGMAC_BUSY;
> + int data;
> +
> + if (phyreg & MII_ADDR_C45) {
> + addr = ((phyreg >> 16) & 0x1f) << 21;
> + addr |= (phyaddr << 16) | (phyreg & 0xffff);
Do you need to tell the hardware this is a C45 transfer? Normally an
extra bit needs setting somewhere.
> + } else {
> + if (phyaddr >= 4)
> + return -ENODEV;
Can the MDIO bus be external? If so, is there a reason why there
cannot be a PHY at addresses > 4. So maybe there is an Ethernet
switch, which needs lots of addresses? And C45 can have devices > 4
but C22 cannot?
> + writel(~0x0, priv->ioaddr + 0x220);
> + addr = (phyaddr << 16) | (phyreg & 0x1f);
> + }
> +
> + value |= (priv->clk_csr << priv->hw->mii.clk_csr_shift)
> + & priv->hw->mii.clk_csr_mask;
> + value |= BIT(18);
Please add a #define for this bit.
> + value |= MII_XGMAC_READ;
> +
> + if (readl_poll_timeout(priv->ioaddr + mii_data, tmp,
> + !(tmp & MII_XGMAC_BUSY), 100, 10000))
> + return -EBUSY;
> +
> + writel(addr, priv->ioaddr + mii_address);
> + writel(value, priv->ioaddr + mii_data);
> +
> + if (readl_poll_timeout(priv->ioaddr + mii_data, tmp,
> + !(tmp & MII_XGMAC_BUSY), 100, 10000))
> + return -EBUSY;
> +
> + /* Read the data from the MII data register */
> + data = (int)readl(priv->ioaddr + mii_data) & GENMASK(15, 0);
Is the cast needed? And why use GENMASK here, but not in all the other
places you have masks in this code?
> /**
> * stmmac_mdio_read
> * @bus: points to the mii_bus structure
> @@ -59,6 +141,9 @@ static int stmmac_mdio_read(struct mii_bus *bus, int phyaddr, int phyreg)
> int data;
> u32 value = MII_BUSY;
>
> + if (priv->plat->has_xgmac)
> + return stmmac_xgmac2_mdio_read(priv, phyaddr, phyreg);
It would be cleaner to instead do this in stmmac_mdio_register() when
setting new_bus->read.
Andrew
^ permalink raw reply
* [PATCH 4.14 240/246] netlink: Do not subscribe to non-existent groups
From: Greg Kroah-Hartman @ 2018-08-01 16:52 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David S. Miller, Herbert Xu,
Steffen Klassert, netdev, Dmitry Safonov
In-Reply-To: <20180801165011.700991984@linuxfoundation.org>
4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Safonov <dima@arista.com>
[ Upstream commit 7acf9d4237c46894e0fa0492dd96314a41742e84 ]
Make ABI more strict about subscribing to group > ngroups.
Code doesn't check for that and it looks bogus.
(one can subscribe to non-existing group)
Still, it's possible to bind() to all possible groups with (-1)
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/netlink/af_netlink.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -976,6 +976,7 @@ static int netlink_bind(struct socket *s
if (err)
return err;
}
+ groups &= (1UL << nlk->ngroups) - 1;
bound = nlk->bound;
if (bound) {
^ permalink raw reply
* [PATCH 4.17 327/336] netlink: Do not subscribe to non-existent groups
From: Greg Kroah-Hartman @ 2018-08-01 16:51 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, David S. Miller, Herbert Xu,
Steffen Klassert, netdev, Dmitry Safonov
In-Reply-To: <20180801165028.930831994@linuxfoundation.org>
4.17-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Safonov <dima@arista.com>
[ Upstream commit 7acf9d4237c46894e0fa0492dd96314a41742e84 ]
Make ABI more strict about subscribing to group > ngroups.
Code doesn't check for that and it looks bogus.
(one can subscribe to non-existing group)
Still, it's possible to bind() to all possible groups with (-1)
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/netlink/af_netlink.c | 1 +
1 file changed, 1 insertion(+)
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1008,6 +1008,7 @@ static int netlink_bind(struct socket *s
if (err)
return err;
}
+ groups &= (1UL << nlk->ngroups) - 1;
bound = nlk->bound;
if (bound) {
^ permalink raw reply
* Re: [PATCH] net/tls: Use kmemdup to simplify the code
From: David Miller @ 2018-08-01 16:48 UTC (permalink / raw)
To: zhongjiang; +Cc: borisp, aviadye, davejwatson, netdev, linux-kernel
In-Reply-To: <1533055824-36976-1-git-send-email-zhongjiang@huawei.com>
From: zhong jiang <zhongjiang@huawei.com>
Date: Wed, 1 Aug 2018 00:50:24 +0800
> Kmemdup is better than kmalloc+memcpy. So replace them.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net/tipc: remove redundant variables 'tn' and 'oport'
From: David Miller @ 2018-08-01 16:48 UTC (permalink / raw)
To: colin.king; +Cc: netdev, kernel-janitors, linux-kernel, tipc-discussion
In-Reply-To: <20180731160137.5850-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 31 Jul 2018 17:01:37 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> Variables 'tn' and 'oport' are being assigned but are never used hence
> they are redundant and can be removed.
>
> Cleans up clang warnings:
> warning: variable 'oport' set but not used [-Wunused-but-set-variable]
> warning: variable 'tn' set but not used [-Wunused-but-set-variable]
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply
* [PATCH] netfilter: ipset: fix ip_set_list allocation failure
From: Andrey Ryabinin @ 2018-08-01 16:46 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal
Cc: David S. Miller, netfilter-devel, coreteam, netdev, linux-kernel,
Andrey Ryabinin
ip_set_create() and ip_set_net_init() attempt to allocate physically
contiguous memory for ip_set_list. If memory is fragmented, the
allocations could easily fail:
vzctl: page allocation failure: order:7, mode:0xc0d0
Call Trace:
dump_stack+0x19/0x1b
warn_alloc_failed+0x110/0x180
__alloc_pages_nodemask+0x7bf/0xc60
alloc_pages_current+0x98/0x110
kmalloc_order+0x18/0x40
kmalloc_order_trace+0x26/0xa0
__kmalloc+0x279/0x290
ip_set_net_init+0x4b/0x90 [ip_set]
ops_init+0x3b/0xb0
setup_net+0xbb/0x170
copy_net_ns+0xf1/0x1c0
create_new_namespaces+0xf9/0x180
copy_namespaces+0x8e/0xd0
copy_process+0xb61/0x1a00
do_fork+0x91/0x320
Use kvcalloc() to fallback to 0-order allocations if high order
page isn't available.
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
---
net/netfilter/ipset/ip_set_core.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/ipset/ip_set_core.c b/net/netfilter/ipset/ip_set_core.c
index bc4bd247bb7d..96dd57c48b1c 100644
--- a/net/netfilter/ipset/ip_set_core.c
+++ b/net/netfilter/ipset/ip_set_core.c
@@ -961,7 +961,7 @@ static int ip_set_create(struct net *net, struct sock *ctnl,
/* Wraparound */
goto cleanup;
- list = kcalloc(i, sizeof(struct ip_set *), GFP_KERNEL);
+ list = kvcalloc(i, sizeof(struct ip_set *), GFP_KERNEL);
if (!list)
goto cleanup;
/* nfnl mutex is held, both lists are valid */
@@ -973,7 +973,7 @@ static int ip_set_create(struct net *net, struct sock *ctnl,
/* Use new list */
index = inst->ip_set_max;
inst->ip_set_max = i;
- kfree(tmp);
+ kvfree(tmp);
ret = 0;
} else if (ret) {
goto cleanup;
@@ -2059,7 +2059,7 @@ ip_set_net_init(struct net *net)
if (inst->ip_set_max >= IPSET_INVALID_ID)
inst->ip_set_max = IPSET_INVALID_ID - 1;
- list = kcalloc(inst->ip_set_max, sizeof(struct ip_set *), GFP_KERNEL);
+ list = kvcalloc(inst->ip_set_max, sizeof(struct ip_set *), GFP_KERNEL);
if (!list)
return -ENOMEM;
inst->is_deleted = false;
@@ -2087,7 +2087,7 @@ ip_set_net_exit(struct net *net)
}
}
nfnl_unlock(NFNL_SUBSYS_IPSET);
- kfree(rcu_dereference_protected(inst->ip_set_list, 1));
+ kvfree(rcu_dereference_protected(inst->ip_set_list, 1));
}
static struct pernet_operations ip_set_net_ops = {
--
2.16.4
^ permalink raw reply related
* Re: [PATCH] Documentation: dpaa2: Use correct heading adornment
From: David Miller @ 2018-08-01 16:46 UTC (permalink / raw)
To: ioana.ciornei
Cc: corbet, laurentiu.tudor, stuyoder, linux-kernel, netdev,
linux-doc
In-Reply-To: <20180731154553.3648-1-ioana.ciornei@nxp.com>
From: Ioana Ciornei <ioana.ciornei@nxp.com>
Date: Tue, 31 Jul 2018 10:45:53 -0500
> Add overline heading adornment to document title in order to comply
> with kernel doc requirements.
>
> Fixes: 60b9131 staging: fsl-mc: Convert documentation to rst format
>
> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 9/9] bindings: net: stmmac: Add the bindings documentation for XGMAC2.
From: Sergei Shtylyov @ 2018-08-01 14:57 UTC (permalink / raw)
To: Jose Abreu, netdev
Cc: David S. Miller, Joao Pinto, Giuseppe Cavallaro, Alexandre Torgue
In-Reply-To: <e6ffc5e73f4beffb3809828a1646c09ded83661c.1533125016.git.joabreu@synopsys.com>
Hello!
On 08/01/2018 03:10 PM, Jose Abreu wrote:
> Adds the documentation for XGMAC2 DT bindings.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: Joao Pinto <jpinto@synopsys.com>
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> ---
> Documentation/devicetree/bindings/net/stmmac.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
> index 3a28a5d8857d..525425beb6e7 100644
> --- a/Documentation/devicetree/bindings/net/stmmac.txt
> +++ b/Documentation/devicetree/bindings/net/stmmac.txt
> @@ -1,7 +1,8 @@
> * STMicroelectronics 10/100/1000 Ethernet driver (GMAC)
>
> Required properties:
> -- compatible: Should be "snps,dwmac-<ip_version>", "snps,dwmac"
> +- compatible: Should be "snps,dwmac-<ip_version>", "snps,dwmac" or
> + "snps,dwxgmac-<ip_version", "snps,dwxgmac".
^ missing >
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] HID: Bluetooth: hidp: buffer overflow in hidp_process_report
From: Mark Salyzyn @ 2018-08-01 16:41 UTC (permalink / raw)
To: Greg KH
Cc: linux-kernel, Marcel Holtmann, Johan Hedberg, David S. Miller,
Kees Cook, Benjamin Tissoires, linux-bluetooth, netdev, stable,
kernel-team, Jiri Kosina
In-Reply-To: <20180801163703.GA6994@kroah.com>
On 08/01/2018 09:37 AM, Greg KH wrote:
> On Tue, Jul 31, 2018 at 03:02:13PM -0700, Mark Salyzyn wrote:
>> CVE-2018-9363
>>
>> The buffer length is unsigned at all layers, but gets cast to int and
>> checked in hidp_process_report and can lead to a buffer overflow.
>> Switch len parameter to unsigned int to resolve issue.
>>
>> This affects 3.18 and newer kernels.
>>
>> Signed-off-by: Mark Salyzyn <salyzyn@android.com>
>> Fixes: a4b1b5877b514b276f0f31efe02388a9c2836728 ("HID: Bluetooth: hidp: make sure input buffers are big enough")
>> Cc: Marcel Holtmann <marcel@holtmann.org>
>> Cc: Johan Hedberg <johan.hedberg@gmail.com>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: Kees Cook <keescook@chromium.org>
>> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>> Cc: linux-bluetooth@vger.kernel.org
>> Cc: netdev@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: security@kernel.org
>> Cc: kernel-team@android.com
> Nit, you only need to bother security@ if you do not have a fix and need
> to figure out one.
Thanks, I thought anything with a CVE was to go there according to
netdev FAQ (dropped security from response list).
> Also, you forgot to cc: stable@vger.kernel.org to be included in older
> kernel releases :(
netdev FAQ said to _not_ copy stable, I am so confused ;-{ (added stable
to response list b/c patch is now taken into bluetooth-next)
> thanks,
>
> greg k-h
^ permalink raw reply
* [PATCH] qede: fix null pointer dereference on skb on allocation failure
From: Colin King @ 2018-08-01 16:39 UTC (permalink / raw)
To: Ariel Elior, everest-linux-l2, David S . Miller, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
If skb fails to be allocated with the call to build_skb then a
null pointer dereference will occur on the call to skb_reserve.
Fix this by checking for a null skb and returning NULL.
Detected by CoverityScan, CID#1469485 ("Dereference null return value")
Fixes: 8a8633978b84 ("qede: Add build_skb() support.")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/qlogic/qede/qede_fp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_fp.c b/drivers/net/ethernet/qlogic/qede/qede_fp.c
index 6c702399b801..4b912ff5c0f3 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_fp.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_fp.c
@@ -730,6 +730,8 @@ qede_build_skb(struct qede_rx_queue *rxq,
buf = page_address(bd->data) + bd->page_offset;
skb = build_skb(buf, rxq->rx_buf_seg_size);
+ if (!skb)
+ return NULL;
skb_reserve(skb, pad);
skb_put(skb, len);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] net/mlx5e: Fix uninitialized variable
From: David Miller @ 2018-08-01 16:38 UTC (permalink / raw)
To: gustavo; +Cc: tariqt, saeedm, leon, netdev, linux-rdma, linux-kernel
In-Reply-To: <20180731142157.GA24066@embeddedor.com>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Tue, 31 Jul 2018 09:21:57 -0500
> There is a potential execution path in which variable *err* is returned
> without being properly initialized previously.
>
> Fix this by initializing variable *err* to 0.
>
> Addresses-Coverity-ID: 1472116 ("Uninitialized scalar variable")
> Fixes: 0ec13877ce95 ("net/mlx5e: Gather all XDP pre-requisite checks in a single function")
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next] qed: Make some functions static
From: David Miller @ 2018-08-01 16:37 UTC (permalink / raw)
To: yuehaibing; +Cc: Ariel.Elior, everest-linux-l2, linux-kernel, netdev
In-Reply-To: <20180731141230.10780-1-yuehaibing@huawei.com>
From: YueHaibing <yuehaibing@huawei.com>
Date: Tue, 31 Jul 2018 22:12:30 +0800
> Fixes the following sparse warning:
...
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH] HID: Bluetooth: hidp: buffer overflow in hidp_process_report
From: Greg KH @ 2018-08-01 16:37 UTC (permalink / raw)
To: Mark Salyzyn
Cc: linux-kernel, Marcel Holtmann, Johan Hedberg, David S. Miller,
Kees Cook, Benjamin Tissoires, linux-bluetooth, netdev, security,
kernel-team, Jiri Kosina
In-Reply-To: <20180731220225.159741-1-salyzyn@android.com>
On Tue, Jul 31, 2018 at 03:02:13PM -0700, Mark Salyzyn wrote:
> CVE-2018-9363
>
> The buffer length is unsigned at all layers, but gets cast to int and
> checked in hidp_process_report and can lead to a buffer overflow.
> Switch len parameter to unsigned int to resolve issue.
>
> This affects 3.18 and newer kernels.
>
> Signed-off-by: Mark Salyzyn <salyzyn@android.com>
> Fixes: a4b1b5877b514b276f0f31efe02388a9c2836728 ("HID: Bluetooth: hidp: make sure input buffers are big enough")
> Cc: Marcel Holtmann <marcel@holtmann.org>
> Cc: Johan Hedberg <johan.hedberg@gmail.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> Cc: linux-bluetooth@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: security@kernel.org
> Cc: kernel-team@android.com
Nit, you only need to bother security@ if you do not have a fix and need
to figure out one.
Also, you forgot to cc: stable@vger.kernel.org to be included in older
kernel releases :(
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 net-next] net: ethernet: ti: cpsw: replace unnecessarily macroses on functions
From: David Miller @ 2018-08-01 16:29 UTC (permalink / raw)
To: ivan.khoronzhuk
Cc: grygorii.strashko, linux-omap, netdev, linux-kernel, joe, andrew
In-Reply-To: <20180730220539.12319-1-ivan.khoronzhuk@linaro.org>
From: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Date: Tue, 31 Jul 2018 01:05:39 +0300
> Replace ugly macroses on functions.
>
> Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
> ---
> Based on net-next/master
Applied, thank you.
^ permalink raw reply
* Re: [PATCH bpf] xdp: add NULL pointer check in __xdp_return()
From: Björn Töpel @ 2018-08-01 14:43 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Taehee Yoo, kafai, Daniel Borkmann, ast, Björn Töpel,
Netdev
In-Reply-To: <20180801161414.24ebb238@redhat.com>
Den ons 1 aug. 2018 kl 16:14 skrev Jesper Dangaard Brouer <brouer@redhat.com>:
>
> On Mon, 23 Jul 2018 11:41:02 +0200
> Björn Töpel <bjorn.topel@gmail.com> wrote:
>
> > > >> diff --git a/net/core/xdp.c b/net/core/xdp.c
> > > >> index 9d1f220..1c12bc7 100644
> > > >> --- a/net/core/xdp.c
> > > >> +++ b/net/core/xdp.c
> > > >> @@ -345,7 +345,8 @@ static void __xdp_return(void *data, struct xdp_mem_info *mem, bool napi_direct,
> > > >> rcu_read_lock();
> > > >> /* mem->id is valid, checked in xdp_rxq_info_reg_mem_model() */
> > > >> xa = rhashtable_lookup(mem_id_ht, &mem->id, mem_id_rht_params);
> > > >> - xa->zc_alloc->free(xa->zc_alloc, handle);
> > > >> + if (xa)
> > > >> + xa->zc_alloc->free(xa->zc_alloc, handle);
> > > > hmm...It is not clear to me the "!xa" case don't have to be handled?
> > >
> > > Thank you for reviewing!
> > >
> > > Returning NULL pointer is bug case such as calling after use
> > > xdp_rxq_info_unreg().
> > > so that, I think it can't handle at that moment.
> > > we can make __xdp_return to add WARN_ON_ONCE() or
> > > add return error code to driver.
> > > But I'm not sure if these is useful information.
> > >
> > > I might have misunderstood scenario of MEM_TYPE_ZERO_COPY
> > > because there is no use case of MEM_TYPE_ZERO_COPY yet.
> > >
> >
> > Taehee, again, sorry for the slow response and thanks for patch!
> >
> > If xa is NULL, the driver has a buggy/broken implementation. What
> > would be a proper way of dealing with this? BUG?
>
> Hmm... I don't like these kind of changes to the hot-path code!
>
> You might not realize this, but adding BUG() and WARN_ON() to the code
> affect performance in ways you might not realize! These macros gets
> compiled and uses an asm instruction called "ud2". Seeing the "ud2"
> instruction causes the CPUs instruction cache prefetcher to stop.
> Thus, if some code ends up below this instruction, this will cause more
> i-cache-misses.
>
> I don't know if xa==NULL is even possible, but if it is, then I think
> this is a result of a driver mem_reg API usage bug. And the mem-reg
> API is full of WARN's and error messages, exactly to push these kind of
> checks out of the fast-path. There is no need for a BUG() call, as
> deref a NULL pointer will case an OOPS, that is easy to read and
> understand.
>
Jesper, thanks for having a look! So, you're right that if xa==NULL
the driver is "broken/buggy" (as stated earlier!). I agree that
OOPSing on a NULL pointer is as good as a BUG!
The applied patch adds a WARN_ON_ONCE, and I thought best practice was
that a buggy driver shouldn't crash the kernel... What is considered
best practices in these scenarios? *I'd* prefer an OOPS instead of
WARN_ON_ONCE, to catch that buggy driver. Again, that's me. I thought
that most people prefer not crashing, hence the patch. :-)
Björn
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: SLAB_TYPESAFE_BY_RCU without constructors (was Re: [PATCH v4 13/17] khwasan: add hooks implementation)
From: Eric Dumazet @ 2018-08-01 16:25 UTC (permalink / raw)
To: Christopher Lameter, Eric Dumazet
Cc: Dmitry Vyukov, Eric Dumazet, Andrey Ryabinin, Linus Torvalds,
Theodore Ts'o, jack, linux-ext4, Greg Kroah-Hartman,
Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David Miller, netfilter-devel, coreteam, netdev, Gerrit Renker,
dccp, jani.nikula, joonas.lahtinen, rodrigo.vivi, airlied,
intel-gfx, dri-devel
In-Reply-To: <01000164f64bd525-be13e04f-18a9-4f7f-a44b-0c0fcec33b71-000000@email.amazonses.com>
On 08/01/2018 09:22 AM, Christopher Lameter wrote:
> On Wed, 1 Aug 2018, Eric Dumazet wrote:
>
>> The idea of having a ctor() would only be a win if all the fields that
>> can be initialized in the ctor are contiguous and fill an integral
>> number of cache lines.
>
> Ok. Its reducing code size and makes the object status more consistent.
> Isn't that enough?
>
Prove it ;)
I yet have to seen actual numbers.
^ permalink raw reply
* Re: [PATCH net-next v5 1/4] net/sched: user-space can't set unknown tcfa_action values
From: Jamal Hadi Salim @ 2018-08-01 14:34 UTC (permalink / raw)
To: Paolo Abeni, netdev
Cc: Cong Wang, Jiri Pirko, Daniel Borkmann, Marcelo Ricardo Leitner,
Eyal Birger, David S. Miller
In-Reply-To: <e2a29da9514e38ab2caef2f2a592780e60ceda4c.camel@redhat.com>
On 31/07/18 10:40 AM, Paolo Abeni wrote:
> If we choose to reject unknown opcodes, such user-space configuration
> will fail.
>
I think that is a good thing. The kernel should not be accepting things
it doesnt understand. This is a good opportunity to enforce that.
> What would happen before this patch is that configurations using such
> TC_ACT_XXXX value would be successful. This is why I proposed to keep
> the fixup.
>
Note: Such behavior can only occur if tc(user space) allows you
to pass illegitimate values which today can only happen when you have a
new user space but older kernel (with "old" starting with your current
changes).
iow, fixing a policy in a kernel which has no support for TC_ACT_XXXX
to translate intent to be TC_ACT_OK/PIPE is problematic (as i was
showing earlier).
> I initially thought the kernel behavior in the above scenario would
> match exactly TC_ACT_UNSPEC processing, but as you noted with the
> example in your previous email, TC_ACT_UNSPEC processing is actually a
> bit different.
>
I worry: I dont think we can get a good default for most use
cases. No point in maintaining faulty expectations
(because IMO: the user will - eventually - fix their scripts if they
dont see expected behavior).
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 07/10] dt-bindings: phy: add DT binding for Microsemi Ocelot SerDes muxing
From: Andrew Lunn @ 2018-08-01 14:31 UTC (permalink / raw)
To: Quentin Schulz
Cc: alexandre.belloni, ralf, paul.burton, jhogan, robh+dt,
mark.rutland, davem, kishon, f.fainelli, linux-mips, devicetree,
linux-kernel, netdev, allan.nielsen, thomas.petazzoni
In-Reply-To: <20180801082413.2mjm52vwxw3anun6@qschulz>
> > Maybe this should be serdes-mux? The SERDES itself should have some
> > registers somewhere. If you ever decide to make use of phylink,
> > e.g. to support SFP, you are going to need to know if the SERDES is
> > up. So you might need to add the actual SERDES device, in addition to
> > the mux for the SERDES.
> >
>
> I'm not sure to follow.
>
> To be honest, I might have mislead you. The whole configuration of the
> serdes is in the hsio register address space. For now, muxing is the
> only reason there is a driver for the serdes but there are other things
> that can be configured (though not used yet): de/serializer, input/output
> buffers, PLL, ... configuration registers for the SerDes.
When you are using the SERDES for networking, you need to know if the
SERDES has achieved sync. For example, when the SERDES connects to an
optical SFP module, the SERDES bit stream continues unmodified over
the optical link to the SERDES in the peer. The optical module can
tell you if it is receiving optical power, but it cannot tell you if
the optical signal makes any sense. The SERDES however knows how to
decode the bitstream, sync to it, etc. So you need some registers in
the SERDES to get this status information. Typically, you can also get
access to the SGMII/1000Base-X code word, so you can do
auto-negotiation, or know if you need to send each bit 10 or 100 times
in order to do 100Mbps or 10Mbps. If you are connecting to a PHY which
can do > 1Gbps, you need to change the SERDES between SGMII,
1000Base-X, 2500Base-X, etc. Before you can say the link is up, you
want the PHY to tell you it has link to its peer PHY, and you want to
know the SERDES is ready. Typically the SERDES is last, since you
don't know what to configure the SERDES to until the PHY is finished
negotiating the link to its peer.
If you look at any of the Marvell SERDES interfaces, found in PHYs or
switches, there are dozens of registers for controlling the SERDES.
Now, it could be we don't have a clear definition of what a SERDES
is. The Marvell documents has a lot in its definition of SERDES, where
as what you could be purely a 'dumb' parallel to serial convert, and
all the rest of the logic is in the Ethernet MAC and the PCIe device?
Now, back to my original point. Where are the registers for 'the rest
of this logic'? If they are in the MAC address space, we don't have a
problem. If they are somewhere else, maybe you will need to add
another device. What is this device called? That is why i'm trying to
differentiate between the 'SERDES-MUX' and the 'SERDES'.
Andrew
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox