* [PATCH 1/1] net: wireless: intersil: fix improper return value
From: Pan Bian @ 2016-12-03 10:22 UTC (permalink / raw)
To: Kalle Valo, linux-wireless, netdev; +Cc: linux-kernel, Pan Bian
Function orinoco_ioctl_commit() returns 0 (indicates success) when the
call to orinoco_lock() fails. Thus, the return value is inconsistent with
the execution status. It may be better to return "-EBUSY" when the call
to orinoco_lock() fails.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188671
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
drivers/net/wireless/intersil/orinoco/wext.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intersil/orinoco/wext.c b/drivers/net/wireless/intersil/orinoco/wext.c
index 1d4dae4..fee57ea 100644
--- a/drivers/net/wireless/intersil/orinoco/wext.c
+++ b/drivers/net/wireless/intersil/orinoco/wext.c
@@ -1314,7 +1314,7 @@ static int orinoco_ioctl_commit(struct net_device *dev,
return 0;
if (orinoco_lock(priv, &flags) != 0)
- return err;
+ return -EBUSY;
err = orinoco_commit(priv);
--
1.9.1
^ permalink raw reply related
* [PATCH 1/1] net: wireless: marvell: fix improper return value
From: Pan Bian @ 2016-12-03 10:27 UTC (permalink / raw)
To: Kalle Valo, Andreas Kemnade, Johannes Berg, libertas-dev,
linux-wireless, netdev
Cc: linux-kernel, Pan Bian
Function lbs_cmd_802_11_sleep_params() always return 0, even if the call
to lbs_cmd_with_response() fails. In this case, the parameter @sp will
keep uninitialized. Because the return value is 0, its caller (say
lbs_sleepparams_read()) will not detect the error, and will copy the
uninitialized stack memory to user sapce, resulting in stack information
leak. To avoid the bug, this patch returns variable ret (which takes
the return value of lbs_cmd_with_response()) instead of 0.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188451
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
drivers/net/wireless/marvell/libertas/cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/libertas/cmd.c b/drivers/net/wireless/marvell/libertas/cmd.c
index 301170c..033ff88 100644
--- a/drivers/net/wireless/marvell/libertas/cmd.c
+++ b/drivers/net/wireless/marvell/libertas/cmd.c
@@ -305,7 +305,7 @@ int lbs_cmd_802_11_sleep_params(struct lbs_private *priv, uint16_t cmd_action,
}
lbs_deb_leave_args(LBS_DEB_CMD, "ret %d", ret);
- return 0;
+ return ret;
}
static int lbs_wait_for_ds_awake(struct lbs_private *priv)
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 net-next 1/2] flow dissector: ICMP support
From: Jiri Pirko @ 2016-12-03 10:49 UTC (permalink / raw)
To: Simon Horman
Cc: David Miller, netdev, Jay Vosburgh, Veaceslav Falico,
Andy Gospodarek, Jamal Hadi Salim, Jiri Pirko
In-Reply-To: <1480710702-16850-2-git-send-email-simon.horman@netronome.com>
Fri, Dec 02, 2016 at 09:31:41PM CET, simon.horman@netronome.com wrote:
>Allow dissection of ICMP(V6) type and code. This re-uses transport layer
>port dissection code as although ICMP is not a transport protocol and their
>type and code are not ports this allows sharing of both code and storage.
>
>Signed-off-by: Simon Horman <simon.horman@netronome.com>
>---
> drivers/net/bonding/bond_main.c | 6 +++--
> include/linux/skbuff.h | 5 +++++
> include/net/flow_dissector.h | 50 ++++++++++++++++++++++++++++++++++++++---
> net/core/flow_dissector.c | 34 +++++++++++++++++++++++++---
> net/sched/cls_flow.c | 4 ++--
> 5 files changed, 89 insertions(+), 10 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 8029dd4912b6..a6f75cfb2bf7 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -3181,7 +3181,8 @@ static bool bond_flow_dissect(struct bonding *bond, struct sk_buff *skb,
> } else {
> return false;
> }
>- if (bond->params.xmit_policy == BOND_XMIT_POLICY_LAYER34 && proto >= 0)
>+ if (bond->params.xmit_policy == BOND_XMIT_POLICY_LAYER34 &&
>+ proto >= 0 && !skb_flow_is_icmp_any(skb, proto))
> fk->ports.ports = skb_flow_get_ports(skb, noff, proto);
>
> return true;
>@@ -3209,7 +3210,8 @@ u32 bond_xmit_hash(struct bonding *bond, struct sk_buff *skb)
> return bond_eth_hash(skb);
>
> if (bond->params.xmit_policy == BOND_XMIT_POLICY_LAYER23 ||
>- bond->params.xmit_policy == BOND_XMIT_POLICY_ENCAP23)
>+ bond->params.xmit_policy == BOND_XMIT_POLICY_ENCAP23 ||
>+ flow_keys_are_icmp_any(&flow))
> hash = bond_eth_hash(skb);
> else
> hash = (__force u32)flow.ports.ports;
>diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
>index 9c535fbccf2c..44a8f69a9198 100644
>--- a/include/linux/skbuff.h
>+++ b/include/linux/skbuff.h
>@@ -1094,6 +1094,11 @@ u32 __skb_get_poff(const struct sk_buff *skb, void *data,
> __be32 __skb_flow_get_ports(const struct sk_buff *skb, int thoff, u8 ip_proto,
> void *data, int hlen_proto);
>
>+static inline bool skb_flow_is_icmp_any(const struct sk_buff *skb, u8 ip_proto)
>+{
>+ return flow_protos_are_icmp_any(skb->protocol, ip_proto);
>+}
>+
> static inline __be32 skb_flow_get_ports(const struct sk_buff *skb,
> int thoff, u8 ip_proto)
> {
>diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h
>index c4f31666afd2..5540dfa18872 100644
>--- a/include/net/flow_dissector.h
>+++ b/include/net/flow_dissector.h
>@@ -2,6 +2,7 @@
> #define _NET_FLOW_DISSECTOR_H
>
> #include <linux/types.h>
>+#include <linux/in.h>
> #include <linux/in6.h>
> #include <uapi/linux/if_ether.h>
>
>@@ -89,10 +90,15 @@ struct flow_dissector_key_addrs {
> };
>
> /**
>- * flow_dissector_key_tp_ports:
>- * @ports: port numbers of Transport header
>+ * flow_dissector_key_ports:
>+ * @ports: port numbers of Transport header or
>+ * type and code of ICMP header
>+ * ports: source (high) and destination (low) port numbers
> * src: source port number
> * dst: destination port number
>+ * icmp: ICMP type (high) and code (low)
>+ * type: ICMP type
>+ * type: ICMP code
> */
> struct flow_dissector_key_ports {
> union {
>@@ -101,6 +107,11 @@ struct flow_dissector_key_ports {
> __be16 src;
> __be16 dst;
> };
>+ __be16 icmp;
>+ struct {
>+ u8 type;
>+ u8 code;
>+ };
Digging into this a bit more. I think it would be much nice not to mix
up l4 ports and icmp stuff.
How about to have FLOW_DISSECTOR_KEY_ICMP
and
struct flow_dissector_key_icmp {
u8 type;
u8 code;
};
The you can make this structure and struct flow_dissector_key_ports into
an union in struct flow_keys.
Looks much cleaner to me.
> };
> };
>
>@@ -188,9 +199,42 @@ struct flow_keys_digest {
> void make_flow_keys_digest(struct flow_keys_digest *digest,
> const struct flow_keys *flow);
>
>+static inline bool flow_protos_are_icmpv4(__be16 n_proto, u8 ip_proto)
>+{
>+ return n_proto == htons(ETH_P_IP) && ip_proto == IPPROTO_ICMP;
>+}
>+
>+static inline bool flow_protos_are_icmpv6(__be16 n_proto, u8 ip_proto)
>+{
>+ return n_proto == htons(ETH_P_IPV6) && ip_proto == IPPROTO_ICMPV6;
>+}
>+
>+static inline bool flow_protos_are_icmp_any(__be16 n_proto, u8 ip_proto)
>+{
>+ return flow_protos_are_icmpv4(n_proto, ip_proto) ||
>+ flow_protos_are_icmpv6(n_proto, ip_proto);
>+}
>+
>+static inline bool flow_basic_key_is_icmpv4(const struct flow_dissector_key_basic *basic)
>+{
>+ return flow_protos_are_icmpv4(basic->n_proto, basic->ip_proto);
>+}
>+
>+static inline bool flow_basic_key_is_icmpv6(const struct flow_dissector_key_basic *basic)
>+{
>+ return flow_protos_are_icmpv6(basic->n_proto, basic->ip_proto);
>+}
>+
>+static inline bool flow_keys_are_icmp_any(const struct flow_keys *keys)
>+{
>+ return flow_protos_are_icmp_any(keys->basic.n_proto,
>+ keys->basic.ip_proto);
>+}
>+
> static inline bool flow_keys_have_l4(const struct flow_keys *keys)
> {
>- return (keys->ports.ports || keys->tags.flow_label);
>+ return (!flow_keys_are_icmp_any(keys) && keys->ports.ports) ||
>+ keys->tags.flow_label;
> }
>
> u32 flow_hash_from_keys(struct flow_keys *keys);
>diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
>index 1eb6f949e5b2..0584b4bb4390 100644
>--- a/net/core/flow_dissector.c
>+++ b/net/core/flow_dissector.c
>@@ -58,6 +58,28 @@ void skb_flow_dissector_init(struct flow_dissector *flow_dissector,
> EXPORT_SYMBOL(skb_flow_dissector_init);
>
> /**
>+ * skb_flow_get_be16 - extract be16 entity
>+ * @skb: sk_buff to extract from
>+ * @poff: offset to extract at
>+ * @data: raw buffer pointer to the packet
>+ * @hlen: packet header length
>+ *
>+ * The function will try to retrieve a be32 entity at
>+ * offset poff
>+ */
>+__be16 skb_flow_get_be16(const struct sk_buff *skb, int poff, void *data,
>+ int hlen)
>+{
>+ __be16 *u, _u;
>+
>+ u = __skb_header_pointer(skb, poff, sizeof(_u), data, hlen, &_u);
>+ if (u)
>+ return *u;
>+
>+ return 0;
>+}
>+
>+/**
> * __skb_flow_get_ports - extract the upper layer ports and return them
> * @skb: sk_buff to extract the ports from
> * @thoff: transport header offset
>@@ -542,8 +564,13 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> key_ports = skb_flow_dissector_target(flow_dissector,
> FLOW_DISSECTOR_KEY_PORTS,
> target_container);
>- key_ports->ports = __skb_flow_get_ports(skb, nhoff, ip_proto,
>- data, hlen);
>+ if (flow_protos_are_icmp_any(proto, ip_proto))
>+ key_ports->icmp = skb_flow_get_be16(skb, nhoff, data,
>+ hlen);
>+ else
>+ key_ports->ports = __skb_flow_get_ports(skb, nhoff,
>+ ip_proto, data,
>+ hlen);
> }
>
> out_good:
>@@ -718,7 +745,8 @@ void make_flow_keys_digest(struct flow_keys_digest *digest,
>
> data->n_proto = flow->basic.n_proto;
> data->ip_proto = flow->basic.ip_proto;
>- data->ports = flow->ports.ports;
>+ if (flow_keys_have_l4(flow))
>+ data->ports = flow->ports.ports;
> data->src = flow->addrs.v4addrs.src;
> data->dst = flow->addrs.v4addrs.dst;
> }
>diff --git a/net/sched/cls_flow.c b/net/sched/cls_flow.c
>index e39672394c7b..a1a7ae71aa62 100644
>--- a/net/sched/cls_flow.c
>+++ b/net/sched/cls_flow.c
>@@ -96,7 +96,7 @@ static u32 flow_get_proto(const struct sk_buff *skb,
> static u32 flow_get_proto_src(const struct sk_buff *skb,
> const struct flow_keys *flow)
> {
>- if (flow->ports.ports)
>+ if (!flow_keys_are_icmp_any(flow) && flow->ports.ports)
> return ntohs(flow->ports.src);
>
> return addr_fold(skb->sk);
>@@ -105,7 +105,7 @@ static u32 flow_get_proto_src(const struct sk_buff *skb,
> static u32 flow_get_proto_dst(const struct sk_buff *skb,
> const struct flow_keys *flow)
> {
>- if (flow->ports.ports)
>+ if (!flow_keys_are_icmp_any(flow) && flow->ports.ports)
> return ntohs(flow->ports.dst);
>
> return addr_fold(skb_dst(skb)) ^ (__force u16) tc_skb_protocol(skb);
>--
>2.7.0.rc3.207.g0ac5344
>
^ permalink raw reply
* [PATCH 1/1] net: caif: fix ineffective error check
From: Pan Bian @ 2016-12-03 11:18 UTC (permalink / raw)
To: Dmitry Tarnyagin, David S. Miller, netdev; +Cc: linux-kernel, Pan Bian
In function caif_sktinit_module(), the check of the return value of
sock_register() seems ineffective. This patch fixes it.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188751
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
net/caif/caif_socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/caif/caif_socket.c b/net/caif/caif_socket.c
index aa209b1..2a689a3 100644
--- a/net/caif/caif_socket.c
+++ b/net/caif/caif_socket.c
@@ -1108,7 +1108,7 @@ static int caif_create(struct net *net, struct socket *sock, int protocol,
static int __init caif_sktinit_module(void)
{
int err = sock_register(&caif_family_ops);
- if (!err)
+ if (err)
return err;
return 0;
}
--
1.9.1
^ permalink raw reply related
* [PATCH 1/1] net: usb: set error code when usb_alloc_urb fails
From: Pan Bian @ 2016-12-03 11:24 UTC (permalink / raw)
To: Woojung Huh, Microchip Linux Driver Support, netdev, linux-usb
Cc: linux-kernel, Pan Bian
In function lan78xx_probe(), variable ret takes the errno code on
failures. However, when the call to usb_alloc_urb() fails, its value
will keeps 0. 0 indicates success in the context, which is inconsistent
with the execution result. This patch fixes the bug, assigning
"-ENOMEM" to ret when usb_alloc_urb() returns a NULL pointer.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188771
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
drivers/net/usb/lan78xx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/lan78xx.c b/drivers/net/usb/lan78xx.c
index db558b8..f33460c 100644
--- a/drivers/net/usb/lan78xx.c
+++ b/drivers/net/usb/lan78xx.c
@@ -3395,6 +3395,7 @@ static int lan78xx_probe(struct usb_interface *intf,
if (buf) {
dev->urb_intr = usb_alloc_urb(0, GFP_KERNEL);
if (!dev->urb_intr) {
+ ret = -ENOMEM;
kfree(buf);
goto out3;
} else {
--
1.9.1
^ permalink raw reply related
* [PATCH 1/1] net: bridge: set error code on failure
From: Pan Bian @ 2016-12-03 11:33 UTC (permalink / raw)
To: Stephen Hemminger, David S. Miller, bridge, netdev; +Cc: linux-kernel, Pan Bian
Function br_sysfs_addbr() does not set error code when the call
kobject_create_and_add() returns a NULL pointer. It may be better to
return "-ENOMEM" when kobject_create_and_add() fails.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188781
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
net/bridge/br_sysfs_br.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c
index e120307..f88c4df 100644
--- a/net/bridge/br_sysfs_br.c
+++ b/net/bridge/br_sysfs_br.c
@@ -898,6 +898,7 @@ int br_sysfs_addbr(struct net_device *dev)
if (!br->ifobj) {
pr_info("%s: can't add kobject (directory) %s/%s\n",
__func__, dev->name, SYSFS_BRIDGE_PORT_SUBDIR);
+ err = -ENOMEM;
goto out3;
}
return 0;
--
1.9.1
^ permalink raw reply related
* [PATCH 1/1] atm: lanai: set error code when ioremap fails
From: Pan Bian @ 2016-12-03 12:25 UTC (permalink / raw)
To: Chas Williams, linux-atm-general, netdev; +Cc: linux-kernel, Pan Bian
In function lanai_dev_open(), when the call to ioremap() fails, the
value of return variable result is 0. 0 means no error in this context.
This patch fixes the bug, assigning "-ENOMEM" to result when ioremap()
returns a NULL pointer.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188791
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
drivers/atm/lanai.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/atm/lanai.c b/drivers/atm/lanai.c
index ce43ae3..445505d 100644
--- a/drivers/atm/lanai.c
+++ b/drivers/atm/lanai.c
@@ -2143,6 +2143,7 @@ static int lanai_dev_open(struct atm_dev *atmdev)
lanai->base = (bus_addr_t) ioremap(raw_base, LANAI_MAPPING_SIZE);
if (lanai->base == NULL) {
printk(KERN_ERR DEV_LABEL ": couldn't remap I/O space\n");
+ result = -ENOMEM;
goto error_pci;
}
/* 3.3: Reset lanai and PHY */
--
1.9.1
^ permalink raw reply related
* net: use-after-free in worker_thread
From: Andrey Konovalov @ 2016-12-03 12:56 UTC (permalink / raw)
To: David S. Miller, Cong Wang, Johannes Berg, Florian Westphal,
Herbert Xu, Eric Dumazet, Bob Copeland, Tom Herbert,
David Decotigny, netdev, LKML
Hi!
I'm seeing lots of the following error reports while running the
syzkaller fuzzer.
Reports appeared when I updated to 3c49de52 (Dec 2) from 2caceb32 (Dec 1).
==================================================================
BUG: KASAN: use-after-free in worker_thread+0x17d8/0x18a0
Read of size 8 at addr ffff880067f3ecd8 by task kworker/3:1/774
page:ffffea00019fce00 count:1 mapcount:0 mapping: (null)
index:0xffff880067f39c10 compound_mapcount: 0
flags: 0x500000000004080(slab|head)
page dumped because: kasan: bad access detected
CPU: 3 PID: 774 Comm: kworker/3:1 Not tainted 4.9.0-rc7+ #66
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff88006c267838 ffffffff81f882da ffffffff6c25e338 1ffff1000d84ce9a
ffffed000d84ce92 ffff88006c25e340 0000000041b58ab3 ffffffff8541e198
ffffffff81f88048 0000000100000000 0000000041b58ab3 ffffffff853d3ee8
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff81f882da>] dump_stack+0x292/0x398 lib/dump_stack.c:51
[< inline >] describe_address mm/kasan/report.c:262
[<ffffffff817e50d1>] kasan_report_error+0x121/0x560 mm/kasan/report.c:368
[< inline >] kasan_report mm/kasan/report.c:390
[<ffffffff817e560e>] __asan_report_load8_noabort+0x3e/0x40
mm/kasan/report.c:411
[<ffffffff81329b88>] worker_thread+0x17d8/0x18a0 kernel/workqueue.c:2228
[<ffffffff8133ebf3>] kthread+0x323/0x3e0 kernel/kthread.c:209
[<ffffffff84a2a22a>] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433
The buggy address belongs to the object at ffff880067f3e6d0
which belongs to the cache kmalloc-2048 of size 2048
The buggy address ffff880067f3ecd8 is located 1544 bytes inside
of 2048-byte region [ffff880067f3e6d0, ffff880067f3eed0)
Freed by task 0:
[<ffffffff81203526>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
[<ffffffff817e4173>] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
[< inline >] set_track mm/kasan/kasan.c:507
[<ffffffff817e4a53>] kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:571
[< inline >] slab_free_hook mm/slub.c:1352
[< inline >] slab_free_freelist_hook mm/slub.c:1374
[< inline >] slab_free mm/slub.c:2951
[<ffffffff817e0eb7>] kfree+0xe7/0x2b0 mm/slub.c:3871
[< inline >] sk_prot_free net/core/sock.c:1372
[<ffffffff831ea1c7>] __sk_destruct+0x5c7/0x6e0 net/core/sock.c:1445
[<ffffffff831f3517>] sk_destruct+0x47/0x80 net/core/sock.c:1453
[<ffffffff831f35a7>] __sk_free+0x57/0x230 net/core/sock.c:1461
[<ffffffff831f37a3>] sk_free+0x23/0x30 net/core/sock.c:1472
[< inline >] sock_put include/net/sock.h:1591
[<ffffffff8348ca9c>] deferred_put_nlk_sk+0x2c/0x40 net/netlink/af_netlink.c:671
[< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
[<ffffffff8146d42f>] rcu_do_batch.isra.67+0x8ff/0xc50 kernel/rcu/tree.c:2776
[< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3040
[< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3007
[<ffffffff8146e097>] rcu_process_callbacks+0x2b7/0xba0 kernel/rcu/tree.c:3024
[<ffffffff84a2d08b>] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284
Allocated by task 10748:
[<ffffffff81203526>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
[<ffffffff817e4173>] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
[< inline >] set_track mm/kasan/kasan.c:507
[<ffffffff817e43fd>] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:598
[<ffffffff817e0050>] __kmalloc+0xa0/0x2d0 mm/slub.c:3734
[< inline >] kmalloc include/linux/slab.h:495
[<ffffffff831e4c01>] sk_prot_alloc+0x101/0x2a0 net/core/sock.c:1333
[<ffffffff831efd15>] sk_alloc+0x105/0x1000 net/core/sock.c:1389
[<ffffffff8348ad46>] __netlink_create+0x66/0x1d0 net/netlink/af_netlink.c:588
[<ffffffff8348cdab>] netlink_create+0x2fb/0x500 net/netlink/af_netlink.c:647
[<ffffffff831dd1d6>] __sock_create+0x4f6/0x880 net/socket.c:1168
[< inline >] sock_create net/socket.c:1208
[< inline >] SYSC_socket net/socket.c:1238
[<ffffffff831dd799>] SyS_socket+0xf9/0x230 net/socket.c:1218
[<ffffffff84a29fc1>] entry_SYSCALL_64_fastpath+0x1f/0xc2
Memory state around the buggy address:
ffff880067f3eb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff880067f3ec00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff880067f3ec80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff880067f3ed00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff880067f3ed80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
^ permalink raw reply
* Re: net: use-after-free in worker_thread
From: Andrey Konovalov @ 2016-12-03 13:05 UTC (permalink / raw)
To: David S. Miller, Cong Wang, Johannes Berg, Florian Westphal,
Herbert Xu, Eric Dumazet, Bob Copeland, Tom Herbert,
David Decotigny, netdev, LKML
Cc: Kostya Serebryany, Dmitry Vyukov, syzkaller
In-Reply-To: <CAAeHK+zDnDugPcdEGBnC6rt5iJMffz+tmmDkF=vv6u0YF=EMwg@mail.gmail.com>
On Sat, Dec 3, 2016 at 1:58 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> +syzkaller@googlegroups.com
>
> On Sat, Dec 3, 2016 at 1:56 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
>> Hi!
>>
>> I'm seeing lots of the following error reports while running the
>> syzkaller fuzzer.
>>
>> Reports appeared when I updated to 3c49de52 (Dec 2) from 2caceb32 (Dec 1).
>>
>> ==================================================================
>> BUG: KASAN: use-after-free in worker_thread+0x17d8/0x18a0
>> Read of size 8 at addr ffff880067f3ecd8 by task kworker/3:1/774
>>
>> page:ffffea00019fce00 count:1 mapcount:0 mapping: (null)
>> index:0xffff880067f39c10 compound_mapcount: 0
>> flags: 0x500000000004080(slab|head)
>> page dumped because: kasan: bad access detected
>>
>> CPU: 3 PID: 774 Comm: kworker/3:1 Not tainted 4.9.0-rc7+ #66
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> ffff88006c267838 ffffffff81f882da ffffffff6c25e338 1ffff1000d84ce9a
>> ffffed000d84ce92 ffff88006c25e340 0000000041b58ab3 ffffffff8541e198
>> ffffffff81f88048 0000000100000000 0000000041b58ab3 ffffffff853d3ee8
>> Call Trace:
>> [< inline >] __dump_stack lib/dump_stack.c:15
>> [<ffffffff81f882da>] dump_stack+0x292/0x398 lib/dump_stack.c:51
>> [< inline >] describe_address mm/kasan/report.c:262
>> [<ffffffff817e50d1>] kasan_report_error+0x121/0x560 mm/kasan/report.c:368
>> [< inline >] kasan_report mm/kasan/report.c:390
>> [<ffffffff817e560e>] __asan_report_load8_noabort+0x3e/0x40
>> mm/kasan/report.c:411
>> [<ffffffff81329b88>] worker_thread+0x17d8/0x18a0 kernel/workqueue.c:2228
>> [<ffffffff8133ebf3>] kthread+0x323/0x3e0 kernel/kthread.c:209
>> [<ffffffff84a2a22a>] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433
>>
>> The buggy address belongs to the object at ffff880067f3e6d0
>> which belongs to the cache kmalloc-2048 of size 2048
>> The buggy address ffff880067f3ecd8 is located 1544 bytes inside
>> of 2048-byte region [ffff880067f3e6d0, ffff880067f3eed0)
>>
>> Freed by task 0:
>> [<ffffffff81203526>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
>> [<ffffffff817e4173>] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
>> [< inline >] set_track mm/kasan/kasan.c:507
>> [<ffffffff817e4a53>] kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:571
>> [< inline >] slab_free_hook mm/slub.c:1352
>> [< inline >] slab_free_freelist_hook mm/slub.c:1374
>> [< inline >] slab_free mm/slub.c:2951
>> [<ffffffff817e0eb7>] kfree+0xe7/0x2b0 mm/slub.c:3871
>> [< inline >] sk_prot_free net/core/sock.c:1372
>> [<ffffffff831ea1c7>] __sk_destruct+0x5c7/0x6e0 net/core/sock.c:1445
>> [<ffffffff831f3517>] sk_destruct+0x47/0x80 net/core/sock.c:1453
>> [<ffffffff831f35a7>] __sk_free+0x57/0x230 net/core/sock.c:1461
>> [<ffffffff831f37a3>] sk_free+0x23/0x30 net/core/sock.c:1472
>> [< inline >] sock_put include/net/sock.h:1591
>> [<ffffffff8348ca9c>] deferred_put_nlk_sk+0x2c/0x40 net/netlink/af_netlink.c:671
>> [< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
>> [<ffffffff8146d42f>] rcu_do_batch.isra.67+0x8ff/0xc50 kernel/rcu/tree.c:2776
>> [< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3040
>> [< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3007
>> [<ffffffff8146e097>] rcu_process_callbacks+0x2b7/0xba0 kernel/rcu/tree.c:3024
>> [<ffffffff84a2d08b>] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284
>>
>> Allocated by task 10748:
>> [<ffffffff81203526>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
>> [<ffffffff817e4173>] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
>> [< inline >] set_track mm/kasan/kasan.c:507
>> [<ffffffff817e43fd>] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:598
>> [<ffffffff817e0050>] __kmalloc+0xa0/0x2d0 mm/slub.c:3734
>> [< inline >] kmalloc include/linux/slab.h:495
>> [<ffffffff831e4c01>] sk_prot_alloc+0x101/0x2a0 net/core/sock.c:1333
>> [<ffffffff831efd15>] sk_alloc+0x105/0x1000 net/core/sock.c:1389
>> [<ffffffff8348ad46>] __netlink_create+0x66/0x1d0 net/netlink/af_netlink.c:588
>> [<ffffffff8348cdab>] netlink_create+0x2fb/0x500 net/netlink/af_netlink.c:647
>> [<ffffffff831dd1d6>] __sock_create+0x4f6/0x880 net/socket.c:1168
>> [< inline >] sock_create net/socket.c:1208
>> [< inline >] SYSC_socket net/socket.c:1238
>> [<ffffffff831dd799>] SyS_socket+0xf9/0x230 net/socket.c:1218
>> [<ffffffff84a29fc1>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>>
>> Memory state around the buggy address:
>> ffff880067f3eb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ffff880067f3ec00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>>ffff880067f3ec80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ^
>> ffff880067f3ed00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ffff880067f3ed80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ==================================================================
Here is another report that looks related:
==================================================================
BUG: KASAN: use-after-free in __list_add+0x236/0x2c0
Read of size 8 at addr ffff880068854780 by task ksoftirqd/2/20
page:ffffea0001a21400 count:1 mapcount:0 mapping: (null)
index:0x0 compound_mapcount: 0
flags: 0x500000000004080(slab|head)
page dumped because: kasan: bad access detected
CPU: 2 PID: 20 Comm: ksoftirqd/2 Not tainted 4.9.0-rc7+ #66
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff88006daf6578 ffffffff81f882da ffffffff6daf62a0 1ffff1000db5ec42
ffffed000db5ec3a dffffc0000000000 0000000041b58ab3 ffffffff8541e198
ffffffff81f88048 ffff88006dac3610 ffff88006daf6300 0000000000000802
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff81f882da>] dump_stack+0x292/0x398 lib/dump_stack.c:51
[< inline >] describe_address mm/kasan/report.c:262
[<ffffffff817e50d1>] kasan_report_error+0x121/0x560 mm/kasan/report.c:368
[< inline >] kasan_report mm/kasan/report.c:390
[<ffffffff817e560e>] __asan_report_load8_noabort+0x3e/0x40
mm/kasan/report.c:411
[<ffffffff8200c166>] __list_add+0x236/0x2c0 lib/list_debug.c:30
[< inline >] list_add_tail include/linux/list.h:77
[<ffffffff8131e295>] insert_work+0x175/0x4b0 kernel/workqueue.c:1298
[<ffffffff8131eb52>] __queue_work+0x582/0x11e0 kernel/workqueue.c:1459
[<ffffffff81320c21>] queue_work_on+0x231/0x240 kernel/workqueue.c:1484
[< inline >] queue_work include/linux/workqueue.h:474
[< inline >] schedule_work include/linux/workqueue.h:532
[<ffffffff8348c8cc>] netlink_sock_destruct+0x23c/0x2d0
net/netlink/af_netlink.c:361
[<ffffffff831e9ce1>] __sk_destruct+0xe1/0x6e0 net/core/sock.c:1423
[<ffffffff831f3517>] sk_destruct+0x47/0x80 net/core/sock.c:1453
[<ffffffff831f35a7>] __sk_free+0x57/0x230 net/core/sock.c:1461
[<ffffffff831f37a3>] sk_free+0x23/0x30 net/core/sock.c:1472
[< inline >] sock_put include/net/sock.h:1591
[<ffffffff8348ca9c>] deferred_put_nlk_sk+0x2c/0x40 net/netlink/af_netlink.c:671
[< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
[<ffffffff8146d42f>] rcu_do_batch.isra.67+0x8ff/0xc50 kernel/rcu/tree.c:2776
[< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3040
[< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3007
[<ffffffff8146e097>] rcu_process_callbacks+0x2b7/0xba0 kernel/rcu/tree.c:3024
[<ffffffff84a2d08b>] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284
[<ffffffff812d38c0>] run_ksoftirqd+0x20/0x60 kernel/softirq.c:676
[<ffffffff81350132>] smpboot_thread_fn+0x562/0x860 kernel/smpboot.c:163
[<ffffffff8133ebf3>] kthread+0x323/0x3e0 kernel/kthread.c:209
[<ffffffff84a2a22a>] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433
The buggy address belongs to the object at ffff880068854170
which belongs to the cache kmalloc-2048 of size 2048
The buggy address ffff880068854780 is located 1552 bytes inside
of 2048-byte region [ffff880068854170, ffff880068854970)
Freed by task 20:
[<ffffffff81203526>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
[<ffffffff817e4173>] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
[< inline >] set_track mm/kasan/kasan.c:507
[<ffffffff817e4a53>] kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:571
[< inline >] slab_free_hook mm/slub.c:1352
[< inline >] slab_free_freelist_hook mm/slub.c:1374
[< inline >] slab_free mm/slub.c:2951
[<ffffffff817e0eb7>] kfree+0xe7/0x2b0 mm/slub.c:3871
[< inline >] sk_prot_free net/core/sock.c:1372
[<ffffffff831ea1c7>] __sk_destruct+0x5c7/0x6e0 net/core/sock.c:1445
[<ffffffff831f3517>] sk_destruct+0x47/0x80 net/core/sock.c:1453
[<ffffffff831f35a7>] __sk_free+0x57/0x230 net/core/sock.c:1461
[<ffffffff831f37a3>] sk_free+0x23/0x30 net/core/sock.c:1472
[< inline >] sock_put include/net/sock.h:1591
[<ffffffff8348ca9c>] deferred_put_nlk_sk+0x2c/0x40 net/netlink/af_netlink.c:671
[< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
[<ffffffff8146d42f>] rcu_do_batch.isra.67+0x8ff/0xc50 kernel/rcu/tree.c:2776
[< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3040
[< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3007
[<ffffffff8146e097>] rcu_process_callbacks+0x2b7/0xba0 kernel/rcu/tree.c:3024
[<ffffffff84a2d08b>] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284
Allocated by task 9480:
[<ffffffff81203526>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
[<ffffffff817e4173>] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
[< inline >] set_track mm/kasan/kasan.c:507
[<ffffffff817e43fd>] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:598
[<ffffffff817e0050>] __kmalloc+0xa0/0x2d0 mm/slub.c:3734
[< inline >] kmalloc include/linux/slab.h:495
[<ffffffff831e4c01>] sk_prot_alloc+0x101/0x2a0 net/core/sock.c:1333
[<ffffffff831efd15>] sk_alloc+0x105/0x1000 net/core/sock.c:1389
[<ffffffff8348ad46>] __netlink_create+0x66/0x1d0 net/netlink/af_netlink.c:588
[<ffffffff8348cdab>] netlink_create+0x2fb/0x500 net/netlink/af_netlink.c:647
[<ffffffff831dd1d6>] __sock_create+0x4f6/0x880 net/socket.c:1168
[< inline >] sock_create net/socket.c:1208
[< inline >] SYSC_socket net/socket.c:1238
[<ffffffff831dd799>] SyS_socket+0xf9/0x230 net/socket.c:1218
[<ffffffff84a29fc1>] entry_SYSCALL_64_fastpath+0x1f/0xc2
Memory state around the buggy address:
ffff880068854680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff880068854700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff880068854780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff880068854800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff880068854880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
^ permalink raw reply
* Re: net: use-after-free in worker_thread
From: Andrey Konovalov @ 2016-12-03 12:58 UTC (permalink / raw)
To: David S. Miller, Cong Wang, Johannes Berg, Florian Westphal,
Herbert Xu, Eric Dumazet, Bob Copeland, Tom Herbert,
David Decotigny, netdev, LKML
Cc: Kostya Serebryany, Dmitry Vyukov, syzkaller
In-Reply-To: <CAAeHK+x95-n__YSbzebp51ez78yjqjK4CJL=tgOgPuBuGh+q1A@mail.gmail.com>
+syzkaller@googlegroups.com
On Sat, Dec 3, 2016 at 1:56 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> Hi!
>
> I'm seeing lots of the following error reports while running the
> syzkaller fuzzer.
>
> Reports appeared when I updated to 3c49de52 (Dec 2) from 2caceb32 (Dec 1).
>
> ==================================================================
> BUG: KASAN: use-after-free in worker_thread+0x17d8/0x18a0
> Read of size 8 at addr ffff880067f3ecd8 by task kworker/3:1/774
>
> page:ffffea00019fce00 count:1 mapcount:0 mapping: (null)
> index:0xffff880067f39c10 compound_mapcount: 0
> flags: 0x500000000004080(slab|head)
> page dumped because: kasan: bad access detected
>
> CPU: 3 PID: 774 Comm: kworker/3:1 Not tainted 4.9.0-rc7+ #66
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffff88006c267838 ffffffff81f882da ffffffff6c25e338 1ffff1000d84ce9a
> ffffed000d84ce92 ffff88006c25e340 0000000041b58ab3 ffffffff8541e198
> ffffffff81f88048 0000000100000000 0000000041b58ab3 ffffffff853d3ee8
> Call Trace:
> [< inline >] __dump_stack lib/dump_stack.c:15
> [<ffffffff81f882da>] dump_stack+0x292/0x398 lib/dump_stack.c:51
> [< inline >] describe_address mm/kasan/report.c:262
> [<ffffffff817e50d1>] kasan_report_error+0x121/0x560 mm/kasan/report.c:368
> [< inline >] kasan_report mm/kasan/report.c:390
> [<ffffffff817e560e>] __asan_report_load8_noabort+0x3e/0x40
> mm/kasan/report.c:411
> [<ffffffff81329b88>] worker_thread+0x17d8/0x18a0 kernel/workqueue.c:2228
> [<ffffffff8133ebf3>] kthread+0x323/0x3e0 kernel/kthread.c:209
> [<ffffffff84a2a22a>] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433
>
> The buggy address belongs to the object at ffff880067f3e6d0
> which belongs to the cache kmalloc-2048 of size 2048
> The buggy address ffff880067f3ecd8 is located 1544 bytes inside
> of 2048-byte region [ffff880067f3e6d0, ffff880067f3eed0)
>
> Freed by task 0:
> [<ffffffff81203526>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
> [<ffffffff817e4173>] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
> [< inline >] set_track mm/kasan/kasan.c:507
> [<ffffffff817e4a53>] kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:571
> [< inline >] slab_free_hook mm/slub.c:1352
> [< inline >] slab_free_freelist_hook mm/slub.c:1374
> [< inline >] slab_free mm/slub.c:2951
> [<ffffffff817e0eb7>] kfree+0xe7/0x2b0 mm/slub.c:3871
> [< inline >] sk_prot_free net/core/sock.c:1372
> [<ffffffff831ea1c7>] __sk_destruct+0x5c7/0x6e0 net/core/sock.c:1445
> [<ffffffff831f3517>] sk_destruct+0x47/0x80 net/core/sock.c:1453
> [<ffffffff831f35a7>] __sk_free+0x57/0x230 net/core/sock.c:1461
> [<ffffffff831f37a3>] sk_free+0x23/0x30 net/core/sock.c:1472
> [< inline >] sock_put include/net/sock.h:1591
> [<ffffffff8348ca9c>] deferred_put_nlk_sk+0x2c/0x40 net/netlink/af_netlink.c:671
> [< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
> [<ffffffff8146d42f>] rcu_do_batch.isra.67+0x8ff/0xc50 kernel/rcu/tree.c:2776
> [< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3040
> [< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3007
> [<ffffffff8146e097>] rcu_process_callbacks+0x2b7/0xba0 kernel/rcu/tree.c:3024
> [<ffffffff84a2d08b>] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284
>
> Allocated by task 10748:
> [<ffffffff81203526>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
> [<ffffffff817e4173>] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
> [< inline >] set_track mm/kasan/kasan.c:507
> [<ffffffff817e43fd>] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:598
> [<ffffffff817e0050>] __kmalloc+0xa0/0x2d0 mm/slub.c:3734
> [< inline >] kmalloc include/linux/slab.h:495
> [<ffffffff831e4c01>] sk_prot_alloc+0x101/0x2a0 net/core/sock.c:1333
> [<ffffffff831efd15>] sk_alloc+0x105/0x1000 net/core/sock.c:1389
> [<ffffffff8348ad46>] __netlink_create+0x66/0x1d0 net/netlink/af_netlink.c:588
> [<ffffffff8348cdab>] netlink_create+0x2fb/0x500 net/netlink/af_netlink.c:647
> [<ffffffff831dd1d6>] __sock_create+0x4f6/0x880 net/socket.c:1168
> [< inline >] sock_create net/socket.c:1208
> [< inline >] SYSC_socket net/socket.c:1238
> [<ffffffff831dd799>] SyS_socket+0xf9/0x230 net/socket.c:1218
> [<ffffffff84a29fc1>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> Memory state around the buggy address:
> ffff880067f3eb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff880067f3ec00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>ffff880067f3ec80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff880067f3ed00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff880067f3ed80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
^ permalink raw reply
* Re: [PATCH 1/1] net: caif: fix ineffective error check
From: Sergei Shtylyov @ 2016-12-03 13:17 UTC (permalink / raw)
To: Pan Bian, Dmitry Tarnyagin, David S. Miller, netdev; +Cc: linux-kernel
In-Reply-To: <1480763901-5323-1-git-send-email-bianpan2016@163.com>
Hello.
On 12/3/2016 2:18 PM, Pan Bian wrote:
> In function caif_sktinit_module(), the check of the return value of
> sock_register() seems ineffective. This patch fixes it.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188751
>
> Signed-off-by: Pan Bian <bianpan2016@163.com>
> ---
> net/caif/caif_socket.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/caif/caif_socket.c b/net/caif/caif_socket.c
> index aa209b1..2a689a3 100644
> --- a/net/caif/caif_socket.c
> +++ b/net/caif/caif_socket.c
> @@ -1108,7 +1108,7 @@ static int caif_create(struct net *net, struct socket *sock, int protocol,
> static int __init caif_sktinit_module(void)
> {
> int err = sock_register(&caif_family_ops);
> - if (!err)
> + if (err)
> return err;
Why not just:
return sock_register(&caif_family_ops);
> return 0;
> }
MBR, Sergei
^ permalink raw reply
* Possible regression due to "net/sched: cls_flower: Add offload support using egress Hardware device"
From: Simon Horman @ 2016-12-03 13:17 UTC (permalink / raw)
To: Hadar Hen Zion
Cc: netdev, Saeed Mahameed, Jiri Pirko, Amir Vadai, Or Gerlitz,
Roi Dayan
Hi Hadar,
in net-next I am observing what appears to be an regression in net-next due to:
7091d8c7055d ("net/sched: cls_flower: Add offload support using egress Hardware device")
The problem occurs when adding a flower filter (without offload to a virtio
device).
# ethtool -d eth0
ethtool -i eth0
driver: virtio_net
...
# tc qdisc add dev eth0 ingress
# tc filter add dev eth0 protocol ip parent ffff: flower indev eth0
[ 104.302779] BUG: unable to handle kernel NULL pointer dereference at 00000000000000d5
[ 104.303388] IP: [<ffffffff812c966d>] fl_dump+0x18d/0x7b0
[ 104.304140] PGD 1f825067 [ 104.304535] PUD 1f81a067
PMD 0 [ 104.305080]
[ 104.305351] Oops: 0000 [#1] SMP
[ 104.305850] Modules linked in:
[ 104.306358] CPU: 0 PID: 164 Comm: tc Not tainted 4.9.0-rc6-01485-g7091d8c7055d #1217
[ 104.307603] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[ 104.309781] task: ffff8800167dac40 task.stack: ffffc9000017c000
[ 104.310950] RIP: 0010:[<ffffffff812c966d>] [<ffffffff812c966d>] fl_dump+0x18d/0x7b0
[ 104.311924] RSP: 0018:ffffc9000017fa40 EFLAGS: 00010246
[ 104.311924] RAX: ffff88001f830a00 RBX: ffff88001b320900 RCX: 0000000000000000
[ 104.311924] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000ffff0000
[ 104.311924] RBP: ffff8800167dec00 R08: 0000000000000000 R09: ffff88001f800034
[ 104.311924] R10: 00000000c6024032 R11: 0000000000000000 R12: ffff88001f800030
[ 104.311924] R13: ffff880016412e00 R14: ffff8800166fb200 R15: ffffc9000017fa50
[ 104.311924] FS: 00007fe24e0e6700(0000) GS:ffff88001b600000(0000) knlGS:0000000000000000
[ 104.311924] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 104.311924] CR2: 00000000000000d5 CR3: 000000001645a000 CR4: 00000000000006b0
[ 104.311924] Stack:
[ 104.311924] 0000000000000286 0000000000000000 0000000000000000 0000000000000000
[ 104.311924] 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 104.311924] ffff88001b320900 ffff88001f800000 ffff88001f800000 ffff880016412e00
[ 104.311924] Call Trace:
[ 104.311924] [<ffffffff812c452e>] ? tcf_fill_node.constprop.12+0x12e/0x180
[ 104.311924] [<ffffffff812c45f6>] ? tfilter_notify.constprop.11+0x76/0x100
[ 104.311924] [<ffffffff812c4ac9>] ? tc_ctl_tfilter+0x449/0x6c0
[ 104.311924] [<ffffffff812b17d3>] ? rtnetlink_rcv_msg+0x83/0x200
[ 104.311924] [<ffffffff812b1750>] ? rtnl_newlink+0x810/0x810
[ 104.311924] [<ffffffff812ce834>] ? netlink_rcv_skb+0x94/0xb0
[ 104.311924] [<ffffffff812ae4e4>] ? rtnetlink_rcv+0x24/0x30
[ 104.311924] [<ffffffff812ce1b5>] ? netlink_unicast+0x145/0x1d0
[ 104.311924] [<ffffffff812ce659>] ? netlink_sendmsg+0x369/0x390
[ 104.311924] [<ffffffff811119a3>] ? rw_copy_check_uvector+0x53/0x110
[ 104.311924] [<ffffffff81282830>] ? sock_sendmsg+0x10/0x20
[ 104.311924] [<ffffffff81282e97>] ? ___sys_sendmsg+0x1f7/0x200
[ 104.311924] [<ffffffff81282fb9>] ? ___sys_recvmsg+0x119/0x140
[ 104.311924] [<ffffffff810e3c70>] ? trace_raw_output_mm_lru_activate+0x60/0x60
[ 104.311924] [<ffffffff81105606>] ? page_add_new_anon_rmap+0x46/0x80
[ 104.311924] [<ffffffff810fd902>] ? handle_mm_fault+0xae2/0xb00
[ 104.311924] [<ffffffff81283da1>] ? __sys_sendmsg+0x41/0x70
[ 104.311924] [<ffffffff813b7560>] ? entry_SYSCALL_64_fastpath+0x13/0x94
[ 104.311924] Code: 85 5b ff ff ff e9 1a ff ff ff 4c 8d 7c 24 10 31 c0 b9 06 00 00 00 4c 8b 85 60 01 00 00 4c 89 ff f3 48 ab 49 8b 45 28 41 8b 7d 20 <41> f6 80 d5 00 00 00 80 48 8b 40 18 48 8b 40 08 0f 84 f0 fe ff
[ 104.311924] RIP [<ffffffff812c966d>] fl_dump+0x18d/0x7b0
[ 104.311924] RSP <ffffc9000017fa40>
[ 104.311924] CR2: 00000000000000d5
[ 104.347974] ---[ end trace 9d9dacd54834303d ]---
^ permalink raw reply
* [PATCH 1/1] net: ethernet: 3com: set error code on failures
From: Pan Bian @ 2016-12-03 13:24 UTC (permalink / raw)
To: David Dillow, netdev; +Cc: linux-kernel, Pan Bian
From: Pan Bian <bianpan2016@163.com>
In function typhoon_init_one(), returns the value of variable err on
errors. However, on some error paths, variable err is not set to a
negative errno. This patch assigns "-EIO" to err on those paths.
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
drivers/net/ethernet/3com/typhoon.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/3com/typhoon.c b/drivers/net/ethernet/3com/typhoon.c
index 8f8418d..9a477fc 100644
--- a/drivers/net/ethernet/3com/typhoon.c
+++ b/drivers/net/ethernet/3com/typhoon.c
@@ -2400,6 +2400,7 @@ enum state_values {
if(!is_valid_ether_addr(dev->dev_addr)) {
err_msg = "Could not obtain valid ethernet address, aborting";
+ err = -EIO;
goto error_out_reset;
}
@@ -2409,6 +2410,7 @@ enum state_values {
INIT_COMMAND_WITH_RESPONSE(&xp_cmd, TYPHOON_CMD_READ_VERSIONS);
if(typhoon_issue_command(tp, 1, &xp_cmd, 3, xp_resp) < 0) {
err_msg = "Could not get Sleep Image version";
+ err = -EIO;
goto error_out_reset;
}
@@ -2451,6 +2453,7 @@ enum state_values {
if(register_netdev(dev) < 0) {
err_msg = "unable to register netdev";
+ err = -EIO;
goto error_out_reset;
}
--
1.9.1
^ permalink raw reply related
* Re: net: use-after-free in worker_thread
From: Eric Dumazet @ 2016-12-03 13:49 UTC (permalink / raw)
To: Andrey Konovalov
Cc: David S. Miller, Cong Wang, Johannes Berg, Florian Westphal,
Herbert Xu, Eric Dumazet, Bob Copeland, Tom Herbert,
David Decotigny, netdev, LKML, Kostya Serebryany, Dmitry Vyukov,
syzkaller
In-Reply-To: <CAAeHK+wtAhv2vvLva5a9J52A-bZj1kY8tF8RT7bC=5QVnxOr7A@mail.gmail.com>
On Sat, 2016-12-03 at 14:05 +0100, Andrey Konovalov wrote:
> On Sat, Dec 3, 2016 at 1:58 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > +syzkaller@googlegroups.com
> >
> > On Sat, Dec 3, 2016 at 1:56 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> >> Hi!
> >>
> >> I'm seeing lots of the following error reports while running the
> >> syzkaller fuzzer.
> >>
> >> Reports appeared when I updated to 3c49de52 (Dec 2) from 2caceb32 (Dec 1).
> >>
> >> ==================================================================
> >> BUG: KASAN: use-after-free in worker_thread+0x17d8/0x18a0
> >> Read of size 8 at addr ffff880067f3ecd8 by task kworker/3:1/774
> >>
> >> page:ffffea00019fce00 count:1 mapcount:0 mapping: (null)
> >> index:0xffff880067f39c10 compound_mapcount: 0
> >> flags: 0x500000000004080(slab|head)
> >> page dumped because: kasan: bad access detected
> >>
> >> CPU: 3 PID: 774 Comm: kworker/3:1 Not tainted 4.9.0-rc7+ #66
> >> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> >> ffff88006c267838 ffffffff81f882da ffffffff6c25e338 1ffff1000d84ce9a
> >> ffffed000d84ce92 ffff88006c25e340 0000000041b58ab3 ffffffff8541e198
> >> ffffffff81f88048 0000000100000000 0000000041b58ab3 ffffffff853d3ee8
> >> Call Trace:
> >> [< inline >] __dump_stack lib/dump_stack.c:15
> >> [<ffffffff81f882da>] dump_stack+0x292/0x398 lib/dump_stack.c:51
> >> [< inline >] describe_address mm/kasan/report.c:262
> >> [<ffffffff817e50d1>] kasan_report_error+0x121/0x560 mm/kasan/report.c:368
> >> [< inline >] kasan_report mm/kasan/report.c:390
> >> [<ffffffff817e560e>] __asan_report_load8_noabort+0x3e/0x40
> >> mm/kasan/report.c:411
> >> [<ffffffff81329b88>] worker_thread+0x17d8/0x18a0 kernel/workqueue.c:2228
> >> [<ffffffff8133ebf3>] kthread+0x323/0x3e0 kernel/kthread.c:209
> >> [<ffffffff84a2a22a>] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433
> >>
> >> The buggy address belongs to the object at ffff880067f3e6d0
> >> which belongs to the cache kmalloc-2048 of size 2048
> >> The buggy address ffff880067f3ecd8 is located 1544 bytes inside
> >> of 2048-byte region [ffff880067f3e6d0, ffff880067f3eed0)
> >>
> >> Freed by task 0:
> >> [<ffffffff81203526>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
> >> [<ffffffff817e4173>] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
> >> [< inline >] set_track mm/kasan/kasan.c:507
> >> [<ffffffff817e4a53>] kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:571
> >> [< inline >] slab_free_hook mm/slub.c:1352
> >> [< inline >] slab_free_freelist_hook mm/slub.c:1374
> >> [< inline >] slab_free mm/slub.c:2951
> >> [<ffffffff817e0eb7>] kfree+0xe7/0x2b0 mm/slub.c:3871
> >> [< inline >] sk_prot_free net/core/sock.c:1372
> >> [<ffffffff831ea1c7>] __sk_destruct+0x5c7/0x6e0 net/core/sock.c:1445
> >> [<ffffffff831f3517>] sk_destruct+0x47/0x80 net/core/sock.c:1453
> >> [<ffffffff831f35a7>] __sk_free+0x57/0x230 net/core/sock.c:1461
> >> [<ffffffff831f37a3>] sk_free+0x23/0x30 net/core/sock.c:1472
> >> [< inline >] sock_put include/net/sock.h:1591
> >> [<ffffffff8348ca9c>] deferred_put_nlk_sk+0x2c/0x40 net/netlink/af_netlink.c:671
> >> [< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
> >> [<ffffffff8146d42f>] rcu_do_batch.isra.67+0x8ff/0xc50 kernel/rcu/tree.c:2776
> >> [< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3040
> >> [< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3007
> >> [<ffffffff8146e097>] rcu_process_callbacks+0x2b7/0xba0 kernel/rcu/tree.c:3024
> >> [<ffffffff84a2d08b>] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284
> >>
> >> Allocated by task 10748:
> >> [<ffffffff81203526>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
> >> [<ffffffff817e4173>] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
> >> [< inline >] set_track mm/kasan/kasan.c:507
> >> [<ffffffff817e43fd>] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:598
> >> [<ffffffff817e0050>] __kmalloc+0xa0/0x2d0 mm/slub.c:3734
> >> [< inline >] kmalloc include/linux/slab.h:495
> >> [<ffffffff831e4c01>] sk_prot_alloc+0x101/0x2a0 net/core/sock.c:1333
> >> [<ffffffff831efd15>] sk_alloc+0x105/0x1000 net/core/sock.c:1389
> >> [<ffffffff8348ad46>] __netlink_create+0x66/0x1d0 net/netlink/af_netlink.c:588
> >> [<ffffffff8348cdab>] netlink_create+0x2fb/0x500 net/netlink/af_netlink.c:647
> >> [<ffffffff831dd1d6>] __sock_create+0x4f6/0x880 net/socket.c:1168
> >> [< inline >] sock_create net/socket.c:1208
> >> [< inline >] SYSC_socket net/socket.c:1238
> >> [<ffffffff831dd799>] SyS_socket+0xf9/0x230 net/socket.c:1218
> >> [<ffffffff84a29fc1>] entry_SYSCALL_64_fastpath+0x1f/0xc2
> >>
> >> Memory state around the buggy address:
> >> ffff880067f3eb80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >> ffff880067f3ec00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >>>ffff880067f3ec80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >> ^
> >> ffff880067f3ed00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >> ffff880067f3ed80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >> ==================================================================
>
> Here is another report that looks related:
>
> ==================================================================
> BUG: KASAN: use-after-free in __list_add+0x236/0x2c0
> Read of size 8 at addr ffff880068854780 by task ksoftirqd/2/20
>
> page:ffffea0001a21400 count:1 mapcount:0 mapping: (null)
> index:0x0 compound_mapcount: 0
> flags: 0x500000000004080(slab|head)
> page dumped because: kasan: bad access detected
>
> CPU: 2 PID: 20 Comm: ksoftirqd/2 Not tainted 4.9.0-rc7+ #66
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffff88006daf6578 ffffffff81f882da ffffffff6daf62a0 1ffff1000db5ec42
> ffffed000db5ec3a dffffc0000000000 0000000041b58ab3 ffffffff8541e198
> ffffffff81f88048 ffff88006dac3610 ffff88006daf6300 0000000000000802
> Call Trace:
> [< inline >] __dump_stack lib/dump_stack.c:15
> [<ffffffff81f882da>] dump_stack+0x292/0x398 lib/dump_stack.c:51
> [< inline >] describe_address mm/kasan/report.c:262
> [<ffffffff817e50d1>] kasan_report_error+0x121/0x560 mm/kasan/report.c:368
> [< inline >] kasan_report mm/kasan/report.c:390
> [<ffffffff817e560e>] __asan_report_load8_noabort+0x3e/0x40
> mm/kasan/report.c:411
> [<ffffffff8200c166>] __list_add+0x236/0x2c0 lib/list_debug.c:30
> [< inline >] list_add_tail include/linux/list.h:77
> [<ffffffff8131e295>] insert_work+0x175/0x4b0 kernel/workqueue.c:1298
> [<ffffffff8131eb52>] __queue_work+0x582/0x11e0 kernel/workqueue.c:1459
> [<ffffffff81320c21>] queue_work_on+0x231/0x240 kernel/workqueue.c:1484
> [< inline >] queue_work include/linux/workqueue.h:474
> [< inline >] schedule_work include/linux/workqueue.h:532
> [<ffffffff8348c8cc>] netlink_sock_destruct+0x23c/0x2d0
> net/netlink/af_netlink.c:361
> [<ffffffff831e9ce1>] __sk_destruct+0xe1/0x6e0 net/core/sock.c:1423
> [<ffffffff831f3517>] sk_destruct+0x47/0x80 net/core/sock.c:1453
> [<ffffffff831f35a7>] __sk_free+0x57/0x230 net/core/sock.c:1461
> [<ffffffff831f37a3>] sk_free+0x23/0x30 net/core/sock.c:1472
> [< inline >] sock_put include/net/sock.h:1591
> [<ffffffff8348ca9c>] deferred_put_nlk_sk+0x2c/0x40 net/netlink/af_netlink.c:671
> [< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
> [<ffffffff8146d42f>] rcu_do_batch.isra.67+0x8ff/0xc50 kernel/rcu/tree.c:2776
> [< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3040
> [< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3007
> [<ffffffff8146e097>] rcu_process_callbacks+0x2b7/0xba0 kernel/rcu/tree.c:3024
> [<ffffffff84a2d08b>] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284
> [<ffffffff812d38c0>] run_ksoftirqd+0x20/0x60 kernel/softirq.c:676
> [<ffffffff81350132>] smpboot_thread_fn+0x562/0x860 kernel/smpboot.c:163
> [<ffffffff8133ebf3>] kthread+0x323/0x3e0 kernel/kthread.c:209
> [<ffffffff84a2a22a>] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433
>
> The buggy address belongs to the object at ffff880068854170
> which belongs to the cache kmalloc-2048 of size 2048
> The buggy address ffff880068854780 is located 1552 bytes inside
> of 2048-byte region [ffff880068854170, ffff880068854970)
>
> Freed by task 20:
> [<ffffffff81203526>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
> [<ffffffff817e4173>] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
> [< inline >] set_track mm/kasan/kasan.c:507
> [<ffffffff817e4a53>] kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:571
> [< inline >] slab_free_hook mm/slub.c:1352
> [< inline >] slab_free_freelist_hook mm/slub.c:1374
> [< inline >] slab_free mm/slub.c:2951
> [<ffffffff817e0eb7>] kfree+0xe7/0x2b0 mm/slub.c:3871
> [< inline >] sk_prot_free net/core/sock.c:1372
> [<ffffffff831ea1c7>] __sk_destruct+0x5c7/0x6e0 net/core/sock.c:1445
> [<ffffffff831f3517>] sk_destruct+0x47/0x80 net/core/sock.c:1453
> [<ffffffff831f35a7>] __sk_free+0x57/0x230 net/core/sock.c:1461
> [<ffffffff831f37a3>] sk_free+0x23/0x30 net/core/sock.c:1472
> [< inline >] sock_put include/net/sock.h:1591
> [<ffffffff8348ca9c>] deferred_put_nlk_sk+0x2c/0x40 net/netlink/af_netlink.c:671
> [< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
> [<ffffffff8146d42f>] rcu_do_batch.isra.67+0x8ff/0xc50 kernel/rcu/tree.c:2776
> [< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3040
> [< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3007
> [<ffffffff8146e097>] rcu_process_callbacks+0x2b7/0xba0 kernel/rcu/tree.c:3024
> [<ffffffff84a2d08b>] __do_softirq+0x2fb/0xb63 kernel/softirq.c:284
>
> Allocated by task 9480:
> [<ffffffff81203526>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
> [<ffffffff817e4173>] save_stack+0x43/0xd0 mm/kasan/kasan.c:495
> [< inline >] set_track mm/kasan/kasan.c:507
> [<ffffffff817e43fd>] kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:598
> [<ffffffff817e0050>] __kmalloc+0xa0/0x2d0 mm/slub.c:3734
> [< inline >] kmalloc include/linux/slab.h:495
> [<ffffffff831e4c01>] sk_prot_alloc+0x101/0x2a0 net/core/sock.c:1333
> [<ffffffff831efd15>] sk_alloc+0x105/0x1000 net/core/sock.c:1389
> [<ffffffff8348ad46>] __netlink_create+0x66/0x1d0 net/netlink/af_netlink.c:588
> [<ffffffff8348cdab>] netlink_create+0x2fb/0x500 net/netlink/af_netlink.c:647
> [<ffffffff831dd1d6>] __sock_create+0x4f6/0x880 net/socket.c:1168
> [< inline >] sock_create net/socket.c:1208
> [< inline >] SYSC_socket net/socket.c:1238
> [<ffffffff831dd799>] SyS_socket+0xf9/0x230 net/socket.c:1218
> [<ffffffff84a29fc1>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>
> Memory state around the buggy address:
> ffff880068854680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff880068854700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >ffff880068854780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff880068854800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff880068854880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
Hi Andrey. Please give us some rest during the week end ;)
This looks like the bug I mentioned earlier for which I have a pending
patch ? Can you try it ?
The RCU conversion done by Thomas was quite buggy.
Thanks.
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 602e5ebe9db39ec6c72708628bc48efad9f0e680..c348c4a5ea4ecc05dcc9e2afbc069ab65a1a57fe 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -475,8 +475,8 @@ static struct sock *netlink_lookup(struct net *net, int protocol, u32 portid)
rcu_read_lock();
sk = __netlink_lookup(table, portid, net);
- if (sk)
- sock_hold(sk);
+ if (sk && !atomic_inc_not_zero(&sk->sk_refcnt))
+ sk = NULL;
rcu_read_unlock();
return sk;
@@ -600,6 +600,7 @@ static int __netlink_create(struct net *net, struct socket *sock,
}
init_waitqueue_head(&nlk->wait);
+ sock_set_flag(sk, SOCK_RCU_FREE);
sk->sk_destruct = netlink_sock_destruct;
sk->sk_protocol = protocol;
return 0;
@@ -664,13 +665,6 @@ static int netlink_create(struct net *net, struct socket *sock, int protocol,
goto out;
}
-static void deferred_put_nlk_sk(struct rcu_head *head)
-{
- struct netlink_sock *nlk = container_of(head, struct netlink_sock, rcu);
-
- sock_put(&nlk->sk);
-}
-
static int netlink_release(struct socket *sock)
{
struct sock *sk = sock->sk;
@@ -743,7 +737,7 @@ static int netlink_release(struct socket *sock)
local_bh_disable();
sock_prot_inuse_add(sock_net(sk), &netlink_proto, -1);
local_bh_enable();
- call_rcu(&nlk->rcu, deferred_put_nlk_sk);
+ sock_put(sk);
return 0;
}
diff --git a/net/netlink/af_netlink.h b/net/netlink/af_netlink.h
index 4fdb3831897775547f77c069a8018c0d2a253c8c..988d1a02487e37b7efd4872dd0ab6d230e5a2021 100644
--- a/net/netlink/af_netlink.h
+++ b/net/netlink/af_netlink.h
@@ -33,7 +33,6 @@ struct netlink_sock {
struct module *module;
struct rhash_head node;
- struct rcu_head rcu;
struct work_struct work;
};
^ permalink raw reply related
* [PATCH 1/1] net: dcb: set error code on failures
From: Pan Bian @ 2016-12-03 13:49 UTC (permalink / raw)
To: David S. Miller, netdev; +Cc: linux-kernel, Pan Bian
From: Pan Bian <bianpan2016@163.com>
In function dcbnl_cee_fill(), returns the value of variable err on
errors. However, on some error paths (e.g. nla put fails), its value may
be 0. It may be better to explicitly set a negative errno to variable
err before returning.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188881
Signed-off-by: Pan Bian <bianpan2016@163.com>
---
net/dcb/dcbnl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/dcb/dcbnl.c b/net/dcb/dcbnl.c
index 4f6c186..3202d75 100644
--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -1353,6 +1353,7 @@ static int dcbnl_cee_fill(struct sk_buff *skb, struct net_device *netdev)
dcb_unlock:
spin_unlock_bh(&dcb_lock);
nla_put_failure:
+ err = -EMSGSIZE;
return err;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/1] net: ethernet: 3com: set error code on failures
From: Lino Sanfilippo @ 2016-12-03 13:53 UTC (permalink / raw)
To: Pan Bian, David Dillow, netdev; +Cc: linux-kernel, Pan Bian
In-Reply-To: <1480771470-6404-1-git-send-email-bianpan201602@163.com>
Hi,
On 03.12.2016 14:24, Pan Bian wrote:
> From: Pan Bian <bianpan2016@163.com>
>
> In function typhoon_init_one(), returns the value of variable err on
> errors. However, on some error paths, variable err is not set to a
> negative errno. This patch assigns "-EIO" to err on those paths.
>
> Signed-off-by: Pan Bian <bianpan2016@163.com>
>
> @@ -2409,6 +2410,7 @@ enum state_values {
> INIT_COMMAND_WITH_RESPONSE(&xp_cmd, TYPHOON_CMD_READ_VERSIONS);
> if(typhoon_issue_command(tp, 1, &xp_cmd, 3, xp_resp) < 0) {
> err_msg = "Could not get Sleep Image version";
> + err = -EIO;
> goto error_out_reset;
> }
>
> @@ -2451,6 +2453,7 @@ enum state_values {
>
> if(register_netdev(dev) < 0) {
> err_msg = "unable to register netdev";
> + err = -EIO;
> goto error_out_reset;
> }
>
>
Why not return the error value provided by the called functions? Is there a reason
to map different errors to -EIO?
Regards,
Lino
^ permalink raw reply
* (unknown),
From: cbordinaro @ 2016-12-03 13:59 UTC (permalink / raw)
To: netdev
[-- Attachment #1: MESSAGE_07189225617444_netdev.zip --]
[-- Type: application/zip, Size: 1430 bytes --]
^ permalink raw reply
* [PATCH net] team: team_port_add should check link_up before enable port
From: Xin Long @ 2016-12-03 13:42 UTC (permalink / raw)
To: network dev; +Cc: davem, Jiri Pirko
Now when users add a nic to team dev, the option 'enable' of the port
is true by default, as team_port_enable enables it after dev_open in
team_port_add.
But even if the port_dev has no carrier, like it's cable was unpluged,
the port is still enabled. It leads to that team dev couldn't work well
if this port was chosen to connect, and has no chance to change to use
other ports if link_watch is ethtool.
This patch is to enable the port only when the port_dev has carrier in
team_port_add.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
drivers/net/team/team.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index a380649..42004ac 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1140,6 +1140,7 @@ static int team_port_add(struct team *team, struct net_device *port_dev)
struct net_device *dev = team->dev;
struct team_port *port;
char *portname = port_dev->name;
+ bool linkup;
int err;
if (port_dev->flags & IFF_LOOPBACK) {
@@ -1249,9 +1250,12 @@ static int team_port_add(struct team *team, struct net_device *port_dev)
port->index = -1;
list_add_tail_rcu(&port->list, &team->port_list);
- team_port_enable(team, port);
+ linkup = !!netif_carrier_ok(port_dev);
+ if (linkup)
+ team_port_enable(team, port);
+
__team_compute_features(team);
- __team_port_change_port_added(port, !!netif_carrier_ok(port_dev));
+ __team_port_change_port_added(port, linkup);
__team_options_change_check(team);
netdev_info(dev, "Port device %s added\n", portname);
--
2.1.0
^ permalink raw reply related
* Re: arp_filter and IPv6 ND
From: Saku Ytti @ 2016-12-03 14:21 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: netdev
In-Reply-To: <96111ae8-9b68-943f-c9be-8fccdd614c8b@stressinduktion.org>
On 2 December 2016 at 20:39, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
Hey,
> E.g. you can use IP addresses bound to other interfaces to send replys
> on another interface. This can be useful if you have a limited amount of
> IP addresses on the system but much more interfaces. Especially if they
> are limited in scope, like in IPv6.
>
> Basically Cisco's feature of "unnumbered interface" is always provided
> in Linux. And there are certainly cases where you would want to use it,
> e.g. emulate private-vlan feature for network separation.
Got it, thanks, the explanation makes sense. And indeed it's valid
case, but also it is the exception, not the rule. I think it would be
entirely change the default and people who want 'unnumbered' style
behaviour (like some BRAS scenarios), will know how to and why to
configure it.
> Also in the BGP setup, you might have it easier to establish loopback
> neighbor contact by just using static on-link routes, without caring
> about more complex numbering there (otherwise you pretty soon introduce
> OSPF or some other routing protocol to do the recursive forward resolution).
The BGP is running on-link, it's just that the BGP is advertising loop
of Linux. Why the loop ends up in ND cache, I don't know.
>> Grand, not that I feel comfortable writing it. I'd rather see the
>> whole suppression functionality moved to neighbour.c from being AFI
>> specific.
>
> Yes sure, please provide a patch. A separate sysctl is necessary anyway
> because the current one is within the ipv4 procfs directory hierarchy.
Sorry, not a comfortable C programmer, I'm pretty confident I could
get it working, but I'm more confident that patch would be entirely
rejected and rewritten by someone who knows what they are doing.
I see no reason not to have AFI specific toggle, just logic and code
should be AFI agnostic, like GC (ARP/ND cache time) stuff in
neighbour.c is nicely done. Frankly whole ARP/ND code could do with
refactoring to make arp.c and ndisc.c more wire-format stuff and
behavioural code more in neighbour.c.
--
++ytti
^ permalink raw reply
* Re: [PATCH net] team: team_port_add should check link_up before enable port
From: Marcelo Ricardo Leitner @ 2016-12-03 14:57 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem, Jiri Pirko
In-Reply-To: <14defaf74cf554158b8e289dd394815da1d8760c.1480772531.git.lucien.xin@gmail.com>
On Sat, Dec 03, 2016 at 09:42:11PM +0800, Xin Long wrote:
> Now when users add a nic to team dev, the option 'enable' of the port
> is true by default, as team_port_enable enables it after dev_open in
> team_port_add.
>
> But even if the port_dev has no carrier, like it's cable was unpluged,
> the port is still enabled. It leads to that team dev couldn't work well
> if this port was chosen to connect, and has no chance to change to use
> other ports if link_watch is ethtool.
>
> This patch is to enable the port only when the port_dev has carrier in
> team_port_add.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
> drivers/net/team/team.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
> index a380649..42004ac 100644
> --- a/drivers/net/team/team.c
> +++ b/drivers/net/team/team.c
> @@ -1140,6 +1140,7 @@ static int team_port_add(struct team *team, struct net_device *port_dev)
> struct net_device *dev = team->dev;
> struct team_port *port;
> char *portname = port_dev->name;
> + bool linkup;
> int err;
>
> if (port_dev->flags & IFF_LOOPBACK) {
> @@ -1249,9 +1250,12 @@ static int team_port_add(struct team *team, struct net_device *port_dev)
>
> port->index = -1;
> list_add_tail_rcu(&port->list, &team->port_list);
> - team_port_enable(team, port);
> + linkup = !!netif_carrier_ok(port_dev);
The !! here is not needed anymore, netif_carrier_ok already returns a
bool.
static inline bool netif_carrier_ok(const struct net_device *dev)
> + if (linkup)
> + team_port_enable(team, port);
> +
> __team_compute_features(team);
> - __team_port_change_port_added(port, !!netif_carrier_ok(port_dev));
> + __team_port_change_port_added(port, linkup);
> __team_options_change_check(team);
>
> netdev_info(dev, "Port device %s added\n", portname);
> --
> 2.1.0
>
^ permalink raw reply
* Re: [PATCH v2 net] ixgbevf: fix invalid uses of napi_hash_del()
From: Eric Dumazet @ 2016-12-03 15:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Jeff Kirsher
In-Reply-To: <1479310010.8455.197.camel@edumazet-glaptop3.roam.corp.google.com>
On Wed, 2016-11-16 at 07:26 -0800, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> Calling napi_hash_del() before netif_napi_del() is dangerous
> if a synchronize_rcu() is not enforced before NAPI struct freeing.
>
> Lets leave this detail to core networking stack to get it right.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> index 7eaac3234049..bf4d7efc7dbd 100644
> --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
> @@ -2511,9 +2511,6 @@ static int ixgbevf_alloc_q_vectors(struct ixgbevf_adapter *adapter)
> while (q_idx) {
> q_idx--;
> q_vector = adapter->q_vector[q_idx];
> -#ifdef CONFIG_NET_RX_BUSY_POLL
> - napi_hash_del(&q_vector->napi);
> -#endif
> netif_napi_del(&q_vector->napi);
> kfree(q_vector);
> adapter->q_vector[q_idx] = NULL;
> @@ -2537,9 +2534,6 @@ static void ixgbevf_free_q_vectors(struct ixgbevf_adapter *adapter)
> struct ixgbevf_q_vector *q_vector = adapter->q_vector[q_idx];
>
> adapter->q_vector[q_idx] = NULL;
> -#ifdef CONFIG_NET_RX_BUSY_POLL
> - napi_hash_del(&q_vector->napi);
> -#endif
> netif_napi_del(&q_vector->napi);
> kfree(q_vector);
> }
>
>
It looks this patch was not picked up ?
Thanks !
^ permalink raw reply
* Re: [PATCH net-next 0/4]: Allow head adjustment in XDP prog
From: Jesper Dangaard Brouer @ 2016-12-03 15:17 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: brouer, netdev, Alexei Starovoitov, Brenden Blanco,
Daniel Borkmann, David Miller, Saeed Mahameed, Tariq Toukan,
Kernel Team
In-Reply-To: <1480721013-1047541-1-git-send-email-kafai@fb.com>
On Fri, 2 Dec 2016 15:23:29 -0800
Martin KaFai Lau <kafai@fb.com> wrote:
> This series adds a helper to allow head adjustment in XDP prog. mlx4
> driver has been modified to support this feature. An example is written
> to encapsulate a packet with an IPv4/v6 header and then XDP_TX it
> out.
Hi Martin,
It is great to see work in this area.
Push/pop of headers is listed as on of the missing features here:
https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/implementation/missing_features.html
We can hopefully soon cross that of the list :-)
Header push and pop desc:
https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/design/requirements.html#header-push-and-pop
Thanks for working on this! :-)))
--
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 1/1] net: ethernet: 3com: set error code on failures
From: Pan Bian @ 2016-12-03 15:23 UTC (permalink / raw)
To: Lino Sanfilippo, David Dillow, netdev; +Cc: PanBian, linux-kernel
In-Reply-To: <06dd8fc8-0c39-e79d-7e34-22bfab17d8a3@gmx.de>
From: PanBian <bianpan2016@163.com>
Hi, Lino,
There is no special reason to map different errors to -EIO. In the
original source code, err is set to -EIO on most error paths. I copied
that. I guess it has no difference with the error value provided by the
called functions in the view of callers of typhoon_init_one().
Thanks!
Best regards,
Pan
On Sat, Dec 03, 2016 at 02:53:07PM +0100, Lino Sanfilippo wrote:
> Hi,
>
> On 03.12.2016 14:24, Pan Bian wrote:
> > From: Pan Bian <bianpan2016@163.com>
> >
> > In function typhoon_init_one(), returns the value of variable err on
> > errors. However, on some error paths, variable err is not set to a
> > negative errno. This patch assigns "-EIO" to err on those paths.
> >
> > Signed-off-by: Pan Bian <bianpan2016@163.com>
>
> >
> > @@ -2409,6 +2410,7 @@ enum state_values {
> > INIT_COMMAND_WITH_RESPONSE(&xp_cmd, TYPHOON_CMD_READ_VERSIONS);
> > if(typhoon_issue_command(tp, 1, &xp_cmd, 3, xp_resp) < 0) {
> > err_msg = "Could not get Sleep Image version";
> > + err = -EIO;
> > goto error_out_reset;
> > }
> >
> > @@ -2451,6 +2453,7 @@ enum state_values {
> >
> > if(register_netdev(dev) < 0) {
> > err_msg = "unable to register netdev";
> > + err = -EIO;
> > goto error_out_reset;
> > }
> >
> >
>
> Why not return the error value provided by the called functions? Is there a reason
> to map different errors to -EIO?
>
> Regards,
> Lino
^ permalink raw reply
* Re: [PATCH net-next 1/4] bpf: xdp: Allow head adjustment in XDP prog
From: Jesper Dangaard Brouer @ 2016-12-03 15:24 UTC (permalink / raw)
To: Martin KaFai Lau
Cc: brouer, netdev, Alexei Starovoitov, Brenden Blanco,
Daniel Borkmann, David Miller, Saeed Mahameed, Tariq Toukan,
Kernel Team
In-Reply-To: <1480721013-1047541-2-git-send-email-kafai@fb.com>
On Fri, 2 Dec 2016 15:23:30 -0800
Martin KaFai Lau <kafai@fb.com> wrote:
> -bool bpf_helper_changes_skb_data(void *func)
> +BPF_CALL_2(bpf_xdp_adjust_head, struct xdp_buff *, xdp, int, offset)
> +{
> + /* Both mlx4 and mlx5 driver align each packet to PAGE_SIZE when
> + * XDP prog is set.
> + * If the above is not true for the other drivers to support
> + * bpf_xdp_adjust_head, struct xdp_buff can be extended.
> + */
> + void *head = (void *)((unsigned long)xdp->data & PAGE_MASK);
> + void *new_data = xdp->data + offset;
> +
> + if (new_data < head || new_data >= xdp->data_end)
> + /* The packet length must be >=1 */
> + return -EINVAL;
> +
> + xdp->data = new_data;
> +
> + return 0;
> +}
First time I read this code, I was about to complain about you didn't
use XDP_PACKET_HEADROOM in your boundary check. But then I noticed the
PAGE_MASK. If you rename "head" to "page_boundary" or "page_start"
then IMHO the code would be more readable.
--
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 1/1] net: caif: fix ineffective error check
From: Pan Bian @ 2016-12-03 15:38 UTC (permalink / raw)
To: Sergei Shtylyov, Dmitry Tarnyagin, David S. Miller
Cc: PanBian, netdev, linux-kernel
In-Reply-To: <f214a441-9e4b-6c40-f09d-32a6d1ea4dd0@cogentembedded.com>
From: PanBian <bianpan2016@163.com>
Hello Sergei,
On Sat, Dec 03, 2016 at 04:17:51PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 12/3/2016 2:18 PM, Pan Bian wrote:
>
> >In function caif_sktinit_module(), the check of the return value of
> >sock_register() seems ineffective. This patch fixes it.
> >
> >Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188751
> >
> >Signed-off-by: Pan Bian <bianpan2016@163.com>
> >---
> > net/caif/caif_socket.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/net/caif/caif_socket.c b/net/caif/caif_socket.c
> >index aa209b1..2a689a3 100644
> >--- a/net/caif/caif_socket.c
> >+++ b/net/caif/caif_socket.c
> >@@ -1108,7 +1108,7 @@ static int caif_create(struct net *net, struct socket *sock, int protocol,
> > static int __init caif_sktinit_module(void)
> > {
> > int err = sock_register(&caif_family_ops);
> >- if (!err)
> >+ if (err)
> > return err;
>
> Why not just:
>
> return sock_register(&caif_family_ops);
>
Your solution looks much cleaner.
But I am not really sure whether it is the author's intention to
return 0 anyway. Do you have any idea?
Thanks!
> > return 0;
> > }
>
> MBR, Sergei
>
Best regards,
Pan
^ 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