Netdev List
 help / color / mirror / Atom feed
* [bpf PATCH v2 2/2] bpf: sockmap only allow ESTABLISHED sock state
From: John Fastabend @ 2018-06-08 15:06 UTC (permalink / raw)
  To: edumazet, weiwan, daniel, ast; +Cc: netdev
In-Reply-To: <20180608145951.15153.80520.stgit@john-Precision-Tower-5810>

Per the note in the TLS ULP (which is actually a generic statement
regarding ULPs)

 /* The TLS ulp is currently supported only for TCP sockets
  * in ESTABLISHED state.
  * Supporting sockets in LISTEN state will require us
  * to modify the accept implementation to clone rather then
  * share the ulp context.
  */

After this patch we only allow socks that are in ESTABLISHED state or
are being added via a sock_ops event that is transitioning into an
ESTABLISHED state. By allowing sock_ops events we allow users to
manage sockmaps directly from sock ops programs. The two supported
sock_ops ops are BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB and
BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB.

Also tested with 'netserver -6' and 'netperf -H [IPv6]' as well as
'netperf -H [IPv4]'.

Reported-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
---
 kernel/bpf/sockmap.c |   32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index fa9b7f3..4921fb7 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -1956,8 +1956,12 @@ static int sock_map_update_elem(struct bpf_map *map,
 		return -EINVAL;
 	}
 
+	/* ULPs are currently supported only for TCP sockets in ESTABLISHED
+	 * state.
+	 */
 	if (skops.sk->sk_type != SOCK_STREAM ||
-	    skops.sk->sk_protocol != IPPROTO_TCP) {
+	    skops.sk->sk_protocol != IPPROTO_TCP ||
+	    skops.sk->sk_state != TCP_ESTABLISHED) {
 		fput(socket->file);
 		return -EOPNOTSUPP;
 	}
@@ -2318,6 +2322,16 @@ static int sock_hash_update_elem(struct bpf_map *map,
 		return -EINVAL;
 	}
 
+	/* ULPs are currently supported only for TCP sockets in ESTABLISHED
+	 * state.
+	 */
+	if (skops.sk->sk_type != SOCK_STREAM ||
+	    skops.sk->sk_protocol != IPPROTO_TCP ||
+	    skops.sk->sk_state != TCP_ESTABLISHED) {
+		fput(socket->file);
+		return -EOPNOTSUPP;
+	}
+
 	err = sock_hash_ctx_update_elem(&skops, map, key, flags);
 	fput(socket->file);
 	return err;
@@ -2403,10 +2417,23 @@ struct sock  *__sock_hash_lookup_elem(struct bpf_map *map, void *key)
 	.map_delete_elem = sock_hash_delete_elem,
 };
 
+static bool bpf_is_valid_sock(struct bpf_sock_ops_kern *ops)
+{
+	return ops->op == BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB ||
+	       ops->op == BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB;
+}
+
 BPF_CALL_4(bpf_sock_map_update, struct bpf_sock_ops_kern *, bpf_sock,
 	   struct bpf_map *, map, void *, key, u64, flags)
 {
 	WARN_ON_ONCE(!rcu_read_lock_held());
+
+	/* ULPs are currently supported only for TCP sockets in ESTABLISHED
+	 * state. This checks that the sock ops triggering the update is
+	 * one indicating we are (or will be soon) in an ESTABLISHED state.
+	 */
+	if (!bpf_is_valid_sock(bpf_sock))
+		return -EOPNOTSUPP;
 	return sock_map_ctx_update_elem(bpf_sock, map, key, flags);
 }
 
@@ -2425,6 +2452,9 @@ struct sock  *__sock_hash_lookup_elem(struct bpf_map *map, void *key)
 	   struct bpf_map *, map, void *, key, u64, flags)
 {
 	WARN_ON_ONCE(!rcu_read_lock_held());
+
+	if (!bpf_is_valid_sock(bpf_sock))
+		return -EOPNOTSUPP;
 	return sock_hash_ctx_update_elem(bpf_sock, map, key, flags);
 }
 

^ permalink raw reply related

* [bpf PATCH v2 1/2] bpf: sockmap, fix crash when ipv6 sock is added
From: John Fastabend @ 2018-06-08 15:06 UTC (permalink / raw)
  To: edumazet, weiwan, daniel, ast; +Cc: netdev
In-Reply-To: <20180608145951.15153.80520.stgit@john-Precision-Tower-5810>

This fixes a crash where we assign tcp_prot to IPv6 sockets instead
of tcpv6_prot.

Previously we overwrote the sk->prot field with tcp_prot even in the
AF_INET6 case. This patch ensures the correct tcp_prot and tcpv6_prot
are used. Further, only allow ESTABLISHED connections to join the
map per note in TLS ULP,

   /* The TLS ulp is currently supported only for TCP sockets
    * in ESTABLISHED state.
    * Supporting sockets in LISTEN state will require us
    * to modify the accept implementation to clone rather then
    * share the ulp context.
    */

Also tested with 'netserver -6' and 'netperf -H [IPv6]' as well as
'netperf -H [IPv4]'. The ESTABLISHED check resolves the previously
crashing case here.

Fixes: 174a79ff9515 ("bpf: sockmap with sk redirect support")
Reported-by: syzbot+5c063698bdbfac19f363@syzkaller.appspotmail.com
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Wei Wang <weiwan@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
 kernel/bpf/sockmap.c |   24 +++++++++++++++++++++---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/kernel/bpf/sockmap.c b/kernel/bpf/sockmap.c
index 52a91d8..fa9b7f3 100644
--- a/kernel/bpf/sockmap.c
+++ b/kernel/bpf/sockmap.c
@@ -41,6 +41,7 @@
 #include <linux/mm.h>
 #include <net/strparser.h>
 #include <net/tcp.h>
+#include <net/transp_v6.h>
 #include <linux/ptr_ring.h>
 #include <net/inet_common.h>
 #include <linux/sched/signal.h>
@@ -140,6 +141,7 @@ static int bpf_tcp_recvmsg(struct sock *sk, struct msghdr *msg, size_t len,
 static int bpf_tcp_sendmsg(struct sock *sk, struct msghdr *msg, size_t size);
 static int bpf_tcp_sendpage(struct sock *sk, struct page *page,
 			    int offset, size_t size, int flags);
+static void bpf_tcp_close(struct sock *sk, long timeout);
 
 static inline struct smap_psock *smap_psock_sk(const struct sock *sk)
 {
@@ -162,6 +164,8 @@ static bool bpf_tcp_stream_read(const struct sock *sk)
 }
 
 static struct proto tcp_bpf_proto;
+static struct proto tcpv6_bpf_proto;
+
 static int bpf_tcp_init(struct sock *sk)
 {
 	struct smap_psock *psock;
@@ -181,14 +185,30 @@ static int bpf_tcp_init(struct sock *sk)
 	psock->save_close = sk->sk_prot->close;
 	psock->sk_proto = sk->sk_prot;
 
+	if (sk->sk_family == AF_INET6) {
+		tcpv6_bpf_proto = *sk->sk_prot;
+		tcpv6_bpf_proto.close = bpf_tcp_close;
+	} else {
+		tcp_bpf_proto = *sk->sk_prot;
+		tcp_bpf_proto.close = bpf_tcp_close;
+	}
+
 	if (psock->bpf_tx_msg) {
+		tcpv6_bpf_proto.sendmsg = bpf_tcp_sendmsg;
+		tcpv6_bpf_proto.sendpage = bpf_tcp_sendpage;
+		tcpv6_bpf_proto.recvmsg = bpf_tcp_recvmsg;
+		tcpv6_bpf_proto.stream_memory_read = bpf_tcp_stream_read;
 		tcp_bpf_proto.sendmsg = bpf_tcp_sendmsg;
 		tcp_bpf_proto.sendpage = bpf_tcp_sendpage;
 		tcp_bpf_proto.recvmsg = bpf_tcp_recvmsg;
 		tcp_bpf_proto.stream_memory_read = bpf_tcp_stream_read;
 	}
 
-	sk->sk_prot = &tcp_bpf_proto;
+	if (sk->sk_family == AF_INET6)
+		sk->sk_prot = &tcpv6_bpf_proto;
+	else
+		sk->sk_prot = &tcp_bpf_proto;
+
 	rcu_read_unlock();
 	return 0;
 }
@@ -1111,8 +1131,6 @@ static void bpf_tcp_msg_add(struct smap_psock *psock,
 
 static int bpf_tcp_ulp_register(void)
 {
-	tcp_bpf_proto = tcp_prot;
-	tcp_bpf_proto.close = bpf_tcp_close;
 	/* Once BPF TX ULP is registered it is never unregistered. It
 	 * will be in the ULP list for the lifetime of the system. Doing
 	 * duplicate registers is not a problem.

^ permalink raw reply related

* [bpf PATCH v2 0/2] bpf, sockmap IPv6/TCP state fixes
From: John Fastabend @ 2018-06-08 15:06 UTC (permalink / raw)
  To: edumazet, weiwan, daniel, ast; +Cc: netdev

ULP are only valid with TCP in ESTABLISHED states. Sockmap was not
following this rule so add a fix to only allow ESTABLISHED states to
be added from the userspace side. On the BPF side we continue to allow
adding sockets to maps from sock_ops events, but only events that are
triggered when entering the ESTABLISHED state. This blocks users from
adding sockets to maps that will not be in the correct TCP state.

Also we stomped on the tcpv6_prot pointer overwriting with the
tcp_prot. This was discovered by syzbot (thanks!) and not found by
selftests because we only have local tests in selftest so even with
ipv6 selftests we did not trigger the splat.

Will follow up with IPv6 tests for selftest regardless it seems like
a miss to not have any IPv6 selftests.

Also these need to go to stable. There will be a small conflict on
the second patch where we add check to the sockhash update function
which did not exist until recently.

---

John Fastabend (2):
      bpf: sockmap, fix crash when ipv6 sock is added
      bpf: sockmap only allow ESTABLISHED sock state


 kernel/bpf/sockmap.c |   56 ++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 52 insertions(+), 4 deletions(-)

^ permalink raw reply

* Re: [PATCH] net: stmmac: fix build failure due to missing COMMON_CLK dependency
From: David Miller @ 2018-06-08 14:59 UTC (permalink / raw)
  To: clabbe; +Cc: alexandre.torgue, peppe.cavallaro, linux-kernel, netdev,
	linux-sunxi
In-Reply-To: <1528310722-11512-1-git-send-email-clabbe@baylibre.com>

From: Corentin Labbe <clabbe@baylibre.com>
Date: Wed,  6 Jun 2018 18:45:22 +0000

> This patch fix the build failure on m68k;
> drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.o: In function `ipq806x_gmac_probe':
> dwmac-ipq806x.c:(.text+0xda): undefined reference to `clk_set_rate'
> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.o: In function `rk_gmac_probe':
> dwmac-rk.c:(.text+0x1e58): undefined reference to `clk_set_rate'
> drivers/net/ethernet/stmicro/stmmac/dwmac-sti.o: In function `stid127_fix_retime_src':
> dwmac-sti.c:(.text+0xd8): undefined reference to `clk_set_rate'
> dwmac-sti.c:(.text+0x114): undefined reference to `clk_set_rate'
> drivers/net/ethernet/stmicro/stmmac/dwmac-sti.o:dwmac-sti.c:(.text+0x12c): more undefined references to `clk_set_rate' follow
> Lots of stmmac platform drivers need COMMON_CLK in their Kconfig depends.
> 
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>

Applied.

^ permalink raw reply

* Re: [PATCH v2] net-fq: Add WARN_ON check for null flow.
From: Eric Dumazet @ 2018-06-08 14:53 UTC (permalink / raw)
  To: Ben Greear, Cong Wang; +Cc: Linux Kernel Network Developers
In-Reply-To: <99455a63-4a19-e172-a9b4-e7d8935cb1e0@candelatech.com>



On 06/08/2018 07:10 AM, Ben Greear wrote:
> Maybe whoever put this code together can take a stab at it.
> 

This was one one the motivation for the Fixes: tag request.

By doing a git blame, you can find which commit(s) added this code,
and thus CC the author, who might not follow netdev@ closely.

^ permalink raw reply

* Re: [PATCH net] kcm: fix races on sk_receive_queue
From: David Miller @ 2018-06-08 14:53 UTC (permalink / raw)
  To: pabeni; +Cc: netdev, tom, ktkhai
In-Reply-To: <628e0398546aefabd68669450621909d269e1ba8.1528289745.git.pabeni@redhat.com>

From: Paolo Abeni <pabeni@redhat.com>
Date: Wed,  6 Jun 2018 15:16:29 +0200

> @@ -1126,7 +1132,7 @@ static int kcm_recvmsg(struct socket *sock, struct msghdr *msg,
>  
>  	lock_sock(sk);
>  
> -	skb = kcm_wait_data(sk, flags, timeo, &err);
> +	skb = kcm_wait_data(sk, flags, peek, timeo, &err);
>  	if (!skb)
>  		goto out;
>  

Because kcm_wait_data() potentially unlinks now, you will have to kfree the
SKB in the error paths, for example if skb_copy_datagram_msg() fails.

Otherwise we have an SKB leak.

Yeah, it's kind of ugly that kcm_recvmsg() is going to become a pile of
conditional operations based upon the peek boolean. :-/

^ permalink raw reply

* [PATCH] net: phy: Add TJA1100 BroadR-Reach PHY driver.
From: Kirill Kranke @ 2018-06-08 14:45 UTC (permalink / raw)
  To: andrew, f.fainelli, davem, netdev; +Cc: Kirill Kranke
In-Reply-To: <20180608134032.GA16663@lunn.ch>

Current generic PHY driver does not work with TJA1100 BroadR-REACH PHY
properly. TJA1100 does not have any standard ability enabled at MII_BMSR
register. Instead it has BroadR-REACH ability at MII_ESTATUS enabled, which
is not handled by generic driver yet. Therefore generic driver is unable to
guess required link speed, duplex etc. Device is started up with 10Mbps
halfduplex which is incorrect.

BroadR-REACH able flag is not specified in IEEE802.3-2015. Which is why I
did not add BroadR-REACH able flag support at generic driver. Once
BroadR-REACH able flag gets into IEEE802.3 it should be reasonable to
support it in the generic PHY driver.

Signed-off-by: Kirill Kranke <kranke.kirill@gmail.com>

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 343989f..7014eb7 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -422,6 +422,14 @@ config TERANETICS_PHY
 	---help---
 	  Currently supports the Teranetics TN2020
 
+config TJA1100_PHY
+	tristate "NXP TJA1100 PHY"
+	help
+	  Support of NXP TJA1100 BroadR-REACH ethernet PHY.
+	  Generic driver is not suitable for TJA1100 PHY while the PHY does not
+	  advertise any standard IEEE capabilities. It uses BroadR-REACH able
+	  flag instead. This driver configures capabilities of the PHY properly.
+
 config VITESSE_PHY
 	tristate "Vitesse PHYs"
 	---help---
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 5805c0b..4d2a69d 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -83,5 +83,6 @@ obj-$(CONFIG_ROCKCHIP_PHY)	+= rockchip.o
 obj-$(CONFIG_SMSC_PHY)		+= smsc.o
 obj-$(CONFIG_STE10XP)		+= ste10Xp.o
 obj-$(CONFIG_TERANETICS_PHY)	+= teranetics.o
+obj-$(CONFIG_TJA1100_PHY)	+= tja1100.o
 obj-$(CONFIG_VITESSE_PHY)	+= vitesse.o
 obj-$(CONFIG_XILINX_GMII2RGMII) += xilinx_gmii2rgmii.o
diff --git a/drivers/net/phy/tja1100.c b/drivers/net/phy/tja1100.c
new file mode 100644
index 0000000..cddf4d7
--- /dev/null
+++ b/drivers/net/phy/tja1100.c
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: GPL-2.0
+/* tja1100.c: TJA1100 BoardR-REACH PHY driver.
+ *
+ * Copyright (c) 2017 Kirill Kranke <kirill.kranke@gmail.com>
+ * Author: Kirill Kranke <kirill.kranke@gmail.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/phy.h>
+
+static int tja1100_phy_config_init(struct phy_device *phydev)
+{
+	phydev->autoneg = AUTONEG_DISABLE;
+	phydev->speed = SPEED_100;
+	phydev->duplex = DUPLEX_FULL;
+
+	return 0;
+}
+
+static int tja1100_phy_config_aneg(struct phy_device *phydev)
+{
+	if (phydev->autoneg == AUTONEG_ENABLE) {
+		phydev_err(phydev, "autonegotiation is not supported\n");
+		return -EINVAL;
+	}
+
+	if (phydev->speed != SPEED_100 || phydev->duplex != DUPLEX_FULL) {
+		phydev_err(phydev, "only 100MBps Full Duplex allowed\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static struct phy_driver tja1100_phy_driver[] = {
+	{
+		.phy_id = 0x0180dc48,
+		.phy_id_mask = 0xfffffff0,
+		.name = "NXP TJA1100",
+
+		/* TJA1100 has only 100BASE-BroadR-REACH ability specified
+		 * at MII_ESTATUS register. Standard modes are not
+		 * supported. Therefore BroadR-REACH allow only 100Mbps
+		 * full duplex without autoneg.
+		 */
+		.features = SUPPORTED_100baseT_Full | SUPPORTED_MII,
+
+		.config_aneg = tja1100_phy_config_aneg,
+		.config_init = tja1100_phy_config_init,
+
+		.suspend = genphy_suspend,
+		.resume = genphy_resume,
+	}
+};
+
+module_phy_driver(tja1100_phy_driver);
+
+MODULE_DESCRIPTION("NXP TJA1100 driver");
+MODULE_AUTHOR("Kirill Kranke <kkranke@topcon.com>");
+MODULE_LICENSE("GPL");
+
+static struct mdio_device_id __maybe_unused nxp_tbl[] = {
+	{ 0x0180dc48, 0xfffffff0 },
+	{}
+};
+
+MODULE_DEVICE_TABLE(mdio, nxp_tbl);

^ permalink raw reply related

* Re: [PATCH v2] net-fq: Add WARN_ON check for null flow.
From: Ben Greear @ 2018-06-08 14:10 UTC (permalink / raw)
  To: Cong Wang; +Cc: Linux Kernel Network Developers
In-Reply-To: <CAM_iQpU8PjkQgmHRSi144L0LHUXrbOKYaetqUV3ECHzWs2cD-A@mail.gmail.com>



On 06/07/2018 05:13 PM, Cong Wang wrote:
> On Thu, Jun 7, 2018 at 4:48 PM,  <greearb@candelatech.com> wrote:
>> From: Ben Greear <greearb@candelatech.com>
>>
>> While testing an ath10k firmware that often crashed under load,
>> I was seeing kernel crashes as well.  One of them appeared to
>> be a dereference of a NULL flow object in fq_tin_dequeue.
>>
>> I have since fixed the firmware flaw, but I think it would be
>> worth adding the WARN_ON in case the problem appears again.
>>
>> BUG: unable to handle kernel NULL pointer dereference at 000000000000003c
>> IP: ieee80211_tx_dequeue+0xfb/0xb10 [mac80211]
>
> Instead of adding WARN_ON(), you need to think about
> the locking there, it is suspicious:
>
> fq is from struct ieee80211_local:
>
> struct fq *fq = &local->fq;
>
> tin is from struct txq_info:
>
> struct fq_tin *tin = &txqi->tin;
>
> I don't know if fq and tin are supposed to be 1:1, if not there is
> a bug in the locking, because ->new_flows and ->old_flows are
> both inside tin instead of fq, but they are protected by fq->lock....

Maybe whoever put this code together can take a stab at it.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

^ permalink raw reply

* Re: [PATCH v2] net-fq: Add WARN_ON check for null flow.
From: Ben Greear @ 2018-06-08 14:08 UTC (permalink / raw)
  To: Cong Wang; +Cc: Linux Kernel Network Developers
In-Reply-To: <CAM_iQpULrWMNtgDcrZkc-uLtB0XOVFeZxQ6cFgpXwv7DtA9jzA@mail.gmail.com>



On 06/07/2018 04:59 PM, Cong Wang wrote:
> On Thu, Jun 7, 2018 at 4:48 PM,  <greearb@candelatech.com> wrote:
>> diff --git a/include/net/fq_impl.h b/include/net/fq_impl.h
>> index be7c0fa..cb911f0 100644
>> --- a/include/net/fq_impl.h
>> +++ b/include/net/fq_impl.h
>> @@ -78,7 +78,10 @@ static struct sk_buff *fq_tin_dequeue(struct fq *fq,
>>                         return NULL;
>>         }
>>
>> -       flow = list_first_entry(head, struct fq_flow, flowchain);
>> +       flow = list_first_entry_or_null(head, struct fq_flow, flowchain);
>> +
>> +       if (WARN_ON_ONCE(!flow))
>> +               return NULL;
>
> This does not make sense either. list_first_entry_or_null()
> returns NULL only when the list is empty, but we already check
> list_empty() right before this code, and it is protected by fq->lock.
>

Nevermind then.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

^ permalink raw reply

* Re: BUG: unable to handle kernel NULL pointer dereference in corrupted
From: Tetsuo Handa @ 2018-06-08 14:08 UTC (permalink / raw)
  To: Dmitry Vyukov, syzbot, ubraun, linux-s390
  Cc: David Miller, LKML, netdev, syzkaller-bugs
In-Reply-To: <CACT4Y+Z9PL4m85TGBfoLLOrw3PtqiCf+vLgdXnLUMPmHcBC33A@mail.gmail.com>

On 2018/06/08 22:39, Dmitry Vyukov wrote:
> On Fri, Jun 8, 2018 at 3:11 PM, syzbot
> <syzbot+f5066e369b2d5fff630f@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:    68abbe729567 Merge branch 'akpm' (patches from Andrew)
>> git tree:       upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=16f7cebf800000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=e5a4673d4582131c
>> dashboard link: https://syzkaller.appspot.com/bug?extid=f5066e369b2d5fff630f
>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1191756f800000
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=162236af800000
> 
> The reproducer suggests that this is in smc.
> +smc maintainers

Yes, an unprivileged user can trigger this oops.

----------
#include <sys/socket.h>
#include <sys/epoll.h>
#define PF_SMC 43

int main(int argc, char *argv[])
{
	struct epoll_event ev = { };
	int sfd = socket(PF_SMC, SOCK_STREAM, 0);
	int epfd = epoll_create(1);
	epoll_ctl(epfd, EPOLL_CTL_ADD, sfd, &ev);
	return 0;
}
----------

^ permalink raw reply

* Re: net-next boot error: KASAN: use-after-free Write in call_usermodehelper_exec_work
From: Dmitry Vyukov @ 2018-06-08 14:05 UTC (permalink / raw)
  To: syzbot, netdev, David Miller, Alexei Starovoitov
  Cc: LKML, Luis R. Rodriguez, syzkaller-bugs
In-Reply-To: <CACT4Y+Z-+Rw9GfX4Q0HJxJtpMcRGO5EFj15cqOhJiEGkntcOMg@mail.gmail.com>

On Sun, May 27, 2018 at 7:40 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Sun, May 27, 2018 at 7:34 AM, syzbot
> <syzbot+9269ae80345087b898d0@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:    5b79c2af667c Merge git://git.kernel.org/pub/scm/linux/kern..
>> git tree:       net-next
>> console output: https://syzkaller.appspot.com/x/log.txt?x=16087fa7800000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=e4078980b886800c
>> dashboard link: https://syzkaller.appspot.com/bug?extid=9269ae80345087b898d0
>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>>
>> Unfortunately, I don't have any reproducer for this crash yet.
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+9269ae80345087b898d0@syzkaller.appspotmail.com
>
>
> This first happened just now on net-next, so +net maintainers.
> This happened during boot, so no separate reproducer.


Could fix this before it reaches Linus tree...

#syz fix: umh: fix race condition


>> FS-Cache: Loaded
>> CacheFiles: Loaded
>> pnp: PnP ACPI init
>> pnp: PnP ACPI: found 7 devices
>> ==================================================================
>> BUG: KASAN: use-after-free in call_usermodehelper_exec_work+0x2d3/0x310
>> kernel/umh.c:195
>> Write of size 4 at addr ffff8801d63bd370 by task kworker/u4:0/6
>>
>> CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 4.17.0-rc6+ #65
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Workqueue: events_unbound call_usermodehelper_exec_work
>> Call Trace:
>>  __dump_stack lib/dump_stack.c:77 [inline]
>>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>>  print_address_description+0x6c/0x20b mm/kasan/report.c:256
>>  kasan_report_error mm/kasan/report.c:354 [inline]
>>  kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
>>  __asan_report_store4_noabort+0x17/0x20 mm/kasan/report.c:437
>>  call_usermodehelper_exec_work+0x2d3/0x310 kernel/umh.c:195
>>  process_one_work+0xc1e/0x1b50 kernel/workqueue.c:2145
>>  worker_thread+0x1cc/0x1440 kernel/workqueue.c:2279
>>  kthread+0x345/0x410 kernel/kthread.c:240
>>  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
>>
>> Allocated by task 1:
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:448
>>  set_track mm/kasan/kasan.c:460 [inline]
>>  kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
>>  kmem_cache_alloc_trace+0x152/0x780 mm/slab.c:3620
>>  kmalloc include/linux/slab.h:512 [inline]
>>  kzalloc include/linux/slab.h:701 [inline]
>>  call_usermodehelper_setup+0xe8/0x400 kernel/umh.c:382
>> clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns:
>> 2085701024 ns
>>  kobject_uevent_env+0xb21/0x1110 lib/kobject_uevent.c:608
>>  kobject_uevent+0x1f/0x30 lib/kobject_uevent.c:636
>>  device_add+0xb01/0x16d0 drivers/base/core.c:1843
>>  device_create_groups_vargs+0x1ff/0x270 drivers/base/core.c:2439
>>  device_create_vargs drivers/base/core.c:2479 [inline]
>>  device_create+0xd3/0x100 drivers/base/core.c:2515
>>  chr_dev_init+0x120/0x158 drivers/char/mem.c:938
>>  do_one_initcall+0x127/0x913 init/main.c:884
>>  do_initcall_level init/main.c:952 [inline]
>>  do_initcalls init/main.c:960 [inline]
>>  do_basic_setup init/main.c:978 [inline]
>>  kernel_init_freeable+0x49b/0x58e init/main.c:1135
>>  kernel_init+0x11/0x1b3 init/main.c:1061
>>  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
>>
>> Freed by task 1296:
>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:448
>> NET: Registered protocol family 2
>>  set_track mm/kasan/kasan.c:460 [inline]
>>  __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
>>  kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
>>  __cache_free mm/slab.c:3498 [inline]
>>  kfree+0xd9/0x260 mm/slab.c:3813
>>  call_usermodehelper_freeinfo kernel/umh.c:45 [inline]
>>  umh_complete+0x7b/0x90 kernel/umh.c:59
>>  call_usermodehelper_exec_async+0x6e8/0x9e0 kernel/umh.c:116
>> tcp_listen_portaddr_hash hash table entries: 4096 (order: 6, 294912 bytes)
>>  ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
>>
>> The buggy address belongs to the object at ffff8801d63bd300
>>  which belongs to the cache kmalloc-192 of size 192
>> The buggy address is located 112 bytes inside of
>>  192-byte region [ffff8801d63bd300, ffff8801d63bd3c0)
>> The buggy address belongs to the page:
>> TCP established hash table entries: 65536 (order: 7, 524288 bytes)
>> page:ffffea000758ef40 count:1 mapcount:0 mapping:ffff8801d63bd000 index:0x0
>> flags: 0x2fffc0000000100(slab)
>> raw: 02fffc0000000100 ffff8801d63bd000 0000000000000000 0000000100000010
>> TCP bind hash table entries: 65536 (order: 10, 4194304 bytes)
>> raw: ffffea000759c2e0 ffffea0007521be0 ffff8801da800040 0000000000000000
>> page dumped because: kasan: bad access detected
>>
>> Memory state around the buggy address:
>>  ffff8801d63bd200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>  ffff8801d63bd280: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>>>
>>> ffff8801d63bd300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>
>> TCP: Hash tables configured (established 65536 bind 65536)
>>                                                              ^
>>  ffff8801d63bd380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
>>  ffff8801d63bd400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ==================================================================
>> UDP hash table entries: 4096 (order: 7, 655360 bytes)
>> UDP-Lite hash table entries: 4096 (order: 7, 655360 bytes)
>>
>>
>> ---
>> This bug is generated by a bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for more information about syzbot.
>> syzbot engineers can be reached at syzkaller@googlegroups.com.
>>
>> syzbot will keep track of this bug report. See:
>> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
>> syzbot.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to syzkaller-bugs+unsubscribe@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/syzkaller-bugs/000000000000424989056d295959%40google.com.
>> For more options, visit https://groups.google.com/d/optout.

^ permalink raw reply

* Re: WARNING in do_dentry_open
From: Daniel Borkmann @ 2018-06-08 13:47 UTC (permalink / raw)
  To: Dmitry Vyukov, syzbot, Alexei Starovoitov, netdev
  Cc: linux-fsdevel, LKML, syzkaller-bugs, Al Viro
In-Reply-To: <CACT4Y+b+6XrNfHmZSBitOKqVHYaq-aOgMDnHhp3vKEVs117iJA@mail.gmail.com>

On 06/08/2018 03:34 PM, Dmitry Vyukov wrote:
> On Fri, Jun 8, 2018 at 3:11 PM, syzbot
> <syzbot+2e7fcab0f56fdbb330b8@syzkaller.appspotmail.com> wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:    68abbe729567 Merge branch 'akpm' (patches from Andrew)
>> git tree:       upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=130146af800000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=e5a4673d4582131c
>> dashboard link: https://syzkaller.appspot.com/bug?extid=2e7fcab0f56fdbb330b8
>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1591756f800000
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=152236af800000
> 
> Looking at the reproducer this seems to be related to bpf.
> +bpf maintainers

Indeed, thanks! Already working on a fix right now.

^ permalink raw reply

* Re: [PATCH] net: phy: Add TJA1100 BroadR-Reach PHY driver.
From: Andrew Lunn @ 2018-06-08 13:40 UTC (permalink / raw)
  To: Kirill Kranke; +Cc: f.fainelli, davem, netdev, Kirill Kranke
In-Reply-To: <1528451799-2481-1-git-send-email-kranke.kirill@gmail.com>

On Fri, Jun 08, 2018 at 12:56:39PM +0300, Kirill Kranke wrote:
> From: Kirill Kranke <kirill.kranke@gmail.com>
> 
> Current generic PHY driver does not work with TJA1100 BroadR-REACH PHY
> properly. TJA1100 does not have any standard ability enabled at MII_BMSR
> register. Instead it has BroadR-REACH ability at MII_ESTATUS enabled, which
> is not handled by generic driver yet. Therefore generic driver is unable to
> guess required link speed, duplex etc. Device is started up with 10Mbps
> halfduplex which is incorrect.
> 
> BroadR-REACH able flag is not specified in IEEE802.3-2015. Which is why I
> did not add BroadR-REACH able flag support at generic driver. Once
> BroadR-REACH able flag gets into IEEE802.3 it should be reasonable to
> support it in the generic PHY driver.
> 
> Signed-off-by: Kirill Kranke <kirill.kranke@gmail.com>
> 
> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> index 343989f..7014eb7 100644
> --- a/drivers/net/phy/Kconfig
> +++ b/drivers/net/phy/Kconfig
> @@ -422,6 +422,14 @@ config TERANETICS_PHY
>  	---help---
>  	  Currently supports the Teranetics TN2020
>  
> +config TJA1100_PHY
> +	tristate "NXP TJA1100 PHY"
> +	help
> +	  Support of NXP TJA1100 BroadR-REACH ethernet PHY.
> +	  Generic driver is not suitable for TJA1100 PHY while the PHY does not
> +	  advertise any standard IEEE capabilities. It uses BroadR-REACH able
> +	  flag instead. This driver configures capabilities of the PHY properly.
> +
>  config VITESSE_PHY
>  	tristate "Vitesse PHYs"
>  	---help---
> diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> index 5805c0b..4d2a69d 100644
> --- a/drivers/net/phy/Makefile
> +++ b/drivers/net/phy/Makefile
> @@ -83,5 +83,6 @@ obj-$(CONFIG_ROCKCHIP_PHY)	+= rockchip.o
>  obj-$(CONFIG_SMSC_PHY)		+= smsc.o
>  obj-$(CONFIG_STE10XP)		+= ste10Xp.o
>  obj-$(CONFIG_TERANETICS_PHY)	+= teranetics.o
> +obj-$(CONFIG_TJA1100_PHY)	+= tja1100.o
>  obj-$(CONFIG_VITESSE_PHY)	+= vitesse.o
>  obj-$(CONFIG_XILINX_GMII2RGMII) += xilinx_gmii2rgmii.o
> diff --git a/drivers/net/phy/tja1100.c b/drivers/net/phy/tja1100.c
> new file mode 100644
> index 0000000..081b580
> --- /dev/null
> +++ b/drivers/net/phy/tja1100.c
> @@ -0,0 +1,215 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* tja1100.c: TJA1100 BoardR-REACH PHY driver.
> + *
> + * Copyright (c) 2017 Kirill Kranke <kirill.kranke@gmail.com>
> + * Author: Kirill Kranke <kirill.kranke@gmail.com>
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/phy.h>
> +
> +/* TJA1100 specific registers */
> +#define TJA1100_ECTRL	0x11	/* Extended control register */
> +#define TJA1100_CFG1	0x12	/* Configuration register 1 */
> +#define TJA1100_CFG2	0x13	/* Configuration register 2 */
> +#define TJA1100_SERRCNT	0x14	/* Symbol error counter register 2 */
> +#define TJA1100_INTST	0x15	/* Interrupt status register */
> +#define TJA1100_INTEN	0x16	/* Interrupt enable register */
> +#define TJA1100_COMST	0x17	/* Communication status register */
> +#define TJA1100_GST	0x18	/* General status register */
> +#define TJA1100_EXTST	0x19	/* External status register */
> +#define TJA1100_LFCNT	0x1a	/* Link fail counter register */
> +
> +/* Extended control register */
> +#define ECTRL_LC	0x8000	/* link control enable */
> +#define ECTRL_PM	0x7800	/* operating mode select */
> +#define ECTRL_PM_NOCNG	0x0000	/* PM == 0000: no change */
> +#define ECTRL_PM_NORMAL	0x1800	/* PM == 0011: Normal mode */
> +#define ECTRL_PM_STANBY	0x6000	/* PM == 1100: Standby mode */
> +#define ECTRL_PM_SREQ	0x5800	/* PM == 1011: Sleep Request mode */
> +#define ECTRL_SJ_TST	0x0400	/* enable/disable Slave jitter test */
> +#define ECTRL_TR_RST	0x0200	/* Autonegotiation process restart */
> +#define ECTRL_TST_MODE	0x01c0	/* test mode selection */
> +#define ECTRL_C_TST	0x0020	/* TDR-based cable test */
> +#define ECTRL_LOOPBACK	0x0018	/* loopback mode select */
> +#define ECTRL_CFGEN	0x0004	/* configuration register access */
> +#define ECTRL_CFGINH	0x0002	/* INH configuration */
> +#define ECTRL_WAKE_REQ	0x0001	/* wake-up request configuration */
> +
> +/* Configuration register 1 */
> +#define CFG1_MS		0x8000	/* PHY Master/Slave configuration */
> +#define CFG1_AUTO_OP	0x4000	/* managed/autonomous operation */
> +#define CFG1_LINKLEN	0x2000	/* cable length: 0 < 15 m; 1 > 15 m */
> +#define CFG1_TXAMP	0x0c00	/* nominal transmit amplitude */
> +#define CFG1_TXAMP_050	0x0000	/* TXAMP == 00: 500 mV */
> +#define CFG1_TXAMP_075	0x0200	/* TXAMP == 01: 750 mV */
> +#define CFG1_TXAMP_100	0x0400	/* TXAMP == 10: 1000 mV */
> +#define CFG1_TXAMP_125	0x0c00	/* TXAMP == 11: 1250 mV */
> +#define CFG1_MODE	0x0300	/* MII/RMII mode */
> +#define CFG1_DRIVER	0x0080	/* MII output driver strength */
> +#define CFG1_SC		0x0040	/* sleep confirmation setting */
> +#define CFG1_LED_MODE	0x0030	/* LED mode */
> +#define CFG1_LED_EN	0x0008	/* LED enable */
> +#define CFG1_CFG_WAKE	0x0004	/* local wake configuration */
> +#define CFG1_APWD	0x0002	/* autonomous power down */
> +#define CFG1_LPS	0x0001	/* LPS code group reception */
> +
> +/* Configuration register 2 */
> +#define CFG2_PHYAD_4_0	0xf800	/* PHY address used for the SMI addr */
> +#define CFG2_SNR_AVG	0x0600	/* signal-to-noise ratio averaging */
> +#define CFG2_SNR_WLIM	0x01c0	/* signal-to-noise ratio warning limit */
> +#define CFG2_SNR_FLIM	0x0038	/* signal-to-noise ratio fail limit */
> +#define CFG2_JUMBO_EN	0x0004	/* Jumbo packet support */
> +#define CFG2_SRTO	0x0003	/* sleep request time-out */
> +#define CFG2_SRTO_04	0x0000	/* SRTO == 00: 0.4 ms */
> +#define CFG2_SRTO_1	0x0001	/* SRTO == 01: 1 ms */
> +#define CFG2_SRTO_4	0x0002	/* SRTO == 10: 4 ms */
> +#define CFG2_SRTO_16	0x0003	/* SRTO == 11: 16 ms */
> +
> +/* Symbol error counter register 2 */
> +#define SERRCNT_SEC	0xffff	/* The symbol error counter */
> +
> +/* Interrupt status register */
> +#define INTST_PWON	0x8000	/* power-on detected */
> +#define INTST_WAKEUP	0x4000	/* local or remote wake-up detected */
> +#define INTST_WUR	0x2000	/* dedicated wake-up request detected */
> +#define INTST_LPS	0x1000	/* LPS code groups received */
> +#define INTST_PIF	0x0800	/* PHY initialization error detected */
> +#define INTST_LINK_FAIL	0x0400	/* link status changed to ‘link fail’ */
> +#define INTST_LINK_UP	0x0200	/* link status changed to ‘link up’ */
> +#define INTST_SYM_ERR	0x0100	/* symbol error detected */
> +#define INTST_TF	0x0080	/* training phase failure detected */
> +#define INTST_SNRW	0x0040	/* SNR value above warning limit */
> +#define INTST_CTRL_ERR	0x0020	/* SMI control error detected */
> +#define INTST_TXENC	0x0010	/* TXEN clamping detected */
> +#define INTST_UV_ERR	0x0008	/* undervoltage detected */
> +#define INTST_UVR	0x0004	/* undervoltage recovery detected */
> +#define INTST_TEMP_ERR	0x0002	/* overtemperature error detected */
> +#define INTST_SA	0x0001	/* transition to Normal on timer expiring */
> +
> +/* Interrupt enable register */
> +#define INTEN_PWON	0x8000	/* PWON interrupt enable */
> +#define INTEN_WAKEUP	0x4000	/* WAKEUP interrupt enable */
> +#define INTEN_WUR	0x2000	/* WUR_RECEIVED interrupt enable */
> +#define INTEN_LPS	0x1000	/* LPS_RECEIVED interrupt enable */
> +#define INTEN_PIF	0x0800	/* PHY_INIT_FAIL interrupt enable */
> +#define INTEN_LINK_FAIL	0x0400	/* LINK_STATUS_FAIL interrupt enable */
> +#define INTEN_LINK_UP	0x0200	/* LINK_STATUS_UP interrupt enable */
> +#define INTEN_SYM_ERR	0x0100	/* SYM_ERR interrupt enable */
> +#define INTEN_TF	0x0080	/* TRAINING_FAILED interrupt enable */
> +#define INTEN_SNRW	0x0040	/* SNR_WARNING interrupt enable */
> +#define INTEN_CTRL_ERR	0x0020	/* CONTROL_ERR interrupt enable */
> +#define INTEN_TXENC	0x0010	/* TXEN_CLAMPED interrupt enable */
> +#define INTEN_UV_ERR	0x0008	/* UV_ERR interrupt enable */
> +#define INTEN_UVR	0x0004	/* UV_RECOVERY interrupt enable */
> +#define INTEN_TEMP_ERR	0x0002	/* TEMP_ERR interrupt enable */
> +#define INTEN_SA	0x0001	/* SLEEP_ABORT interrupt enable */
> +
> +/* Communication status register */
> +#define COMST_LINK_UP	0x8000	/* link OK */
> +#define COMST_TXM	0x6000	/* transmitter mode */
> +#define COMST_TXM_DIS	0x0000	/* TXM == 00: transmitter disabled */
> +#define COMST_TXM_DIS	0x0000	/* TXM == 01: transmitter in SEND_N mode */
> +#define COMST_TXM_DIS	0x0000	/* TXM == 10: transmitter in SEND_I mode */
> +#define COMST_TXM_DIS	0x0000	/* TXM == 11: transmitter in SEND_Z mode */
> +#define COMST_LR	0x1000	/* local receiver OK */
> +#define COMST_RR	0x0800	/* remote receiver OK */
> +#define COMST_SCRL	0x0400	/* descrambler locked */
> +#define COMST_SSD_ERR	0x0200	/* SSD error detected */
> +#define COMST_ESD_ERR	0x0100	/* ESD error detected */
> +#define COMST_SNR	0x00e0	/* SNR link status */
> +#define COMST_RX_ERR	0x0010	/* receive error detected since last read */
> +#define COMST_TX_ERR	0x0080	/* transmit error detected since last read */
> +#define COMST_PS	0x0007	/* PHY state */
> +
> +/* General status register */
> +#define GST_INTP	0x8000	/* unmasked interrupt pending */
> +#define GST_PLL_LOCKED	0x4000	/* PLL stable and locked */
> +#define GST_LWU		0x2000	/* local wake-up detected */
> +#define GST_RWU		0x1000	/* remote wake-up detected */
> +#define GST_DDWU	0x0800	/* data detected at MDI in Sleep Request mode */
> +#define GST_EN		0x0400	/* EN switched LOW since last read */
> +#define GST_RST		0x0200	/* hardware reset detected since last read */
> +#define GST_LF_CNT	0x00f8	/* number of link fails since last read */
> +
> +/* External status register */
> +#define EXTST_UVDDA_3V3	0x4000	/* undervoltage detected on pin VDDA(3V3) */
> +#define EXTST_UVDDD_1V8	0x2000	/* undervoltage detected on pin VDDD(1V8) */
> +#define EXTST_UVDDA_1V8	0x1000	/* undervoltage detected on pin VDDA(1V8) */
> +#define EXTST_UVDDIO	0x0800	/* undervoltage detected on pin VDD(IO) */
> +#define EXTST_TH	0x0400	/* temperature above high level */
> +#define EXTST_TW	0x0200	/* temperature above warning level */
> +#define EXTST_SD	0x0100	/* short circuit detected since last read */
> +#define EXTST_OD	0x0080	/* open circuit detected since last read */
> +#define EXTST_INTDET	0x0040	/* interleave order detection */
> +
> +/* Link fail counter register */
> +#define LFCNT_LRC	0xff00	/* incremented when local receiver is NOT_OK */
> +#define LFCNT_RRC	0x00ff	/* incremented when remote receiver is NOT_OK */

Hi Kirill

You have a lot of #define here which you don't use. If you intend to
send more patches which make use of them, that is find. But if this is
going to be the only patch, please remove those which are not needed.

> +
> +static int tja1100_phy_config_init(struct phy_device *phydev)
> +{
> +	u32 features;
> +
> +	/* TJA1100 has only 100BASE-BroadR-REACH ability specified at
> +	 * MII_ESTATUS register. Standard modes are not supported. Therefore
> +	 * BroadR-REACH allow only 100Mbps full duplex without autoneg.
> +	 */
> +	features = SUPPORTED_MII;
> +	features |= SUPPORTED_100baseT_Full;
> +
> +	phydev->supported &= features;
> +	phydev->advertising &= features;

You should not need to play with these. They should come from
.features you set in the driver configuration below.

> +	phydev->autoneg = AUTONEG_DISABLE;
> +	phydev->speed = SPEED_100;
> +	phydev->duplex = DUPLEX_FULL;
> +
> +	return 0;
> +}
> +
> +static int tja1100_phy_config_aneg(struct phy_device *phydev)
> +{
> +	if (phydev->autoneg == AUTONEG_ENABLE) {
> +		pr_err("TJA1100: autonegotiation is not supported\n");
> +		return -1;
> +	}

Please use proper error code.

Also dev_err().

> +
> +	if (phydev->speed != SPEED_100 || phydev->duplex != DUPLEX_FULL) {
> +		pr_err("TJA1100: only 100MBps Full Duplex allowed\n");

Same here.

> +		return -2;
> +	}
> +
> +	return 0;
> +}
> +
> +static struct phy_driver tja1100_phy_driver[] = {
> +	{
> +		.phy_id = 0x0180dc48,
> +		.phy_id_mask = 0xfffffff0,
> +		.name = "NXP TJA1100",
> +
> +		.features = SUPPORTED_100baseT_Full | SUPPORTED_MII,
> +
> +		.config_aneg = tja1100_phy_config_aneg,
> +		.read_status = genphy_read_status,
> +		.config_init = tja1100_phy_config_init,
> +		.soft_reset = genphy_soft_reset,

There is no need to specify read_status and soft_reset. They will
default to the genphy if not specified.

	Andrew

^ permalink raw reply

* Re: [PATCH net v2] net: bridge: Fix locking in br_fdb_find_port()
From: Nikolay Aleksandrov @ 2018-06-08 13:39 UTC (permalink / raw)
  To: Petr Machata, bridge, netdev; +Cc: stephen, davem
In-Reply-To: <38d89430-32c4-8842-efd4-88e7d3912506@cumulusnetworks.com>

On 08/06/18 16:35, Nikolay Aleksandrov wrote:
> On 08/06/18 16:11, Petr Machata wrote:
>> Callers of br_fdb_find() need to hold the hash lock, which
>> br_fdb_find_port() doesn't do. However, since br_fdb_find_port() is not
>> doing any actual FDB manipulation, the hash lock is not really needed at
>> all. So convert to br_fdb_find_rcu(), surrounded by rcu_read_lock() /
>> _unlock() pair.
>>
>> The device pointer copied from inside the FDB entry is then kept alive
>> by the RTNL lock, which br_fdb_find_port() asserts.
>>
>> Fixes: 4d4fd36126d6 ("net: bridge: Publish bridge accessor functions")
>> Signed-off-by: Petr Machata <petrm@mellanox.com>
>> ---
>>
>> Notes:
>>     Changes from v1 to v2:
>>     
>>     - Instead of taking hash lock, take RCU lock and call br_fdb_find_rcu().
>>
>>  net/bridge/br_fdb.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
>> index b19e310..502f663 100644
>> --- a/net/bridge/br_fdb.c
>> +++ b/net/bridge/br_fdb.c
>> @@ -135,9 +135,11 @@ struct net_device *br_fdb_find_port(const struct net_device *br_dev,
>>  		return NULL;
>>  
>>  	br = netdev_priv(br_dev);
>> -	f = br_fdb_find(br, addr, vid);
>> +	rcu_read_lock();
>> +	f = br_fdb_find_rcu(br, addr, vid);
>>  	if (f && f->dst)
>>  		dev = f->dst->dev;
>> +	rcu_read_unlock();
>>  
>>  	return dev;
>>  }
>>
> 
> Important note: the only reason this will not dereference a NULL pointer
> when getting f->dst is because RTNL is held in all of its current
> callers. I missed the comments on the previous version, but using RCU
> here is dangerous if someone decides to use this without rtnl they will
> get a false sense of security, that is why I acked the previous version.
> I'd suggest to use READ_ONCE() for f->dst to avoid reading it again.
> 

Nevermind the READ_ONCE part, I missed that there's ASSERT_RTNL() in the
beginning of this function, so it'll always be used with RTNL. :-)
It's good as it stands, I need to get some coffee.

Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>

^ permalink raw reply

* Re: BUG: unable to handle kernel NULL pointer dereference in corrupted
From: Dmitry Vyukov @ 2018-06-08 13:39 UTC (permalink / raw)
  To: syzbot, ubraun, linux-s390; +Cc: David Miller, LKML, netdev, syzkaller-bugs
In-Reply-To: <000000000000b98577056e212120@google.com>

On Fri, Jun 8, 2018 at 3:11 PM, syzbot
<syzbot+f5066e369b2d5fff630f@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:    68abbe729567 Merge branch 'akpm' (patches from Andrew)
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=16f7cebf800000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=e5a4673d4582131c
> dashboard link: https://syzkaller.appspot.com/bug?extid=f5066e369b2d5fff630f
> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1191756f800000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=162236af800000

The reproducer suggests that this is in smc.
+smc maintainers

> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+f5066e369b2d5fff630f@syzkaller.appspotmail.com
>
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> PGD 1b51e5067 P4D 1b51e5067 PUD 1b508f067 PMD 0
> Oops: 0010 [#1] SMP KASAN
> CPU: 1 PID: 4485 Comm: syz-executor452 Not tainted 4.17.0+ #90
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:          (null)
> Code: Bad RIP value.
> RSP: 0018:ffff8801b6f273a0 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff8801b629b800 RCX: 1ffffffff10ea805
> RDX: ffff8801b6f27c00 RSI: ffff8801ae67a100 RDI: ffff8801b51feac0
> RBP: ffff8801b6f27510 R08: ffff8801b563cf78 R09: 0000000000000006
> R10: ffff8801b563c740 R11: 0000000000000000 R12: 1ffff10036de4e79
> R13: ffff8801b6f27c00 R14: ffff8801b629b812 R15: ffff8801b629bc58
> FS:  0000000001c2b880(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffffffffffffffd6 CR3: 00000001b5625000 CR4: 00000000001406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  sock_poll+0x1d1/0x710 net/socket.c:1156
>  vfs_poll+0x77/0x2a0 fs/select.c:40
>  ep_item_poll.isra.15+0x2c1/0x390 fs/eventpoll.c:887
>  ep_insert+0x6b8/0x1c00 fs/eventpoll.c:1459
>  __do_sys_epoll_ctl fs/eventpoll.c:2113 [inline]
>  __se_sys_epoll_ctl fs/eventpoll.c:1999 [inline]
>  __x64_sys_epoll_ctl+0xef1/0x10f0 fs/eventpoll.c:1999
>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x43fcc9
> Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff
> 0f 83 6b 45 00 00 c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fff59e3a2f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000e9
> RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fcc9
> RDX: 0000000000000003 RSI: 0000000000000001 RDI: 0000000000000004
> RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
> R10: 0000000020000000 R11: 0000000000000217 R12: 00000000004015f0
> R13: 0000000000401680 R14: 0000000000000000 R15: 0000000000000000
> Modules linked in:
> Dumping ftrace buffer:
>    (ftrace buffer empty)
> CR2: 0000000000000000
> ---[ end trace 090a30b2125a99a3 ]---
> RIP: 0010:          (null)
> Code: Bad RIP value.
> RSP: 0018:ffff8801b6f273a0 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff8801b629b800 RCX: 1ffffffff10ea805
> RDX: ffff8801b6f27c00 RSI: ffff8801ae67a100 RDI: ffff8801b51feac0
> RBP: ffff8801b6f27510 R08: ffff8801b563cf78 R09: 0000000000000006
> R10: ffff8801b563c740 R11: 0000000000000000 R12: 1ffff10036de4e79
> R13: ffff8801b6f27c00 R14: ffff8801b629b812 R15: ffff8801b629bc58
> FS:  0000000001c2b880(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffffffffffffffd6 CR3: 00000001b5625000 CR4: 00000000001406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/000000000000b98577056e212120%40google.com.
> For more options, visit https://groups.google.com/d/optout.

^ permalink raw reply

* Re: general protection fault in pipe_write
From: Dmitry Vyukov @ 2018-06-08 13:36 UTC (permalink / raw)
  To: syzbot, Alexei Starovoitov, Daniel Borkmann, netdev
  Cc: linux-fsdevel, LKML, syzkaller-bugs, Al Viro
In-Reply-To: <000000000000c109af056e2121a4@google.com>

On Fri, Jun 8, 2018 at 3:11 PM, syzbot
<syzbot+772c951c5f15d2f1df03@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:    7170e6045a6a strparser: Add __strp_unpause and use it in k..
> git tree:       net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=15b5c8cf800000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=a601a80fec461d44
> dashboard link: https://syzkaller.appspot.com/bug?extid=772c951c5f15d2f1df03
> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13ad0b6f800000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+772c951c5f15d2f1df03@syzkaller.appspotmail.com

This seems to be same as the splash of other crashes in bpfilter:

#syz fix: bpfilter: fix race in pipe access


> 8021q: adding VLAN 0 to HW filter on device team0
> 8021q: adding VLAN 0 to HW filter on device team0
> bpfilter: read fail -512
> kasan: CONFIG_KASAN_INLINE enabled
> kasan: GPF could be caused by NULL-ptr deref or user memory access
> general protection fault: 0000 [#1] SMP KASAN
> Dumping ftrace buffer:
>    (ftrace buffer empty)
> Modules linked in:
> CPU: 1 PID: 6572 Comm: syz-executor5 Not tainted 4.17.0-rc7+ #82
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:pipe_write+0xa49/0xeb0 fs/pipe.c:480
> RSP: 0000:ffff8801ac6b7858 EFLAGS: 00010206
> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff81c22b3b
> RDX: 0000000000000005 RSI: ffffffff81c22b49 RDI: 0000000000000028
> RBP: ffff8801ac6b78d8 R08: ffff8801b3796080 R09: 0000000000000006
> R10: ffff8801b3796080 R11: 0000000000000000 R12: ffff8801cdbaa820
> R13: ffff8801cdb31a40 R14: 0000000000000000 R15: dffffc0000000000
> FS:  00007fe12b0e9700(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fe01b0f9af0 CR3: 00000001c43e7000 CR4: 00000000001406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  call_write_iter include/linux/fs.h:1784 [inline]
>  new_sync_write fs/read_write.c:474 [inline]
>  __vfs_write+0x64d/0x960 fs/read_write.c:487
>  __kernel_write+0x10c/0x380 fs/read_write.c:506
>  __bpfilter_process_sockopt+0x1d8/0x35b net/bpfilter/bpfilter_kern.c:66
>  bpfilter_mbox_request+0x4d/0xb0 net/ipv4/bpfilter/sockopt.c:25
>  bpfilter_ip_set_sockopt+0x33/0x40 net/ipv4/bpfilter/sockopt.c:31
>  ip_setsockopt+0x124/0x140 net/ipv4/ip_sockglue.c:1250
>  raw_setsockopt+0xe2/0x100 net/ipv4/raw.c:868
>  sock_common_setsockopt+0x9a/0xe0 net/core/sock.c:3059
>  __sys_setsockopt+0x1bd/0x390 net/socket.c:1903
>  __do_sys_setsockopt net/socket.c:1914 [inline]
>  __se_sys_setsockopt net/socket.c:1911 [inline]
>  __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1911
>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x4559f9
> RSP: 002b:00007fe12b0e8c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
> RAX: ffffffffffffffda RBX: 00007fe12b0e96d4 RCX: 00000000004559f9
> RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000004
> RBP: 000000000072bf50 R08: 0000000000000370 R09: 0000000000000000
> R10: 00000000200003c0 R11: 0000000000000246 R12: 00000000ffffffff
> R13: 00000000004c0d8b R14: 00000000004d0828 R15: 0000000000000001
> Code: 48 c1 ea 03 80 3c 02 00 0f 85 fc 03 00 00 48 8b 45 c8 48 8b 58 20 48
> b8 00 00 00 00 00 fc ff df 48 8d 7b 28 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
> 85 ef 03 00 00 48 8b 7b 28 31 d2 be 01 00 00 00
> RIP: pipe_write+0xa49/0xeb0 fs/pipe.c:480 RSP: ffff8801ac6b7858
> ---[ end trace 7e44f4b8135e2e72 ]---
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/000000000000c109af056e2121a4%40google.com.
> For more options, visit https://groups.google.com/d/optout.

^ permalink raw reply

* Re: [PATCH net v2] net: bridge: Fix locking in br_fdb_find_port()
From: Nikolay Aleksandrov @ 2018-06-08 13:35 UTC (permalink / raw)
  To: Petr Machata, bridge, netdev; +Cc: stephen, davem
In-Reply-To: <c41fffa00abb9a123039e5509886a0de85274291.1528450455.git.petrm@mellanox.com>

On 08/06/18 16:11, Petr Machata wrote:
> Callers of br_fdb_find() need to hold the hash lock, which
> br_fdb_find_port() doesn't do. However, since br_fdb_find_port() is not
> doing any actual FDB manipulation, the hash lock is not really needed at
> all. So convert to br_fdb_find_rcu(), surrounded by rcu_read_lock() /
> _unlock() pair.
> 
> The device pointer copied from inside the FDB entry is then kept alive
> by the RTNL lock, which br_fdb_find_port() asserts.
> 
> Fixes: 4d4fd36126d6 ("net: bridge: Publish bridge accessor functions")
> Signed-off-by: Petr Machata <petrm@mellanox.com>
> ---
> 
> Notes:
>     Changes from v1 to v2:
>     
>     - Instead of taking hash lock, take RCU lock and call br_fdb_find_rcu().
> 
>  net/bridge/br_fdb.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
> index b19e310..502f663 100644
> --- a/net/bridge/br_fdb.c
> +++ b/net/bridge/br_fdb.c
> @@ -135,9 +135,11 @@ struct net_device *br_fdb_find_port(const struct net_device *br_dev,
>  		return NULL;
>  
>  	br = netdev_priv(br_dev);
> -	f = br_fdb_find(br, addr, vid);
> +	rcu_read_lock();
> +	f = br_fdb_find_rcu(br, addr, vid);
>  	if (f && f->dst)
>  		dev = f->dst->dev;
> +	rcu_read_unlock();
>  
>  	return dev;
>  }
> 

Important note: the only reason this will not dereference a NULL pointer
when getting f->dst is because RTNL is held in all of its current
callers. I missed the comments on the previous version, but using RCU
here is dangerous if someone decides to use this without rtnl they will
get a false sense of security, that is why I acked the previous version.
I'd suggest to use READ_ONCE() for f->dst to avoid reading it again.

The way to reach a null dst is with fdbs pointing to the bridge which
currently can only be installed via user-space with RTNL held.

^ permalink raw reply

* Re: WARNING in do_dentry_open
From: Dmitry Vyukov @ 2018-06-08 13:34 UTC (permalink / raw)
  To: syzbot, Alexei Starovoitov, Daniel Borkmann, netdev
  Cc: linux-fsdevel, LKML, syzkaller-bugs, Al Viro
In-Reply-To: <000000000000bd54dd056e212189@google.com>

On Fri, Jun 8, 2018 at 3:11 PM, syzbot
<syzbot+2e7fcab0f56fdbb330b8@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:    68abbe729567 Merge branch 'akpm' (patches from Andrew)
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=130146af800000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=e5a4673d4582131c
> dashboard link: https://syzkaller.appspot.com/bug?extid=2e7fcab0f56fdbb330b8
> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1591756f800000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=152236af800000

Looking at the reproducer this seems to be related to bpf.
+bpf maintainers

> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+2e7fcab0f56fdbb330b8@syzkaller.appspotmail.com
>
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> WARNING: CPU: 1 PID: 4508 at fs/open.c:778 do_dentry_open+0x4ad/0xe40
> fs/open.c:778
> Kernel panic - not syncing: panic_on_warn set ...
>
> CPU: 1 PID: 4508 Comm: syz-executor867 Not tainted 4.17.0+ #90
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x1b9/0x294 lib/dump_stack.c:113
>  panic+0x22f/0x4de kernel/panic.c:184
>  __warn.cold.8+0x163/0x1b3 kernel/panic.c:536
>  report_bug+0x252/0x2d0 lib/bug.c:186
>  fixup_bug arch/x86/kernel/traps.c:178 [inline]
>  do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296
>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316
>  invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:992
> RIP: 0010:do_dentry_open+0x4ad/0xe40 fs/open.c:778
> Code: 7b 28 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00
> 0f 85 15 08 00 00 48 c7 43 28 00 00 00 00 e8 f3 6d ba ff <0f> 0b e8 ec 6d ba
> ff 48 8d 43 18 41 be ed ff ff ff 48 89 45 c0 e9
> RSP: 0018:ffff8801afcaf7c8 EFLAGS: 00010293
> RAX: ffff8801afe08400 RBX: ffff8801b099e0c0 RCX: ffffffff81bfccf6
> RDX: 0000000000000000 RSI: ffffffff81bfcf6d RDI: ffff8801b099e0e8
> RBP: ffff8801afcaf840 R08: ffff8801afe08400 R09: ffffed0036aa2afc
> R10: ffffed0036aa2afc R11: ffff8801b55157e3 R12: ffff8801ab28d4b0
> R13: ffff8801ab28d6a8 R14: 0000000000000000 R15: ffff8801b099e13c
>  vfs_open+0x139/0x230 fs/open.c:908
>  do_last fs/namei.c:3370 [inline]
>  path_openat+0x1717/0x4dc0 fs/namei.c:3511
>  do_filp_open+0x249/0x350 fs/namei.c:3545
>  do_sys_open+0x56f/0x740 fs/open.c:1101
>  __do_sys_openat fs/open.c:1128 [inline]
>  __se_sys_openat fs/open.c:1122 [inline]
>  __x64_sys_openat+0x9d/0x100 fs/open.c:1122
>  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x43ff09
> Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff
> 0f 83 6b 45 00 00 c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007ffe4eafe4f8 EFLAGS: 00000217 ORIG_RAX: 0000000000000101
> RAX: ffffffffffffffda RBX: 2f30656c69662f2e RCX: 000000000043ff09
> RDX: 0000000000000040 RSI: 0000000020000100 RDI: ffffffffffffff9c
> RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
> R10: 0000000000000004 R11: 0000000000000217 R12: 0000000000401830
> R13: 00000000004018c0 R14: 0000000000000000 R15: 0000000000000000
> Dumping ftrace buffer:
>    (ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/000000000000bd54dd056e212189%40google.com.
> For more options, visit https://groups.google.com/d/optout.

^ permalink raw reply

* [PATCH net v2] net: bridge: Fix locking in br_fdb_find_port()
From: Petr Machata @ 2018-06-08 13:11 UTC (permalink / raw)
  To: bridge, netdev; +Cc: stephen, davem, stephen

Callers of br_fdb_find() need to hold the hash lock, which
br_fdb_find_port() doesn't do. However, since br_fdb_find_port() is not
doing any actual FDB manipulation, the hash lock is not really needed at
all. So convert to br_fdb_find_rcu(), surrounded by rcu_read_lock() /
_unlock() pair.

The device pointer copied from inside the FDB entry is then kept alive
by the RTNL lock, which br_fdb_find_port() asserts.

Fixes: 4d4fd36126d6 ("net: bridge: Publish bridge accessor functions")
Signed-off-by: Petr Machata <petrm@mellanox.com>
---

Notes:
    Changes from v1 to v2:
    
    - Instead of taking hash lock, take RCU lock and call br_fdb_find_rcu().

 net/bridge/br_fdb.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index b19e310..502f663 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -135,9 +135,11 @@ struct net_device *br_fdb_find_port(const struct net_device *br_dev,
 		return NULL;
 
 	br = netdev_priv(br_dev);
-	f = br_fdb_find(br, addr, vid);
+	rcu_read_lock();
+	f = br_fdb_find_rcu(br, addr, vid);
 	if (f && f->dst)
 		dev = f->dst->dev;
+	rcu_read_unlock();
 
 	return dev;
 }
-- 
2.4.11

^ permalink raw reply related

* kernel BUG at include/linux/mm.h:LINE! (2)
From: syzbot @ 2018-06-08 13:11 UTC (permalink / raw)
  To: davem, edumazet, kuznet, linux-kernel, netdev, syzkaller-bugs,
	yoshfuji

Hello,

syzbot found the following crash on:

HEAD commit:    7170e6045a6a strparser: Add __strp_unpause and use it in k..
git tree:       net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=114236af800000
kernel config:  https://syzkaller.appspot.com/x/.config?x=a601a80fec461d44
dashboard link: https://syzkaller.appspot.com/bug?extid=3225ce21c0e9929bb9cf
compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=10f44fdf800000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=110f636f800000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3225ce21c0e9929bb9cf@syzkaller.appspotmail.com

flags: 0x2fffc0000000000()
raw: 02fffc0000000000 0000000000000000 0000000000000000 00000000ffffff80
raw: ffffea0006b29220 ffff88021fffac18 0000000000000003 0000000000000000
page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) <= 0)
------------[ cut here ]------------
kernel BUG at include/linux/mm.h:853!
invalid opcode: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
    (ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 4545 Comm: syz-executor492 Not tainted 4.17.0-rc7+ #82
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
RIP: 0010:get_page include/linux/mm.h:853 [inline]
RIP: 0010:do_tcp_sendpages+0x1879/0x1e60 net/ipv4/tcp.c:1002
RSP: 0018:ffff8801c2a06f88 EFLAGS: 00010203
RAX: 0000000000000000 RBX: ffff8801d972d580 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff81a66c25 RDI: ffffed0038540de0
RBP: ffff8801c2a071e8 R08: ffff8801b11d2480 R09: 0000000000000006
R10: ffff8801b11d2480 R11: 0000000000000000 R12: 000000000000301d
R13: ffffea0006b2621c R14: ffff8801ae5a6040 R15: dffffc0000000000
FS:  0000000000000000(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020008000 CR3: 0000000008c6a000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
  tls_push_sg+0x25b/0x860 net/tls/tls_main.c:126
  tls_push_record+0xae5/0x13e0 net/tls/tls_sw.c:266
  tls_sw_push_pending_record+0x22/0x30 net/tls/tls_sw.c:276
  tls_handle_open_record net/tls/tls_main.c:164 [inline]
  tls_sk_proto_close+0x734/0xad0 net/tls/tls_main.c:264
  inet_release+0x104/0x1f0 net/ipv4/af_inet.c:427
  inet6_release+0x50/0x70 net/ipv6/af_inet6.c:459
  sock_release+0x96/0x1b0 net/socket.c:594
  sock_close+0x16/0x20 net/socket.c:1149
  __fput+0x34d/0x890 fs/file_table.c:209
  ____fput+0x15/0x20 fs/file_table.c:243
  task_work_run+0x1e4/0x290 kernel/task_work.c:113
  exit_task_work include/linux/task_work.h:22 [inline]
  do_exit+0x1aee/0x2730 kernel/exit.c:865
  do_group_exit+0x16f/0x430 kernel/exit.c:968
  __do_sys_exit_group kernel/exit.c:979 [inline]
  __se_sys_exit_group kernel/exit.c:977 [inline]
  __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:977
  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x43f368
RSP: 002b:00007ffd03500578 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000043f368
RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000
RBP: 00000000004bf448 R08: 00000000000000e7 R09: ffffffffffffffd0
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
R13: 00000000006d1180 R14: 0000000000000000 R15: 0000000000000000
Code: ff ff 41 89 86 cc 08 00 00 e8 e4 07 05 00 e9 2c eb ff ff e8 ca 4b 27  
fb 48 8b bd b8 fd ff ff 48 c7 c6 40 0c 54 88 e8 77 72 54 fb <0f> 0b 48 89  
85 b8 fd ff ff e8 a9 4b 27 fb 48 8b 85 b8 fd ff ff
RIP: get_page include/linux/mm.h:853 [inline] RSP: ffff8801c2a06f88
RIP: do_tcp_sendpages+0x1879/0x1e60 net/ipv4/tcp.c:1002 RSP:  
ffff8801c2a06f88
---[ end trace 500a6e4fab99629c ]---


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

^ permalink raw reply

* BUG: unable to handle kernel NULL pointer dereference in corrupted
From: syzbot @ 2018-06-08 13:11 UTC (permalink / raw)
  To: davem, linux-kernel, netdev, syzkaller-bugs

Hello,

syzbot found the following crash on:

HEAD commit:    68abbe729567 Merge branch 'akpm' (patches from Andrew)
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16f7cebf800000
kernel config:  https://syzkaller.appspot.com/x/.config?x=e5a4673d4582131c
dashboard link: https://syzkaller.appspot.com/bug?extid=f5066e369b2d5fff630f
compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1191756f800000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=162236af800000

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+f5066e369b2d5fff630f@syzkaller.appspotmail.com

random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
PGD 1b51e5067 P4D 1b51e5067 PUD 1b508f067 PMD 0
Oops: 0010 [#1] SMP KASAN
CPU: 1 PID: 4485 Comm: syz-executor452 Not tainted 4.17.0+ #90
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
RIP: 0010:          (null)
Code: Bad RIP value.
RSP: 0018:ffff8801b6f273a0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8801b629b800 RCX: 1ffffffff10ea805
RDX: ffff8801b6f27c00 RSI: ffff8801ae67a100 RDI: ffff8801b51feac0
RBP: ffff8801b6f27510 R08: ffff8801b563cf78 R09: 0000000000000006
R10: ffff8801b563c740 R11: 0000000000000000 R12: 1ffff10036de4e79
R13: ffff8801b6f27c00 R14: ffff8801b629b812 R15: ffff8801b629bc58
FS:  0000000001c2b880(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 00000001b5625000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
  sock_poll+0x1d1/0x710 net/socket.c:1156
  vfs_poll+0x77/0x2a0 fs/select.c:40
  ep_item_poll.isra.15+0x2c1/0x390 fs/eventpoll.c:887
  ep_insert+0x6b8/0x1c00 fs/eventpoll.c:1459
  __do_sys_epoll_ctl fs/eventpoll.c:2113 [inline]
  __se_sys_epoll_ctl fs/eventpoll.c:1999 [inline]
  __x64_sys_epoll_ctl+0xef1/0x10f0 fs/eventpoll.c:1999
  do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x43fcc9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 6b 45 00 00 c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fff59e3a2f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000e9
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 000000000043fcc9
RDX: 0000000000000003 RSI: 0000000000000001 RDI: 0000000000000004
RBP: 00000000006ca018 R08: 00000000004002c8 R09: 00000000004002c8
R10: 0000000020000000 R11: 0000000000000217 R12: 00000000004015f0
R13: 0000000000401680 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
Dumping ftrace buffer:
    (ftrace buffer empty)
CR2: 0000000000000000
---[ end trace 090a30b2125a99a3 ]---
RIP: 0010:          (null)
Code: Bad RIP value.
RSP: 0018:ffff8801b6f273a0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8801b629b800 RCX: 1ffffffff10ea805
RDX: ffff8801b6f27c00 RSI: ffff8801ae67a100 RDI: ffff8801b51feac0
RBP: ffff8801b6f27510 R08: ffff8801b563cf78 R09: 0000000000000006
R10: ffff8801b563c740 R11: 0000000000000000 R12: 1ffff10036de4e79
R13: ffff8801b6f27c00 R14: ffff8801b629b812 R15: ffff8801b629bc58
FS:  0000000001c2b880(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffffffffd6 CR3: 00000001b5625000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with  
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

^ permalink raw reply

* [PATCH 2/2] iproute2: Remove leftover gated RT_PROT defines
From: Donald Sharp @ 2018-06-08 12:46 UTC (permalink / raw)
  To: netdev, stephen, dsahern

These values are not being used nor maintained, so remove.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
---
 etc/iproute2/rt_protos | 13 -------------
 1 file changed, 13 deletions(-)

diff --git a/etc/iproute2/rt_protos b/etc/iproute2/rt_protos
index 3ffe8a6c..a965ad16 100644
--- a/etc/iproute2/rt_protos
+++ b/etc/iproute2/rt_protos
@@ -21,16 +21,3 @@
 188     ospf
 189     rip
 192     eigrp
-
-#
-#	Used by me for gated
-#
-254	gated/aggr
-253	gated/bgp
-252	gated/ospf
-251	gated/ospfase
-250	gated/rip
-249	gated/static
-248	gated/conn
-247	gated/inet
-246	gated/default
-- 
2.14.4

^ permalink raw reply related

* [PATCH 1/2] iproute2: Add support for a few routing protocols
From: Donald Sharp @ 2018-06-08 12:46 UTC (permalink / raw)
  To: netdev, stephen, dsahern

Add support for:

BGP
ISIS
OSPF
RIP
EIGRP

Routing protocols to iproute2.

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
---
 etc/iproute2/rt_protos    | 5 +++++
 include/linux/rtnetlink.h | 5 +++++
 lib/rt_names.c            | 5 +++++
 3 files changed, 15 insertions(+)

diff --git a/etc/iproute2/rt_protos b/etc/iproute2/rt_protos
index 82cf9c46..3ffe8a6c 100644
--- a/etc/iproute2/rt_protos
+++ b/etc/iproute2/rt_protos
@@ -16,6 +16,11 @@
 15	ntk
 16      dhcp
 42	babel
+186     bgp
+187     isis
+188     ospf
+189     rip
+192     eigrp
 
 #
 #	Used by me for gated
diff --git a/include/linux/rtnetlink.h b/include/linux/rtnetlink.h
index 742ba078..2e83a267 100644
--- a/include/linux/rtnetlink.h
+++ b/include/linux/rtnetlink.h
@@ -248,6 +248,11 @@ enum {
 #define RTPROT_DHCP	16      /* DHCP client */
 #define RTPROT_MROUTED	17      /* Multicast daemon */
 #define RTPROT_BABEL	42      /* Babel daemon */
+#define RTPROT_BGP	186     /* BGP Routes */
+#define RTPROT_ISIS	187     /* ISIS Routes */
+#define RTPROT_OSPF	188     /* OSPF Routes */
+#define RTPROT_RIP	189     /* RIP Routes */
+#define RTPROT_EIGRP	192     /* EIGRP Routes */
 
 /* rtm_scope
 
diff --git a/lib/rt_names.c b/lib/rt_names.c
index 253389a6..d3562d2d 100644
--- a/lib/rt_names.c
+++ b/lib/rt_names.c
@@ -137,6 +137,11 @@ static char * rtnl_rtprot_tab[256] = {
 	[RTPROT_XORP] = "xorp",
 	[RTPROT_NTK] = "ntk",
 	[RTPROT_DHCP] = "dhcp",
+	[RTPROT_BGP] = "bgp",
+	[RTPROT_ISIS] = "isis",
+	[RTPROT_OSPF] = "ospf",
+	[RTPROT_RIP] = "rip",
+	[RTPROT_EIGRP] = "eigrp",
 };
 
 
-- 
2.14.4

^ permalink raw reply related

* [PATCH 0/2] Addition of new routing protocols for iproute2
From: Donald Sharp @ 2018-06-08 12:46 UTC (permalink / raw)
  To: netdev, stephen, dsahern

The linux kernel recently accepted some new RTPROT values for some
fairly standard routing protocols.  This commit brings in support
for iproute2 to handle these new values.

Additionally clean up some long standing cruft in etc/iproute2/rt_protos

Donald Sharp (2):
  iproute2: Add support for a few routing protocols
  iproute2: Remove leftover gated RT_PROT defines

 etc/iproute2/rt_protos    | 18 +++++-------------
 include/linux/rtnetlink.h |  5 +++++
 lib/rt_names.c            |  5 +++++
 3 files changed, 15 insertions(+), 13 deletions(-)

-- 
2.14.4

^ permalink raw reply

* Re: [PATCH] netfilter: remove include/net/netfilter/nft_dup.h
From: Pablo Neira Ayuso @ 2018-06-08 10:42 UTC (permalink / raw)
  To: Corentin Labbe
  Cc: davem, fw, kadlec, coreteam, linux-kernel, netdev,
	netfilter-devel
In-Reply-To: <1528400289-28004-1-git-send-email-clabbe@baylibre.com>

On Thu, Jun 07, 2018 at 07:38:09PM +0000, Corentin Labbe wrote:
> include/net/netfilter/nft_dup.h was introduced in d877f07112f1 ("netfilter: nf_tables: add nft_dup expression")
> but was never user since this date.
> 
> Furthermore, the only struct in this file is unused elsewhere.

Applied.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox