* [patch net-next v4 05/10] rocker: Create an ordered workqueue for FIB offload
From: Jiri Pirko @ 2016-12-03 15:45 UTC (permalink / raw)
To: netdev
Cc: davem, idosch, eladr, yotamg, nogahf, arkadis, ogerlitz, roopa,
dsa, nikolay, andy, vivien.didelot, andrew, f.fainelli,
alexander.h.duyck, hannes, kaber
In-Reply-To: <1480779907-32535-1-git-send-email-jiri@resnulli.us>
From: Ido Schimmel <idosch@mellanox.com>
As explained in the previous commits, we need to process FIB entries
addition / deletion events in FIFO order or otherwise we can have a
mismatch between the kernel's FIB table and the device's.
Create an ordered workqueue for rocker to which these work items will be
submitted to.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/rocker/rocker.h | 1 +
drivers/net/ethernet/rocker/rocker_main.c | 11 +++++++++++
2 files changed, 12 insertions(+)
diff --git a/drivers/net/ethernet/rocker/rocker.h b/drivers/net/ethernet/rocker/rocker.h
index 2eb9b49..ee9675d 100644
--- a/drivers/net/ethernet/rocker/rocker.h
+++ b/drivers/net/ethernet/rocker/rocker.h
@@ -72,6 +72,7 @@ struct rocker {
struct rocker_dma_ring_info event_ring;
struct notifier_block fib_nb;
struct rocker_world_ops *wops;
+ struct workqueue_struct *rocker_owq;
void *wpriv;
};
diff --git a/drivers/net/ethernet/rocker/rocker_main.c b/drivers/net/ethernet/rocker/rocker_main.c
index 67df4cf..424be96 100644
--- a/drivers/net/ethernet/rocker/rocker_main.c
+++ b/drivers/net/ethernet/rocker/rocker_main.c
@@ -28,6 +28,7 @@
#include <linux/if_bridge.h>
#include <linux/bitops.h>
#include <linux/ctype.h>
+#include <linux/workqueue.h>
#include <net/switchdev.h>
#include <net/rtnetlink.h>
#include <net/netevent.h>
@@ -2754,6 +2755,13 @@ static int rocker_probe(struct pci_dev *pdev, const struct pci_device_id *id)
goto err_request_event_irq;
}
+ rocker->rocker_owq = alloc_ordered_workqueue(rocker_driver_name,
+ WQ_MEM_RECLAIM);
+ if (!rocker->rocker_owq) {
+ err = -ENOMEM;
+ goto err_alloc_ordered_workqueue;
+ }
+
rocker->hw.id = rocker_read64(rocker, SWITCH_ID);
err = rocker_probe_ports(rocker);
@@ -2771,6 +2779,8 @@ static int rocker_probe(struct pci_dev *pdev, const struct pci_device_id *id)
return 0;
err_probe_ports:
+ destroy_workqueue(rocker->rocker_owq);
+err_alloc_ordered_workqueue:
free_irq(rocker_msix_vector(rocker, ROCKER_MSIX_VEC_EVENT), rocker);
err_request_event_irq:
free_irq(rocker_msix_vector(rocker, ROCKER_MSIX_VEC_CMD), rocker);
@@ -2799,6 +2809,7 @@ static void rocker_remove(struct pci_dev *pdev)
unregister_fib_notifier(&rocker->fib_nb);
rocker_write32(rocker, CONTROL, ROCKER_CONTROL_RESET);
rocker_remove_ports(rocker);
+ destroy_workqueue(rocker->rocker_owq);
free_irq(rocker_msix_vector(rocker, ROCKER_MSIX_VEC_EVENT), rocker);
free_irq(rocker_msix_vector(rocker, ROCKER_MSIX_VEC_CMD), rocker);
rocker_dma_rings_fini(rocker);
--
2.7.4
^ permalink raw reply related
* [patch net-next v4 03/10] mlxsw: core: Create an ordered workqueue for FIB offload
From: Jiri Pirko @ 2016-12-03 15:45 UTC (permalink / raw)
To: netdev
Cc: davem, idosch, eladr, yotamg, nogahf, arkadis, ogerlitz, roopa,
dsa, nikolay, andy, vivien.didelot, andrew, f.fainelli,
alexander.h.duyck, hannes, kaber
In-Reply-To: <1480779907-32535-1-git-send-email-jiri@resnulli.us>
From: Ido Schimmel <idosch@mellanox.com>
We're going to start processing FIB entries addition / deletion events
in deferred work. These work items must be processed in the order they
were submitted or otherwise we can have differences between the kernel's
FIB table and the device's.
Solve this by creating an ordered workqueue to which these work items
will be submitted to. Note that we can't simply convert the current
workqueue to be ordered, as EMADs re-transmissions are also processed in
deferred work.
Later on, we can migrate other work items to this workqueue, such as FDB
notification processing and nexthop resolution, since they all take the
same lock anyway.
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/core.c | 22 ++++++++++++++++++++++
drivers/net/ethernet/mellanox/mlxsw/core.h | 2 ++
2 files changed, 24 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core.c b/drivers/net/ethernet/mellanox/mlxsw/core.c
index 4dc028b..57a9884 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/core.c
@@ -77,6 +77,7 @@ static const char mlxsw_core_driver_name[] = "mlxsw_core";
static struct dentry *mlxsw_core_dbg_root;
static struct workqueue_struct *mlxsw_wq;
+static struct workqueue_struct *mlxsw_owq;
struct mlxsw_core_pcpu_stats {
u64 trap_rx_packets[MLXSW_TRAP_ID_MAX];
@@ -1900,6 +1901,18 @@ int mlxsw_core_schedule_dw(struct delayed_work *dwork, unsigned long delay)
}
EXPORT_SYMBOL(mlxsw_core_schedule_dw);
+int mlxsw_core_schedule_odw(struct delayed_work *dwork, unsigned long delay)
+{
+ return queue_delayed_work(mlxsw_owq, dwork, delay);
+}
+EXPORT_SYMBOL(mlxsw_core_schedule_odw);
+
+void mlxsw_core_flush_owq(void)
+{
+ flush_workqueue(mlxsw_owq);
+}
+EXPORT_SYMBOL(mlxsw_core_flush_owq);
+
static int __init mlxsw_core_module_init(void)
{
int err;
@@ -1907,6 +1920,12 @@ static int __init mlxsw_core_module_init(void)
mlxsw_wq = alloc_workqueue(mlxsw_core_driver_name, WQ_MEM_RECLAIM, 0);
if (!mlxsw_wq)
return -ENOMEM;
+ mlxsw_owq = alloc_ordered_workqueue("%s_ordered", WQ_MEM_RECLAIM,
+ mlxsw_core_driver_name);
+ if (!mlxsw_owq) {
+ err = -ENOMEM;
+ goto err_alloc_ordered_workqueue;
+ }
mlxsw_core_dbg_root = debugfs_create_dir(mlxsw_core_driver_name, NULL);
if (!mlxsw_core_dbg_root) {
err = -ENOMEM;
@@ -1915,6 +1934,8 @@ static int __init mlxsw_core_module_init(void)
return 0;
err_debugfs_create_dir:
+ destroy_workqueue(mlxsw_owq);
+err_alloc_ordered_workqueue:
destroy_workqueue(mlxsw_wq);
return err;
}
@@ -1922,6 +1943,7 @@ static int __init mlxsw_core_module_init(void)
static void __exit mlxsw_core_module_exit(void)
{
debugfs_remove_recursive(mlxsw_core_dbg_root);
+ destroy_workqueue(mlxsw_owq);
destroy_workqueue(mlxsw_wq);
}
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core.h b/drivers/net/ethernet/mellanox/mlxsw/core.h
index e856b49..a7f94fb 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/core.h
@@ -207,6 +207,8 @@ enum devlink_port_type mlxsw_core_port_type_get(struct mlxsw_core *mlxsw_core,
u8 local_port);
int mlxsw_core_schedule_dw(struct delayed_work *dwork, unsigned long delay);
+int mlxsw_core_schedule_odw(struct delayed_work *dwork, unsigned long delay);
+void mlxsw_core_flush_owq(void);
#define MLXSW_CONFIG_PROFILE_SWID_COUNT 8
--
2.7.4
^ permalink raw reply related
* [patch net-next v4 02/10] ipv4: fib: Add fib_info_hold() helper
From: Jiri Pirko @ 2016-12-03 15:44 UTC (permalink / raw)
To: netdev
Cc: davem, idosch, eladr, yotamg, nogahf, arkadis, ogerlitz, roopa,
dsa, nikolay, andy, vivien.didelot, andrew, f.fainelli,
alexander.h.duyck, hannes, kaber
In-Reply-To: <1480779907-32535-1-git-send-email-jiri@resnulli.us>
From: Ido Schimmel <idosch@mellanox.com>
As explained in the previous commit, modules are going to need to take a
reference on fib info and then drop it using fib_info_put().
Add the fib_info_hold() helper to make the code more readable and also
symmetric with fib_info_put().
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Suggested-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
include/net/ip_fib.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/include/net/ip_fib.h b/include/net/ip_fib.h
index f390c3b..6c67b93 100644
--- a/include/net/ip_fib.h
+++ b/include/net/ip_fib.h
@@ -397,6 +397,11 @@ static inline void fib_combine_itag(u32 *itag, const struct fib_result *res)
void free_fib_info(struct fib_info *fi);
+static inline void fib_info_hold(struct fib_info *fi)
+{
+ atomic_inc(&fi->fib_clntref);
+}
+
static inline void fib_info_put(struct fib_info *fi)
{
if (atomic_dec_and_test(&fi->fib_clntref))
--
2.7.4
^ permalink raw reply related
* [patch net-next v4 01/10] ipv4: fib: Export free_fib_info()
From: Jiri Pirko @ 2016-12-03 15:44 UTC (permalink / raw)
To: netdev
Cc: davem, idosch, eladr, yotamg, nogahf, arkadis, ogerlitz, roopa,
dsa, nikolay, andy, vivien.didelot, andrew, f.fainelli,
alexander.h.duyck, hannes, kaber
In-Reply-To: <1480779907-32535-1-git-send-email-jiri@resnulli.us>
From: Ido Schimmel <idosch@mellanox.com>
The FIB notification chain is going to be converted to an atomic chain,
which means switchdev drivers will have to offload FIB entries in
deferred work, as hardware operations entail sleeping.
However, while the work is queued fib info might be freed, so a
reference must be taken. To release the reference (and potentially free
the fib info) fib_info_put() will be called, which in turn calls
free_fib_info().
Export free_fib_info() so that modules will be able to invoke
fib_info_put().
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
net/ipv4/fib_semantics.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index 388d3e2..c1bc1e9 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -234,6 +234,7 @@ void free_fib_info(struct fib_info *fi)
#endif
call_rcu(&fi->rcu, free_fib_info_rcu);
}
+EXPORT_SYMBOL_GPL(free_fib_info);
void fib_release_info(struct fib_info *fi)
{
--
2.7.4
^ permalink raw reply related
* [patch net-next v4 00/10] ipv4: fib: Replay events when registering FIB notifier
From: Jiri Pirko @ 2016-12-03 15:44 UTC (permalink / raw)
To: netdev
Cc: davem, idosch, eladr, yotamg, nogahf, arkadis, ogerlitz, roopa,
dsa, nikolay, andy, vivien.didelot, andrew, f.fainelli,
alexander.h.duyck, hannes, kaber
From: Jiri Pirko <jiri@mellanox.com>
Ido says:
In kernel 4.9 the switchdev-specific FIB offload mechanism was replaced
by a new FIB notification chain to which modules could register in order
to be notified about the addition and deletion of FIB entries. The
motivation for this change was that switchdev drivers need to be able to
reflect the entire FIB table and not only FIBs configured on top of the
port netdevs themselves. This is useful in case of in-band management.
The fundamental problem with this approach is that upon registration
listeners lose all the information previously sent in the chain and
thus have an incomplete view of the FIB tables, which can result in
packet loss. This patchset fixes that by dumping the FIB tables and
replaying notifications previously sent in the chain for the registered
notification block.
The entire dump process is done under RCU and thus the FIB notification
chain is converted to be atomic. The listeners are modified accordingly.
This is done in the first eight patches.
The ninth patch adds a change sequence counter to ensure the integrity
of the FIB dump. The last patch adds the dump itself to the FIB chain
registration function and modifies existing listeners to pass a callback
to be executed in case dump was inconsistent.
---
v3->v4:
- Register the notification block after the dump and protect it using
the change sequence counter (Hannes Frederic Sowa).
- Since we now integrate the dump into the registration function, drop
the sysctl to set maximum number of retries and instead set it to a
fixed number. Lets see if it's really a problem before adding something
we can never remove.
- For the same reason, dump FIB tables for all net namespaces.
- Add a comment regarding guarantees provided by mutex semantics.
v2->v3:
- Add sysctl to set the number of FIB dump retries (Hannes Frederic Sowa).
- Read the sequence counter under RTNL to ensure synchronization
between the dump process and other processes changing the routing
tables (Hannes Frederic Sowa).
- Pass a callback to the dump function to be executed prior to a retry.
- Limit the dump to a single net namespace.
v1->v2:
- Add a sequence counter to ensure the integrity of the FIB dump
(David S. Miller, Hannes Frederic Sowa).
- Protect notifications from re-ordering in listeners by using an
ordered workqueue (Hannes Frederic Sowa).
- Introduce fib_info_hold() (Jiri Pirko).
- Relieve rocker from the need to invoke the FIB dump by registering
to the FIB notification chain prior to ports creation.
Ido Schimmel (10):
ipv4: fib: Export free_fib_info()
ipv4: fib: Add fib_info_hold() helper
mlxsw: core: Create an ordered workqueue for FIB offload
mlxsw: spectrum_router: Implement FIB offload in deferred work
rocker: Create an ordered workqueue for FIB offload
rocker: Implement FIB offload in deferred work
rocker: Register FIB notifier before creating ports
ipv4: fib: Convert FIB notification chain to be atomic
ipv4: fib: Allow for consistent FIB dumping
ipv4: fib: Replay events when registering FIB notifier
drivers/net/ethernet/mellanox/mlxsw/core.c | 22 +++
drivers/net/ethernet/mellanox/mlxsw/core.h | 2 +
.../net/ethernet/mellanox/mlxsw/spectrum_router.c | 92 ++++++++++--
drivers/net/ethernet/rocker/rocker.h | 1 +
drivers/net/ethernet/rocker/rocker_main.c | 84 +++++++++--
drivers/net/ethernet/rocker/rocker_ofdpa.c | 1 +
include/net/ip_fib.h | 8 +-
include/net/netns/ipv4.h | 3 +
net/ipv4/fib_frontend.c | 2 +
net/ipv4/fib_semantics.c | 1 +
net/ipv4/fib_trie.c | 155 ++++++++++++++++++++-
11 files changed, 342 insertions(+), 29 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: net: use-after-free in worker_thread
From: Andrey Konovalov @ 2016-12-03 15:39 UTC (permalink / raw)
To: syzkaller
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
In-Reply-To: <1480772947.18162.402.camel@edumazet-glaptop3.roam.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 14438 bytes --]
On Sat, Dec 3, 2016 at 2:49 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 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 ;)
Hi Eric,
Sorry, wanted to restart fuzzer on newer kernel and immediately
started getting enormous amount of crashes :)
>
> This looks like the bug I mentioned earlier for which I have a pending
> patch ? Can you try it ?
No, it seems that your patch doesn't help, this is apparently something else.
I've attached a reproducer.
Thanks!
>
> 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;
> };
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: worker-crash-poc.c --]
[-- Type: text/x-csrc, Size: 8352 bytes --]
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#ifndef __NR_socket
#define __NR_socket 41
#endif
#ifndef __NR_write
#define __NR_write 1
#endif
#ifndef __NR_readv
#define __NR_readv 19
#endif
#ifndef __NR_mmap
#define __NR_mmap 9
#endif
#define _GNU_SOURCE
#include <sys/ioctl.h>
#include <sys/mount.h>
#include <sys/prctl.h>
#include <sys/resource.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/time.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <linux/capability.h>
#include <linux/if.h>
#include <linux/if_tun.h>
#include <linux/sched.h>
#include <net/if_arp.h>
#include <assert.h>
#include <dirent.h>
#include <errno.h>
#include <fcntl.h>
#include <grp.h>
#include <pthread.h>
#include <setjmp.h>
#include <signal.h>
#include <stdarg.h>
#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
const int kFailStatus = 67;
const int kErrorStatus = 68;
const int kRetryStatus = 69;
__attribute__((noreturn)) void fail(const char* msg, ...)
{
int e = errno;
fflush(stdout);
va_list args;
va_start(args, msg);
vfprintf(stderr, msg, args);
va_end(args);
fprintf(stderr, " (errno %d)\n", e);
exit(kFailStatus);
}
__attribute__((noreturn)) void exitf(const char* msg, ...)
{
int e = errno;
fflush(stdout);
va_list args;
va_start(args, msg);
vfprintf(stderr, msg, args);
va_end(args);
fprintf(stderr, " (errno %d)\n", e);
exit(kRetryStatus);
}
static int flag_debug;
void debug(const char* msg, ...)
{
if (!flag_debug)
return;
va_list args;
va_start(args, msg);
vfprintf(stdout, msg, args);
va_end(args);
fflush(stdout);
}
__thread int skip_segv;
__thread jmp_buf segv_env;
static void segv_handler(int sig, siginfo_t* info, void* uctx)
{
if (__atomic_load_n(&skip_segv, __ATOMIC_RELAXED))
_longjmp(segv_env, 1);
exit(sig);
}
static void install_segv_handler()
{
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_sigaction = segv_handler;
sa.sa_flags = SA_NODEFER | SA_SIGINFO;
sigaction(SIGSEGV, &sa, NULL);
sigaction(SIGBUS, &sa, NULL);
}
#define NONFAILING(...) \
{ \
__atomic_fetch_add(&skip_segv, 1, __ATOMIC_SEQ_CST); \
if (_setjmp(segv_env) == 0) { \
__VA_ARGS__; \
} \
__atomic_fetch_sub(&skip_segv, 1, __ATOMIC_SEQ_CST); \
}
static uintptr_t execute_syscall(int nr, uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5,
uintptr_t a6, uintptr_t a7,
uintptr_t a8)
{
switch (nr) {
default:
return syscall(nr, a0, a1, a2, a3, a4, a5);
}
}
static void setup_main_process(uint64_t pid, bool enable_tun)
{
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_handler = SIG_IGN;
syscall(SYS_rt_sigaction, 0x20, &sa, NULL, 8);
syscall(SYS_rt_sigaction, 0x21, &sa, NULL, 8);
install_segv_handler();
char tmpdir_template[] = "./syzkaller.XXXXXX";
char* tmpdir = mkdtemp(tmpdir_template);
if (!tmpdir)
fail("failed to mkdtemp");
if (chmod(tmpdir, 0777))
fail("failed to chmod");
if (chdir(tmpdir))
fail("failed to chdir");
}
static void loop();
static void sandbox_common()
{
prctl(PR_SET_PDEATHSIG, SIGKILL, 0, 0, 0);
setpgrp();
setsid();
struct rlimit rlim;
rlim.rlim_cur = rlim.rlim_max = 128 << 20;
setrlimit(RLIMIT_AS, &rlim);
rlim.rlim_cur = rlim.rlim_max = 1 << 20;
setrlimit(RLIMIT_FSIZE, &rlim);
rlim.rlim_cur = rlim.rlim_max = 1 << 20;
setrlimit(RLIMIT_STACK, &rlim);
rlim.rlim_cur = rlim.rlim_max = 0;
setrlimit(RLIMIT_CORE, &rlim);
unshare(CLONE_NEWNS);
unshare(CLONE_NEWIPC);
unshare(CLONE_IO);
}
static int do_sandbox_none()
{
int pid = fork();
if (pid)
return pid;
sandbox_common();
loop();
exit(1);
}
static void remove_dir(const char* dir)
{
DIR* dp;
struct dirent* ep;
int iter = 0;
retry:
dp = opendir(dir);
if (dp == NULL) {
if (errno == EMFILE) {
exitf("opendir(%s) failed due to NOFILE, exiting");
}
exitf("opendir(%s) failed", dir);
}
while ((ep = readdir(dp))) {
if (strcmp(ep->d_name, ".") == 0 || strcmp(ep->d_name, "..") == 0)
continue;
char filename[FILENAME_MAX];
snprintf(filename, sizeof(filename), "%s/%s", dir, ep->d_name);
struct stat st;
if (lstat(filename, &st))
exitf("lstat(%s) failed", filename);
if (S_ISDIR(st.st_mode)) {
remove_dir(filename);
continue;
}
int i;
for (i = 0;; i++) {
debug("unlink(%s)\n", filename);
if (unlink(filename) == 0)
break;
if (errno == EROFS) {
debug("ignoring EROFS\n");
break;
}
if (errno != EBUSY || i > 100)
exitf("unlink(%s) failed", filename);
debug("umount(%s)\n", filename);
if (umount2(filename, MNT_DETACH))
exitf("umount(%s) failed", filename);
}
}
closedir(dp);
int i;
for (i = 0;; i++) {
debug("rmdir(%s)\n", dir);
if (rmdir(dir) == 0)
break;
if (i < 100) {
if (errno == EROFS) {
debug("ignoring EROFS\n");
break;
}
if (errno == EBUSY) {
debug("umount(%s)\n", dir);
if (umount2(dir, MNT_DETACH))
exitf("umount(%s) failed", dir);
continue;
}
if (errno == ENOTEMPTY) {
if (iter < 100) {
iter++;
goto retry;
}
}
}
exitf("rmdir(%s) failed", dir);
}
}
static uint64_t current_time_ms()
{
struct timespec ts;
if (clock_gettime(CLOCK_MONOTONIC, &ts))
fail("clock_gettime failed");
return (uint64_t)ts.tv_sec * 1000 + (uint64_t)ts.tv_nsec / 1000000;
}
static void test();
void loop()
{
int iter;
for (iter = 0;; iter++) {
char cwdbuf[256];
sprintf(cwdbuf, "./%d", iter);
if (mkdir(cwdbuf, 0777))
fail("failed to mkdir");
int pid = fork();
if (pid < 0)
fail("clone failed");
if (pid == 0) {
prctl(PR_SET_PDEATHSIG, SIGKILL, 0, 0, 0);
setpgrp();
if (chdir(cwdbuf))
fail("failed to chdir");
test();
exit(0);
}
int status = 0;
uint64_t start = current_time_ms();
for (;;) {
int res = waitpid(pid, &status, __WALL | WNOHANG);
int errno0 = errno;
if (res == pid)
break;
usleep(1000);
if (current_time_ms() - start > 5 * 1000) {
kill(-pid, SIGKILL);
kill(pid, SIGKILL);
waitpid(pid, &status, __WALL);
break;
}
}
remove_dir(cwdbuf);
}
}
long r[7];
void* thr(void* arg)
{
switch ((long)arg) {
case 0:
r[0] =
execute_syscall(__NR_mmap, 0x20000000ul, 0xe43000ul, 0x3ul,
0x32ul, 0xfffffffffffffffful, 0x0ul, 0, 0, 0);
break;
case 1:
r[1] = execute_syscall(__NR_socket, 0x10ul, 0x3ul, 0x0ul, 0, 0, 0,
0, 0, 0);
break;
case 2:
NONFAILING(memcpy((void*)0x20e42fe1,
"\x1f\x00\x00\x00\x1a\x00\x03\xf2\x00\x00\x13\xff"
"\x07\x00\x00\x77\x00\x00\xff\xff\xff\x7f\xd8\x00"
"\x00\x00\x00\x00\x00\x00\x34",
31));
r[3] = execute_syscall(__NR_write, r[1], 0x20e42fe1ul, 0x1ful, 0, 0,
0, 0, 0, 0);
break;
case 3:
NONFAILING(*(uint64_t*)0x20e41000 = (uint64_t)0x20e3ef11);
NONFAILING(*(uint64_t*)0x20e41008 = (uint64_t)0x1);
r[6] = execute_syscall(__NR_readv, r[1], 0x20e41000ul, 0x1ul, 0, 0,
0, 0, 0, 0);
break;
}
return 0;
}
void test()
{
long i;
pthread_t th[8];
memset(r, -1, sizeof(r));
srand(getpid());
for (i = 0; i < 4; i++) {
pthread_create(&th[i], 0, thr, (void*)i);
usleep(10000);
}
usleep(100000);
}
int main()
{
setup_main_process(0, false);
int pid = do_sandbox_none();
int status = 0;
while (waitpid(pid, &status, __WALL) != pid) {
}
return 0;
}
^ 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
* 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: 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 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 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] 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: 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
* [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
* (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
* 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
* [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: 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: 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
* 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
* 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
* 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: 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
* 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
* [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
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