* [PATCH RFC ipsec-next 0/3] Virtual xfrm interfaces
From: Steffen Klassert @ 2018-06-04 6:09 UTC (permalink / raw)
To: netdev
Cc: Steffen Klassert, Eyal Birger, Antony Antony, Benedict Wong,
Lorenzo Colitti, Shannon Nelson
This patchset introduces new virtual xfrm interfaces.
The design of virtual xfrm interfaces interfaces was
discussed at the Linux IPsec workshop 2018. This patchset
implements these interfaces as the IPsec userspace and
kernel developers agreed. The purpose of these interfaces
is to overcome the design limitations that the existing
VTI devices have.
We had two presentations about xfrm interfaces at
the workshop. Slides with further informations
can be found at the workshop homepage:
https://workshop.linux-ipsec.org/2018/
^ permalink raw reply
* [PATCH RFC ipsec-next 1/3] flow: Extend flow informations with xfrm interface id.
From: Steffen Klassert @ 2018-06-04 6:09 UTC (permalink / raw)
To: netdev
Cc: Steffen Klassert, Eyal Birger, Antony Antony, Benedict Wong,
Lorenzo Colitti, Shannon Nelson
In-Reply-To: <20180604060910.13896-1-steffen.klassert@secunet.com>
Add a new flowi_xfrm structure with informations needed to do
a xfrm lookup. At the moment it keeps the informations about
the xfrm interface id.
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Acked-by: Shannon Nelson <shannon.nelson@oracle.com>
Acked-by: Benedict Wong <benedictwong@google.com>
Tested-by: Benedict Wong <benedictwong@google.com>
Tested-by: Antony Antony <antony@phenome.org>
Reviewed-by: Eyal Birger <eyal.birger@gmail.com>
---
include/net/flow.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/include/net/flow.h b/include/net/flow.h
index 8ce21793094e..187c9bef672f 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -26,6 +26,10 @@ struct flowi_tunnel {
__be64 tun_id;
};
+struct flowi_xfrm {
+ __u32 if_id;
+};
+
struct flowi_common {
int flowic_oif;
int flowic_iif;
@@ -39,6 +43,7 @@ struct flowi_common {
#define FLOWI_FLAG_SKIP_NH_OIF 0x04
__u32 flowic_secid;
struct flowi_tunnel flowic_tun_key;
+ struct flowi_xfrm xfrm;
kuid_t flowic_uid;
};
@@ -78,6 +83,7 @@ struct flowi4 {
#define flowi4_secid __fl_common.flowic_secid
#define flowi4_tun_key __fl_common.flowic_tun_key
#define flowi4_uid __fl_common.flowic_uid
+#define flowi4_xfrm __fl_common.xfrm
/* (saddr,daddr) must be grouped, same order as in IP header */
__be32 saddr;
@@ -109,6 +115,7 @@ static inline void flowi4_init_output(struct flowi4 *fl4, int oif,
fl4->flowi4_flags = flags;
fl4->flowi4_secid = 0;
fl4->flowi4_tun_key.tun_id = 0;
+ fl4->flowi4_xfrm.if_id = 0;
fl4->flowi4_uid = uid;
fl4->daddr = daddr;
fl4->saddr = saddr;
@@ -138,6 +145,7 @@ struct flowi6 {
#define flowi6_secid __fl_common.flowic_secid
#define flowi6_tun_key __fl_common.flowic_tun_key
#define flowi6_uid __fl_common.flowic_uid
+#define flowi6_xfrm __fl_common.xfrm
struct in6_addr daddr;
struct in6_addr saddr;
/* Note: flowi6_tos is encoded in flowlabel, too. */
@@ -185,6 +193,7 @@ struct flowi {
#define flowi_secid u.__fl_common.flowic_secid
#define flowi_tun_key u.__fl_common.flowic_tun_key
#define flowi_uid u.__fl_common.flowic_uid
+#define flowi_xfrm u.__fl_common.xfrm
} __attribute__((__aligned__(BITS_PER_LONG/8)));
static inline struct flowi *flowi4_to_flowi(struct flowi4 *fl4)
--
2.14.1
^ permalink raw reply related
* 答复: ANNOUNCE: Enhanced IP v1.4
From: PKU.孙斌 @ 2018-06-04 5:58 UTC (permalink / raw)
To: 'Willy Tarreau', 'Eric Dumazet'
Cc: 'Linux Kernel Network Developers'
In-Reply-To: <20180604043426.GB11775@1wt.eu>
On Sun, Jun 03, 2018 at 03:41:08PM -0700, Eric Dumazet wrote:
>
>
> On 06/03/2018 01:37 PM, Tom Herbert wrote:
>
> > This is not an inconsequential mechanism that is being proposed. It's
> > a modification to IP protocol that is intended to work on the
> > Internet, but it looks like the draft hasn't been updated for two
> > years and it is not adopted by any IETF working group. I don't see how
> > this can go anywhere without IETF support. Also, I suggest that you
> > look at the IPv10 proposal since that was very similar in intent. One
> > of the reasons that IPv10 shot down was because protocol transition
> > mechanisms were more interesting ten years ago than today. IPv6 has
> > good traction now. In fact, it's probably the case that it's now
> > easier to bring up IPv6 than to try to make IPv4 options work over the
> > Internet.
>
> +1
>
> Many hosts do not use IPv4 anymore.
>
> We even have the project making IPv4 support in linux optional.
I guess then Linux kernel wouldn't be able to boot itself without IPv4 built in, e.g., when we only have old L2 links (without the IPv6 frame type)...
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in bpf_csum_update
From: Dmitry Vyukov @ 2018-06-04 5:36 UTC (permalink / raw)
To: syzbot
Cc: Alexei Starovoitov, Daniel Borkmann, David Miller, LKML, netdev,
syzkaller-bugs
In-Reply-To: <000000000000b2a7ea056dc54779@google.com>
On Mon, Jun 4, 2018 at 1:36 AM, syzbot
<syzbot+efae31b384d5badbd620@syzkaller.appspotmail.com> wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 0512e0134582 Merge tag 'xfs-4.17-fixes-3' of git://git.ker..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=17eb2d7b800000
> kernel config: https://syzkaller.appspot.com/x/.config?x=968b0b23c7854c0b
> dashboard link: https://syzkaller.appspot.com/bug?extid=efae31b384d5badbd620
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=162c6def800000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14fe3db7800000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+efae31b384d5badbd620@syzkaller.appspotmail.com
>
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in ____bpf_csum_update net/core/filter.c:1679
> [inline]
> BUG: KASAN: slab-out-of-bounds in bpf_csum_update+0xb4/0xc0
> net/core/filter.c:1673
> Read of size 1 at addr ffff8801d9235b50 by task syz-executor507/4513
>
> CPU: 0 PID: 4513 Comm: syz-executor507 Not tainted 4.17.0-rc7+ #78
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1b9/0x294 lib/dump_stack.c:113
> print_address_description+0x6c/0x20b mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
> __asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
> ____bpf_csum_update net/core/filter.c:1679 [inline]
> bpf_csum_update+0xb4/0xc0 net/core/filter.c:1673
/\/\/\/\/\
Are there any known bugs with unwind through bpf functions?
> Allocated by task 0:
> (stack is not available)
>
> Freed by task 0:
> (stack is not available)
>
> The buggy address belongs to the object at ffff8801d9235a40
> which belongs to the cache skbuff_head_cache of size 232
> The buggy address is located 40 bytes to the right of
> 232-byte region [ffff8801d9235a40, ffff8801d9235b28)
> The buggy address belongs to the page:
> page:ffffea0007648d40 count:1 mapcount:0 mapping:ffff8801d9235040 index:0x0
> flags: 0x2fffc0000000100(slab)
> raw: 02fffc0000000100 ffff8801d9235040 0000000000000000 000000010000000c
> raw: ffffea00074360a0 ffff8801d944d848 ffff8801d9bdd6c0 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801d9235a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801d9235a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>>
>> ffff8801d9235b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>
> ^
> ffff8801d9235b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801d9235c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/000000000000b2a7ea056dc54779%40google.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: ANNOUNCE: Enhanced IP v1.4
From: Willy Tarreau @ 2018-06-04 4:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Herbert, Sam Patton, Linux Kernel Network Developers
In-Reply-To: <b70e6448-8d34-1d18-0ec0-10e803f489b5@gmail.com>
On Sun, Jun 03, 2018 at 03:41:08PM -0700, Eric Dumazet wrote:
>
>
> On 06/03/2018 01:37 PM, Tom Herbert wrote:
>
> > This is not an inconsequential mechanism that is being proposed. It's
> > a modification to IP protocol that is intended to work on the
> > Internet, but it looks like the draft hasn't been updated for two
> > years and it is not adopted by any IETF working group. I don't see how
> > this can go anywhere without IETF support. Also, I suggest that you
> > look at the IPv10 proposal since that was very similar in intent. One
> > of the reasons that IPv10 shot down was because protocol transition
> > mechanisms were more interesting ten years ago than today. IPv6 has
> > good traction now. In fact, it's probably the case that it's now
> > easier to bring up IPv6 than to try to make IPv4 options work over the
> > Internet.
>
> +1
>
> Many hosts do not use IPv4 anymore.
>
> We even have the project making IPv4 support in linux optional.
I agree on these points, but I'd like to figure what can be done to put
a bit more pressure on ISPs to *always* provide IPv6. It's still very
hard to have decent connectivity at home and without this it will continue
to be marginalize.
I do have IPv6 at home (a /48, waste of addressing space, I'd be fine
with less), there's none at work (I don't even know if the ISP supports
it, at least it was never ever mentioned so probably they don't know
about this), and some ISPs only provide a /64 which is as ridiculous
as providing a single address as it forces the end user to NAT thus
breaking the end-to-end principle. Ideally with IoT at the door, every
home connection should have at least a /60 and enterprises should have
a /56, and this by default, without having to request anything.
Maybe setting up a public list of ISPs where users don't have at least
a /60 by default could help, but I suspect that most of them will
consider that as long as their competitors are on the list there's no
emergency.
Willy
^ permalink raw reply
* Re: [PATCH] NFC: fix attrs checks in netlink interface
From: Samuel Ortiz @ 2018-06-04 4:29 UTC (permalink / raw)
To: Andrey Konovalov
Cc: David S . Miller, linux-wireless, netdev, linux-kernel,
Dmitry Vyukov, Kostya Serebryany
In-Reply-To: <75ce3040b4086ffa2d2e088ad7f24f5e4a87be56.1523552145.git.andreyknvl@google.com>
Hi Andrey,
On Thu, Apr 12, 2018 at 06:56:56PM +0200, Andrey Konovalov wrote:
> nfc_genl_deactivate_target() relies on the NFC_ATTR_TARGET_INDEX
> attribute being present, but doesn't check whether it is actually
> provided by the user. Same goes for nfc_genl_fw_download() and
> NFC_ATTR_FIRMWARE_NAME.
>
> This patch adds appropriate checks.
>
> Found with syzkaller.
>
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> ---
> net/nfc/netlink.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
Thanks, applied to nfc-next.
Cheers,
Samuel.
^ permalink raw reply
* Re: [PATCH 04/18] rhashtable: detect when object movement might have invalidated a lookup
From: NeilBrown @ 2018-06-04 3:38 UTC (permalink / raw)
To: Herbert Xu
Cc: Thomas Graf, netdev, linux-kernel, Eric Dumazet, David S. Miller
In-Reply-To: <20180601160613.7ud25g2ux55k3bma@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]
On Sat, Jun 02 2018, Herbert Xu wrote:
> On Fri, Jun 01, 2018 at 02:44:09PM +1000, NeilBrown wrote:
>> Some users of rhashtable might need to change the key
>> of an object and move it to a different location in the table.
>> Other users might want to allocate objects using
>> SLAB_TYPESAFE_BY_RCU which can result in the same memory allocation
>> being used for a different (type-compatible) purpose and similarly
>> end up in a different hash-chain.
>>
>> To support these, we store a unique NULLS_MARKER at the end of
>> each chain, and when a search fails to find a match, we check
>> if the NULLS marker found was the expected one. If not,
>> the search is repeated.
>>
>> The unique NULLS_MARKER is derived from the address of the
>> head of the chain.
>
> Yes I thinks makes a lot more sense than the existing rhashtable
> nulls code. The current rhashtable nulls code harkens back to the
> time of the old rhashtable implementation where the same chain
> existed in two different tables and that is no longer the case.
>
>> If an object is removed and re-added to the same hash chain, we won't
>> notice by looking that the NULLS marker. In this case we must be sure
>
> This is not currently required by TCP/UDP. I'd rather not add
> extra constraints that aren't actually used.
I assume you are referring here to the change to insert at the head of
the chain, rather than at the end.
This is important for me to be able to use SLAB_TYPESAFE_BY_RCU
for the kmem_cache. Without that, I need a new rcu-free callback
for every different kmem_cache.
When using SLAB_TYPESAFE_BY_RCU, there is no way to know where
a freed and re-allocated object might be used again - it could
be used in the same table with the same hash value.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* [PATCH 15a/18] rhashtables: add lockdep tracking to bucket bit-spin-locks.
From: NeilBrown @ 2018-06-04 2:52 UTC (permalink / raw)
To: Eric Dumazet, Herbert Xu
Cc: Thomas Graf, netdev, linux-kernel, Eric Dumazet, David S. Miller
In-Reply-To: <871sdnqty4.fsf@notabene.neil.brown.name>
[-- Attachment #1: Type: text/plain, Size: 6838 bytes --]
Native bit_spin_locks are not tracked by lockdep.
The bit_spin_locks used for rhashtable buckets are local
to the rhashtable implementation, so there is little opportunity
for the sort of misuse that lockdep might detect.
However locks are held while a hash function or compare
function is called, and if one of these took a lock,
a misbehaviour is possible.
As it is quite easy to add lockdep support this unlikely
possibility see to be enough justification.
So create a lockdep class for bucket bit_spin_lock as attach
through a lockdep_map in each bucket_table.
With the 'nested' annotation in rhashtable_rehash_one(), lockdep
correctly reports a possible problem as this lock it taken
while another bucket lock (in another table) is held. This
confirms that the added support works.
With the correct nested annotation in place, lockdep reports
no problems.
Signed-off-by: NeilBrown <neilb@suse.com>
---
include/linux/rhashtable.h | 40 +++++++++++++++++++++++++++-------------
lib/rhashtable.c | 17 ++++++++++-------
2 files changed, 37 insertions(+), 20 deletions(-)
diff --git a/include/linux/rhashtable.h b/include/linux/rhashtable.h
index 42b5d037ad2e..b12c2cd30a56 100644
--- a/include/linux/rhashtable.h
+++ b/include/linux/rhashtable.h
@@ -70,6 +70,8 @@ struct bucket_table {
struct bucket_table __rcu *future_tbl;
+ struct lockdep_map dep_map;
+
struct rhash_head __rcu *buckets[] ____cacheline_aligned_in_smp;
};
@@ -90,20 +92,32 @@ struct bucket_table {
* will have provided that.
*/
-static inline void rht_lock(struct rhash_head **bucket)
+static inline void rht_lock(struct bucket_table *tbl, struct rhash_head **bucket)
+{
+ local_bh_disable();
+ bit_spin_lock(1, (unsigned long *)bucket);
+ lock_map_acquire(&tbl->dep_map);
+}
+
+static inline void rht_lock_nested(struct bucket_table *tbl,
+ struct rhash_head **bucket,
+ unsigned int subclass)
{
local_bh_disable();
bit_spin_lock(1, (unsigned long *)bucket);
+ lock_acquire_exclusive(&tbl->dep_map, subclass, 0, NULL, _THIS_IP_);
}
-static inline void rht_unlock(struct rhash_head **bucket)
+static inline void rht_unlock(struct bucket_table *tbl, struct rhash_head **bucket)
{
+ lock_map_release(&tbl->dep_map);
bit_spin_unlock(1, (unsigned long *)bucket);
local_bh_enable();
}
-static inline void rht_unlocked(void)
+static inline void rht_unlocked(struct bucket_table *tbl)
{
+ lock_map_release(&tbl->dep_map);
preempt_enable();
__release(bitlock);
local_bh_enable();
@@ -742,11 +756,11 @@ static inline void *__rhashtable_insert_fast(
if (!headp)
goto out;
lock = pprev = headp;
- rht_lock(lock);
+ rht_lock(tbl, lock);
if (unlikely(rcu_access_pointer(tbl->future_tbl))) {
slow_path:
- rht_unlock(lock);
+ rht_unlock(tbl, lock);
rcu_read_unlock();
return rhashtable_insert_slow(ht, key, obj);
}
@@ -825,10 +839,10 @@ static inline void *__rhashtable_insert_fast(
/* Assigning to *headp unlocked the chain, so we
* don't need to do it again.
*/
- rht_unlocked();
+ rht_unlocked(tbl);
} else {
out:
- rht_unlock(lock);
+ rht_unlock(tbl, lock);
}
rcu_read_unlock();
@@ -1033,7 +1047,7 @@ static inline int __rhashtable_remove_fast_one(
if (!pprev)
return -ENOENT;
lock = pprev;
- rht_lock(lock);
+ rht_lock(tbl, lock);
rht_for_each_from(he, rht_ptr(*pprev), tbl, hash) {
struct rhlist_head *list;
@@ -1078,13 +1092,13 @@ static inline int __rhashtable_remove_fast_one(
rcu_assign_pointer(*pprev, obj);
if (lock == pprev) {
/* That rcu_assign_pointer() unlocked the chain */
- rht_unlocked();
+ rht_unlocked(tbl);
goto unlocked;
}
break;
}
- rht_unlock(lock);
+ rht_unlock(tbl, lock);
unlocked:
if (err > 0) {
if (params.percpu_count)
@@ -1195,7 +1209,7 @@ static inline int __rhashtable_replace_fast(
return -ENOENT;
lock = pprev;
- rht_lock(lock);
+ rht_lock(tbl, lock);
rht_for_each_from(he, rht_ptr(*pprev), tbl, hash) {
if (he != obj_old) {
@@ -1208,13 +1222,13 @@ static inline int __rhashtable_replace_fast(
err = 0;
if (pprev == lock) {
/* We just unlocked the chain by assigning to *pprev */
- rht_unlocked();
+ rht_unlocked(tbl);
goto unlocked;
}
break;
}
- rht_unlock(lock);
+ rht_unlock(tbl, lock);
unlocked:
return err;
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index aa1e7be8fc5b..1fc235f5d04e 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -174,6 +174,7 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht,
struct bucket_table *tbl = NULL;
size_t size;
int i;
+ static struct lock_class_key __key;
size = sizeof(*tbl) + nbuckets * sizeof(tbl->buckets[0]);
if (gfp != GFP_KERNEL)
@@ -190,6 +191,8 @@ static struct bucket_table *bucket_table_alloc(struct rhashtable *ht,
if (tbl == NULL)
return NULL;
+ lockdep_init_map(&tbl->dep_map, "rhashtable_bucket", &__key, 0);
+
tbl->size = size;
INIT_LIST_HEAD(&tbl->walkers);
@@ -249,7 +252,7 @@ static int rhashtable_rehash_one(struct rhashtable *ht,
inspos = &new_tbl->buckets[new_hash];
lock = inspos;
- rht_lock(lock);
+ rht_lock_nested(new_tbl, lock, SINGLE_DEPTH_NESTING);
head = rht_ptr(rht_dereference_bucket(*inspos, new_tbl, new_hash));
while (!rht_is_a_nulls(head) && head < entry) {
@@ -260,9 +263,9 @@ static int rhashtable_rehash_one(struct rhashtable *ht,
rcu_assign_pointer(*inspos, entry);
if (inspos != lock)
- rht_unlock(lock);
+ rht_unlock(new_tbl, lock);
else
- rht_unlocked();
+ rht_unlocked(new_tbl);
/* Need to preserved the bit lock. */
if (rht_is_locked(*pprev))
@@ -283,14 +286,14 @@ static int rhashtable_rehash_chain(struct rhashtable *ht,
if (!pprev)
return 0;
- rht_lock(pprev);
+ rht_lock(old_tbl, pprev);
while (!(err = rhashtable_rehash_one(ht, pprev, old_hash)))
;
if (err == -ENOENT)
err = 0;
- rht_unlock(pprev);
+ rht_unlock(old_tbl, pprev);
return err;
}
@@ -658,7 +661,7 @@ static void *rhashtable_try_insert(struct rhashtable *ht, const void *key,
new_tbl = rht_dereference_rcu(tbl->future_tbl, ht);
data = ERR_PTR(-EAGAIN);
} else {
- rht_lock(pprev);
+ rht_lock(tbl, pprev);
data = rhashtable_lookup_one(ht, pprev, tbl,
hash, key, obj);
new_tbl = rhashtable_insert_one(ht, pprev, tbl,
@@ -666,7 +669,7 @@ static void *rhashtable_try_insert(struct rhashtable *ht, const void *key,
if (PTR_ERR(new_tbl) != -EEXIST)
data = ERR_CAST(new_tbl);
- rht_unlock(pprev);
+ rht_unlock(tbl, pprev);
}
} while (!IS_ERR_OR_NULL(new_tbl));
--
2.14.0.rc0.dirty
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply related
* Re: [PATCH net] net: ipv6: prevent use after free in ip6_route_mpath_notify()
From: Eric Dumazet @ 2018-06-04 2:39 UTC (permalink / raw)
To: David Ahern, Eric Dumazet, David S . Miller; +Cc: netdev
In-Reply-To: <26bd52c0-1218-3c65-95ca-b2a908466841@cumulusnetworks.com>
On 06/03/2018 07:46 AM, David Ahern wrote:
> It was a mistake to set rt_last before checking err. So the
> use-after-free exposed the semantic error.
>
SGTM, please send the formal patch then, thanks !
^ permalink raw reply
* Re: [PATCH 10/18] rhashtable: remove rhashtable_walk_peek()
From: NeilBrown @ 2018-06-04 2:09 UTC (permalink / raw)
To: Tom Herbert
Cc: Herbert Xu, Thomas Graf, Linux Kernel Network Developers, LKML,
Tom Herbert
In-Reply-To: <CALx6S37AYrFoJNrdToRc84J=B4f57jaHS077UsxdEoQ-xwyCeg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4320 bytes --]
On Sun, Jun 03 2018, Tom Herbert wrote:
> On Sun, Jun 3, 2018 at 5:30 PM, NeilBrown <neilb@suse.com> wrote:
>> On Sat, Jun 02 2018, Herbert Xu wrote:
>>
>>> On Fri, Jun 01, 2018 at 02:44:09PM +1000, NeilBrown wrote:
>>>> This function has a somewhat confused behavior that is not properly
>>>> described by the documentation.
>>>> Sometimes is returns the previous object, sometimes it returns the
>>>> next one.
>>>> Sometimes it changes the iterator, sometimes it doesn't.
>>>>
>>>> This function is not currently used and is not worth keeping, so
>>>> remove it.
>>>>
>>>> A future patch will introduce a new function with a
>>>> simpler interface which can meet the same need that
>>>> this was added for.
>>>>
>>>> Signed-off-by: NeilBrown <neilb@suse.com>
>>>
>>> Please keep Tom Herbert in the loop. IIRC he had an issue with
>>> this patch.
>>
>> Yes you are right - sorry for forgetting to add Tom.
>>
>> My understanding of where this issue stands is that Tom raised issue and
>> asked for clarification, I replied, nothing further happened.
>>
>> It summary, my position is that:
>> - most users of my new rhashtable_walk_prev() will use it like
>> rhasthable_talk_prev() ?: rhashtable_walk_next()
>> which is close to what rhashtable_walk_peek() does
>> - I know of no use-case that could not be solved if we only had
>> the combined operation
>> - BUT it is hard to document the combined operation, as it really
>> does two things. If it is hard to document, then it might be
>> hard to understand.
>>
>> So provide the most understandable/maintainable solution, I think
>> we should provide rhashtable_walk_prev() as a separate interface.
>>
> I'm still missing why requiring two API operations instead of one is
> simpler or easier to document. Also, I disagree that
> rhashtable_walk_peek does two things-- it just does one which is to
> return the current element in the walk without advancing to the next
> one. The fact that the iterator may or may not move is immaterial in
> the API, that is an implementation detail. In fact, it's conceivable
> that we might completely reimplement this someday such that the
> iterator works completely differently implementation semantics but the
> API doesn't change. Also the naming in your proposal is confusing,
> we'd have operations to get the previous, and the next next object--
> so the user may ask where's the API to get the current object in the
> walk? The idea that we get it by first trying to get the previous
> object, and then if that fails getting the next object seems
> counterintuitive.
To respond to your points out of order:
- I accept that "rhashtable_walk_prev" is not a perfect name. It
suggests a stronger symmetry with rhasthable_walk_next than actually
exist. I cannot think of a better name, but I think the
description "Return the previously returned object if it is
still in the table" is clear and simple and explains the name.
I'm certainly open to suggestions for a better name.
- I don't think it is meaningful to talk about a "current" element in a
table where asynchronous insert/remove is to be expected.
The best we can hope for is a "current location" is the sequence of
objects in the table - a location which is after some objects and
before all others. rhashtable_walk_next() returns the next object
after the current location, and advances the location pointer past
that object.
rhashtable_walk_prev() *doesn't* return the previous object in the
table. It returns the previously returned object. ("previous" in
time, but not in space, if you like).
- rhashtable_walk_peek() currently does one of two different things.
It either returns the previously returned object (iter->p) if that
is still in the table, or it find the next object, steps over it, and
returns it.
- I would like to suggest that when an API acts on a iterator object,
the question of whether or not the iterator is advanced *must* be a
fundamental question, not one that might change from time to time.
Maybe a useful way forward would be for you to write documentation for
the rhashtable_walk_peek() interface which correctly describes what it
does and how it is used. Given that, I can implement that interface
with the stability improvements that I'm working on.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: flowlabel in bpf_fib_lookup should be flowinfo
From: Alexei Starovoitov @ 2018-06-04 1:48 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, borkmann, ast, Michal Kubecek
In-Reply-To: <32d91faa-a963-43f5-1dea-8f238abc434c@gmail.com>
On Sun, Jun 03, 2018 at 07:47:11PM -0600, David Ahern wrote:
> On 6/3/18 7:41 PM, Alexei Starovoitov wrote:
> > On Sun, Jun 03, 2018 at 08:15:19AM -0700, dsahern@kernel.org wrote:
> >> From: David Ahern <dsahern@gmail.com>
> >>
> >> As Michal noted the flow struct takes both the flow label and priority.
> >> Update the bpf_fib_lookup API to note that it is flowinfo and not just
> >> the flow label.
> >>
> >> Cc: Michal Kubecek <mkubecek@suse.cz>
> >> Signed-off-by: David Ahern <dsahern@gmail.com>
> >
> > Applied, Thanks
> >
>
> I noticed 4.17 was released. Just to make sure we are on the same page,
> this patch needs to be 4.18.
It was applied to bpf-next obviously.
As soon as we resolve the situation with af_xdp the PR will be sent to Dave
for net-next, so net-next can be sent to Linus.
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: flowlabel in bpf_fib_lookup should be flowinfo
From: David Ahern @ 2018-06-04 1:47 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: netdev, borkmann, ast, Michal Kubecek
In-Reply-To: <20180604014118.5nazn4s43443esio@ast-mbp>
On 6/3/18 7:41 PM, Alexei Starovoitov wrote:
> On Sun, Jun 03, 2018 at 08:15:19AM -0700, dsahern@kernel.org wrote:
>> From: David Ahern <dsahern@gmail.com>
>>
>> As Michal noted the flow struct takes both the flow label and priority.
>> Update the bpf_fib_lookup API to note that it is flowinfo and not just
>> the flow label.
>>
>> Cc: Michal Kubecek <mkubecek@suse.cz>
>> Signed-off-by: David Ahern <dsahern@gmail.com>
>
> Applied, Thanks
>
I noticed 4.17 was released. Just to make sure we are on the same page,
this patch needs to be 4.18.
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: flowlabel in bpf_fib_lookup should be flowinfo
From: Alexei Starovoitov @ 2018-06-04 1:41 UTC (permalink / raw)
To: dsahern; +Cc: netdev, borkmann, ast, David Ahern, Michal Kubecek
In-Reply-To: <20180603151519.10205-1-dsahern@kernel.org>
On Sun, Jun 03, 2018 at 08:15:19AM -0700, dsahern@kernel.org wrote:
> From: David Ahern <dsahern@gmail.com>
>
> As Michal noted the flow struct takes both the flow label and priority.
> Update the bpf_fib_lookup API to note that it is flowinfo and not just
> the flow label.
>
> Cc: Michal Kubecek <mkubecek@suse.cz>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied, Thanks
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] bpf: implement bpf_get_current_cgroup_id() helper
From: Alexei Starovoitov @ 2018-06-04 1:27 UTC (permalink / raw)
To: Yonghong Song; +Cc: ast, daniel, netdev, kernel-team
In-Reply-To: <20180603225943.2370719-1-yhs@fb.com>
On Sun, Jun 03, 2018 at 03:59:40PM -0700, Yonghong Song wrote:
> bpf has been used extensively for tracing. For example, bcc
> contains an almost full set of bpf-based tools to trace kernel
> and user functions/events. Most tracing tools are currently
> either filtered based on pid or system-wide.
>
> Containers have been used quite extensively in industry and
> cgroup is often used together to provide resource isolation
> and protection. Several processes may run inside the same
> container. It is often desirable to get container-level tracing
> results as well, e.g. syscall count, function count, I/O
> activity, etc.
>
> This patch implements a new helper, bpf_get_current_cgroup_id(),
> which will return cgroup id based on the cgroup within which
> the current task is running.
>
> Patch #1 implements the new helper in the kernel.
> Patch #2 syncs the uapi bpf.h header and helper between tools
> and kernel.
> Patch #3 shows how to get the same cgroup id in user space,
> so a filter or policy could be configgured in the bpf program
> based on current task cgroup.
>
> Changelog:
> v1 -> v2:
> . rebase to resolve merge conflict with latest bpf-next.
Applied, Thanks.
^ permalink raw reply
* Re: [PATCH 10/18] rhashtable: remove rhashtable_walk_peek()
From: Tom Herbert @ 2018-06-04 1:18 UTC (permalink / raw)
To: NeilBrown
Cc: Herbert Xu, Thomas Graf, Linux Kernel Network Developers, LKML,
Tom Herbert
In-Reply-To: <87y3fvpf40.fsf@notabene.neil.brown.name>
On Sun, Jun 3, 2018 at 5:30 PM, NeilBrown <neilb@suse.com> wrote:
> On Sat, Jun 02 2018, Herbert Xu wrote:
>
>> On Fri, Jun 01, 2018 at 02:44:09PM +1000, NeilBrown wrote:
>>> This function has a somewhat confused behavior that is not properly
>>> described by the documentation.
>>> Sometimes is returns the previous object, sometimes it returns the
>>> next one.
>>> Sometimes it changes the iterator, sometimes it doesn't.
>>>
>>> This function is not currently used and is not worth keeping, so
>>> remove it.
>>>
>>> A future patch will introduce a new function with a
>>> simpler interface which can meet the same need that
>>> this was added for.
>>>
>>> Signed-off-by: NeilBrown <neilb@suse.com>
>>
>> Please keep Tom Herbert in the loop. IIRC he had an issue with
>> this patch.
>
> Yes you are right - sorry for forgetting to add Tom.
>
> My understanding of where this issue stands is that Tom raised issue and
> asked for clarification, I replied, nothing further happened.
>
> It summary, my position is that:
> - most users of my new rhashtable_walk_prev() will use it like
> rhasthable_talk_prev() ?: rhashtable_walk_next()
> which is close to what rhashtable_walk_peek() does
> - I know of no use-case that could not be solved if we only had
> the combined operation
> - BUT it is hard to document the combined operation, as it really
> does two things. If it is hard to document, then it might be
> hard to understand.
>
> So provide the most understandable/maintainable solution, I think
> we should provide rhashtable_walk_prev() as a separate interface.
>
I'm still missing why requiring two API operations instead of one is
simpler or easier to document. Also, I disagree that
rhashtable_walk_peek does two things-- it just does one which is to
return the current element in the walk without advancing to the next
one. The fact that the iterator may or may not move is immaterial in
the API, that is an implementation detail. In fact, it's conceivable
that we might completely reimplement this someday such that the
iterator works completely differently implementation semantics but the
API doesn't change. Also the naming in your proposal is confusing,
we'd have operations to get the previous, and the next next object--
so the user may ask where's the API to get the current object in the
walk? The idea that we get it by first trying to get the previous
object, and then if that fails getting the next object seems
counterintuitive.
Tom
Tom
> Thanks,
> NeilBronw
^ permalink raw reply
* Re: [PATCH iproute2] iplink_vrf: Save device index from response for return code
From: Hangbin Liu @ 2018-06-04 1:11 UTC (permalink / raw)
To: dsahern; +Cc: stephen, netdev, David Ahern, Phil Sutter
In-Reply-To: <20180601155016.3524-1-dsahern@kernel.org>
On Fri, Jun 01, 2018 at 08:50:16AM -0700, dsahern@kernel.org wrote:
> From: David Ahern <dsahern@gmail.com>
>
> A recent commit changed rtnl_talk_* to return the response message in
> allocated memory so callers need to free it. The change to name_is_vrf
> did not save the device index which is pointing to a struct inside the
> now allocated and freed memory resulting in garbage getting returned
> in some cases.
>
> Fix by using a stack variable to save the return value and only set
> it to ifi->ifi_index after all checks are done and before the answer
> buffer is freed.
>
> Fixes: 86bf43c7c2fdc ("lib/libnetlink: update rtnl_talk to support malloc buff at run time")
> Cc: Hangbin Liu <liuhangbin@gmail.com>
> Cc: Phil Sutter <phil@nwl.cc>
> Signed-off-by: David Ahern <dsahern@gmail.com>
> ---
> ip/iplink_vrf.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/ip/iplink_vrf.c b/ip/iplink_vrf.c
> index e9dd0df98412..6004bb4f305e 100644
> --- a/ip/iplink_vrf.c
> +++ b/ip/iplink_vrf.c
> @@ -191,6 +191,7 @@ int name_is_vrf(const char *name)
> struct rtattr *tb[IFLA_MAX+1];
> struct rtattr *li[IFLA_INFO_MAX+1];
> struct ifinfomsg *ifi;
> + int ifindex = 0;
> int len;
>
> addattr_l(&req.n, sizeof(req), IFLA_IFNAME, name, strlen(name) + 1);
> @@ -218,7 +219,8 @@ int name_is_vrf(const char *name)
> if (strcmp(RTA_DATA(li[IFLA_INFO_KIND]), "vrf"))
> goto out;
>
> + ifindex = ifi->ifi_index;
> out:
> free(answer);
> - return ifi->ifi_index;
> + return ifindex;
> }
> --
> 2.11.0
>
Thanks for the fix.
Acked-by: Hangbin Liu <liuhangbin@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next] netfilter: fix null-ptr-deref in nf_nat_decode_session
From: Prashant Bhole @ 2018-06-04 1:10 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Florian Westphal, David S . Miller, Jozsef Kadlecsik, netdev,
netfilter-devel
In-Reply-To: <20180528105249.36pvoyo5loqjjmsa@breakpoint.cc>
CC netfilter-devel
On 5/28/2018 7:52 PM, Florian Westphal wrote:
> Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> wrote:
>> Add null check for nat_hook in nf_nat_decode_session()
>
> Acked-by: Florian Westphal <fw@strlen.de>
Hi Pablo,
Just pinging in case this patch was missed.
-Prashant
^ permalink raw reply
* Re: [PATCH v5 net] stmmac: 802.1ad tag stripping fix
From: Toshiaki Makita @ 2018-06-04 0:49 UTC (permalink / raw)
To: David Miller, eladv6
Cc: Jose.Abreu, f.fainelli, netdev, peppe.cavallaro, alexandre.torgue
In-Reply-To: <20180603.103313.1827081859745223157.davem@davemloft.net>
On 2018/06/03 23:33, David Miller wrote:
> From: Elad Nachman <eladv6@gmail.com>
> Date: Wed, 30 May 2018 08:48:25 +0300
>
>> static void stmmac_rx_vlan(struct net_device *dev, struct sk_buff *skb)
>> {
>> - struct ethhdr *ehdr;
>> + struct vlan_ethhdr *veth;
>> u16 vlanid;
>> + __be16 vlan_proto;
>
> Please order local variables from longest to shortest line.
>
>>
>> - if ((dev->features & NETIF_F_HW_VLAN_CTAG_RX) ==
>> - NETIF_F_HW_VLAN_CTAG_RX &&
>> - !__vlan_get_tag(skb, &vlanid)) {
>> + if (!__vlan_get_tag(skb, &vlanid)) {
>> /* pop the vlan tag */
>> - ehdr = (struct ethhdr *)skb->data;
>> - memmove(skb->data + VLAN_HLEN, ehdr, ETH_ALEN * 2);
>> + veth = (struct vlan_ethhdr *)skb->data;
>> + vlan_proto = veth->h_vlan_proto;
>> + memmove(skb->data + VLAN_HLEN, veth, ETH_ALEN * 2);
>> skb_pull(skb, VLAN_HLEN);
>> - __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), vlanid);
>> + __vlan_hwaccel_put_tag(skb, vlan_proto, vlanid);
>> }
>> }
>
> I can't see how it is valid to do an unconditional software VLAN
> untagging even when VLAN is disabled in the kernel config or the
> NETIF_F_* feature bits are not set.
Right. It is not valid.
>
> At a minimum that feature test has to stay there, and when it's clear
> we let the generic VLAN code untag the packet.
Since NETIF_F_HW_VLAN_*_RX are not protocol agnostic, we need two kind
of similar checking here.
veth = (struct vlan_ethhdr *)skb->data;
vlan_proto = veth->h_vlan_proto;
if ((vlan_proto == htons(ETH_P_8021Q) &&
dev->features & NETIF_F_HW_VLAN_CTAG_RX) ||
(vlan_proto == htons(ETH_P_8021AD) &&
dev->features & NETIF_F_HW_VLAN_STAG_RX) {
vlanid = ntohs(veth->h_vlan_TCI);
memmove(...);
skb_pull(...);
__vlan_hwaccel_put_tag(skb, vlan_proto, vlanid);
}
An alternative way is not to check vlan_proto or features here but
compile this code only when VLAN is enabled in the kernel config. This
can be valid only because this driver does not have NETIF_F_HW_VLAN_*_RX
in hw_features and they can not be toggled for now.
static void stmmac_rx_vlan(struct net_device *dev, struct sk_buff *skb)
{
#ifdef STMMAC_VLAN_TAG_USED
...
if (!__vlan_get_tag(skb, &vlanid)) {
...
__vlan_hwaccel_put_tag(skb, vlan_proto, vlanid);
}
#endif
}
--
Toshiaki Makita
^ permalink raw reply
* Re: [PATCH 10/18] rhashtable: remove rhashtable_walk_peek()
From: NeilBrown @ 2018-06-04 0:30 UTC (permalink / raw)
To: Herbert Xu; +Cc: Thomas Graf, netdev, linux-kernel, Tom Herbert
In-Reply-To: <20180602154851.pfy4wryezuhxp76v@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 1530 bytes --]
On Sat, Jun 02 2018, Herbert Xu wrote:
> On Fri, Jun 01, 2018 at 02:44:09PM +1000, NeilBrown wrote:
>> This function has a somewhat confused behavior that is not properly
>> described by the documentation.
>> Sometimes is returns the previous object, sometimes it returns the
>> next one.
>> Sometimes it changes the iterator, sometimes it doesn't.
>>
>> This function is not currently used and is not worth keeping, so
>> remove it.
>>
>> A future patch will introduce a new function with a
>> simpler interface which can meet the same need that
>> this was added for.
>>
>> Signed-off-by: NeilBrown <neilb@suse.com>
>
> Please keep Tom Herbert in the loop. IIRC he had an issue with
> this patch.
Yes you are right - sorry for forgetting to add Tom.
My understanding of where this issue stands is that Tom raised issue and
asked for clarification, I replied, nothing further happened.
It summary, my position is that:
- most users of my new rhashtable_walk_prev() will use it like
rhasthable_talk_prev() ?: rhashtable_walk_next()
which is close to what rhashtable_walk_peek() does
- I know of no use-case that could not be solved if we only had
the combined operation
- BUT it is hard to document the combined operation, as it really
does two things. If it is hard to document, then it might be
hard to understand.
So provide the most understandable/maintainable solution, I think
we should provide rhashtable_walk_prev() as a separate interface.
Thanks,
NeilBronw
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH 15/18] rhashtable: use bit_spin_locks to protect hash bucket.
From: NeilBrown @ 2018-06-04 0:25 UTC (permalink / raw)
To: Eric Dumazet, Herbert Xu
Cc: Thomas Graf, netdev, linux-kernel, Eric Dumazet, David S. Miller
In-Reply-To: <9bea77df-e7db-677a-31b2-710dc6d956ee@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 677 bytes --]
On Sat, Jun 02 2018, Eric Dumazet wrote:
> On 06/02/2018 01:03 AM, Herbert Xu wrote:
>
>> Yes the concept looks good to me. But I would like to hear from
>> Eric/Dave as to whether this would be acceptable for existing
>> network hash tables such as the ones in inet.
>
>
> What about lockdep support ?
bitlocks don't have native lockdep support.
I would be fairly easy to add lockdep support to
rht_{lock,unlock,unlocked} if you think it is worthwhile.
It could only really help if a hash-function or cmp-function took a
lock, but it is not a great cost so we may as well just do it.
I'll try to have a patch in the next day or so.
Thanks,
NeilBrown
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] net: ipv6: Generate random IID for addresses on RAWIP devices
From: 吉藤英明 @ 2018-06-03 23:50 UTC (permalink / raw)
To: Subash Abhinov Kasiviswanathan; +Cc: davem, netdev, yoshfuji
In-Reply-To: <1528062874-19250-1-git-send-email-subashab@codeaurora.org>
Hello,
2018-06-04 6:54 GMT+09:00 Subash Abhinov Kasiviswanathan
<subashab@codeaurora.org>:
> RAWIP devices such as rmnet do not have a hardware address and
> instead require the kernel to generate a random IID for the
> temporary addresses. For permanent addresses, the device IID is
> used along with prefix received.
>
> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
> ---
> net/ipv6/addrconf.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index f09afc2..e4c4540 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -2230,6 +2230,18 @@ static int addrconf_ifid_ip6tnl(u8 *eui, struct net_device *dev)
> return 0;
> }
>
> +static int addrconf_ifid_rawip(u8 *eui, struct net_device *dev)
> +{
> + struct in6_addr lladdr;
> +
> + if (ipv6_get_lladdr(dev, &lladdr, IFA_F_TENTATIVE))
> + get_random_bytes(eui, 8);
Please be aware of I/G bit and G/L bit.
--yoshfuji
^ permalink raw reply
* KASAN: use-after-free Read in bpf_csum_update
From: syzbot @ 2018-06-03 23:36 UTC (permalink / raw)
To: ast, daniel, davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: bcece5dc40b9 bpf: Change bpf_fib_lookup to return -EAFNOSU..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=161e2c6f800000
kernel config: https://syzkaller.appspot.com/x/.config?x=e4078980b886800c
dashboard link: https://syzkaller.appspot.com/bug?extid=3d0b2441dbb71751615e
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=17cb5adf800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17ebf19f800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3d0b2441dbb71751615e@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
==================================================================
BUG: KASAN: use-after-free in ____bpf_csum_update net/core/filter.c:1907
[inline]
BUG: KASAN: use-after-free in bpf_csum_update+0xb4/0xc0
net/core/filter.c:1901
Read of size 1 at addr ffff8801ad062f10 by task syz-executor354/4488
CPU: 1 PID: 4488 Comm: syz-executor354 Not tainted 4.17.0-rc6+ #29
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
____bpf_csum_update net/core/filter.c:1907 [inline]
bpf_csum_update+0xb4/0xc0 net/core/filter.c:1901
The buggy address belongs to the page:
page:ffffea0006b41880 count:0 mapcount:0 mapping:0000000000000000 index:0x0
flags: 0x2fffc0000000000()
raw: 02fffc0000000000 0000000000000000 0000000000000000 00000000ffffffff
raw: ffffea0006b41820 ffffea0006b671a0 0000000000000000 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801ad062e00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff8801ad062e80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ffff8801ad062f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff8801ad062f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff8801ad063000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* KASAN: slab-out-of-bounds Read in skb_ensure_writable
From: syzbot @ 2018-06-03 23:36 UTC (permalink / raw)
To: ast, daniel, davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 0512e0134582 Merge tag 'xfs-4.17-fixes-3' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=14956af7800000
kernel config: https://syzkaller.appspot.com/x/.config?x=968b0b23c7854c0b
dashboard link: https://syzkaller.appspot.com/bug?extid=e5190cb881d8660fb1a3
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=123d9d7b800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=100329d7800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e5190cb881d8660fb1a3@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
==================================================================
BUG: KASAN: slab-out-of-bounds in pskb_may_pull include/linux/skbuff.h:2104
[inline]
BUG: KASAN: slab-out-of-bounds in skb_ensure_writable+0x554/0x620
net/core/skbuff.c:5101
Read of size 4 at addr ffff8801aefc1780 by task syz-executor159/4509
CPU: 0 PID: 4509 Comm: syz-executor159 Not tainted 4.17.0-rc7+ #78
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
pskb_may_pull include/linux/skbuff.h:2104 [inline]
skb_ensure_writable+0x554/0x620 net/core/skbuff.c:5101
__bpf_try_make_writable net/core/filter.c:1419 [inline]
bpf_try_make_writable net/core/filter.c:1425 [inline]
____bpf_l3_csum_replace net/core/filter.c:1546 [inline]
bpf_l3_csum_replace+0x8c/0x4d0 net/core/filter.c:1537
Allocated by task 0:
(stack is not available)
Freed by task 0:
(stack is not available)
The buggy address belongs to the object at ffff8801aefc1680
which belongs to the cache skbuff_head_cache of size 232
The buggy address is located 24 bytes to the right of
232-byte region [ffff8801aefc1680, ffff8801aefc1768)
The buggy address belongs to the page:
page:ffffea0006bbf040 count:1 mapcount:0 mapping:ffff8801aefc1040 index:0x0
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffff8801aefc1040 0000000000000000 000000010000000c
raw: ffffea0006b61060 ffffea0006bd69e0 ffff8801d9bdd6c0 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801aefc1680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801aefc1700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801aefc1780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8801aefc1800: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801aefc1880: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* KASAN: use-after-free Read in skb_ensure_writable
From: syzbot @ 2018-06-03 23:36 UTC (permalink / raw)
To: ast, daniel, davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: bcece5dc40b9 bpf: Change bpf_fib_lookup to return -EAFNOSU..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=10ee76b7800000
kernel config: https://syzkaller.appspot.com/x/.config?x=e4078980b886800c
dashboard link: https://syzkaller.appspot.com/bug?extid=c8504affd4fdd0c1b626
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=10d926df800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1778c26f800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+c8504affd4fdd0c1b626@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
==================================================================
BUG: KASAN: use-after-free in pskb_may_pull include/linux/skbuff.h:2108
[inline]
BUG: KASAN: use-after-free in skb_ensure_writable+0x554/0x620
net/core/skbuff.c:5118
Read of size 4 at addr ffff8801b0b40fc0 by task syz-executor258/4479
CPU: 0 PID: 4479 Comm: syz-executor258 Not tainted 4.17.0-rc6+ #29
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
pskb_may_pull include/linux/skbuff.h:2108 [inline]
skb_ensure_writable+0x554/0x620 net/core/skbuff.c:5118
__bpf_try_make_writable net/core/filter.c:1606 [inline]
bpf_try_make_writable net/core/filter.c:1612 [inline]
____bpf_l3_csum_replace net/core/filter.c:1774 [inline]
bpf_l3_csum_replace+0x8c/0x4d0 net/core/filter.c:1765
The buggy address belongs to the page:
page:ffffea0006c2d000 count:0 mapcount:0 mapping:0000000000000000 index:0x0
flags: 0x2fffc0000000000()
raw: 02fffc0000000000 0000000000000000 0000000000000000 00000000ffffffff
raw: ffffea00075ea760 ffffea0006c39660 ffff8801b5848738 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801b0b40e80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ffff8801b0b40f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ffff8801b0b40f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
^
ffff8801b0b41000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801b0b41080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* KASAN: slab-out-of-bounds Read in bpf_csum_update
From: syzbot @ 2018-06-03 23:36 UTC (permalink / raw)
To: ast, daniel, davem, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 0512e0134582 Merge tag 'xfs-4.17-fixes-3' of git://git.ker..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17eb2d7b800000
kernel config: https://syzkaller.appspot.com/x/.config?x=968b0b23c7854c0b
dashboard link: https://syzkaller.appspot.com/bug?extid=efae31b384d5badbd620
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=162c6def800000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14fe3db7800000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+efae31b384d5badbd620@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
==================================================================
BUG: KASAN: slab-out-of-bounds in ____bpf_csum_update
net/core/filter.c:1679 [inline]
BUG: KASAN: slab-out-of-bounds in bpf_csum_update+0xb4/0xc0
net/core/filter.c:1673
Read of size 1 at addr ffff8801d9235b50 by task syz-executor507/4513
CPU: 0 PID: 4513 Comm: syz-executor507 Not tainted 4.17.0-rc7+ #78
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:430
____bpf_csum_update net/core/filter.c:1679 [inline]
bpf_csum_update+0xb4/0xc0 net/core/filter.c:1673
Allocated by task 0:
(stack is not available)
Freed by task 0:
(stack is not available)
The buggy address belongs to the object at ffff8801d9235a40
which belongs to the cache skbuff_head_cache of size 232
The buggy address is located 40 bytes to the right of
232-byte region [ffff8801d9235a40, ffff8801d9235b28)
The buggy address belongs to the page:
page:ffffea0007648d40 count:1 mapcount:0 mapping:ffff8801d9235040 index:0x0
flags: 0x2fffc0000000100(slab)
raw: 02fffc0000000100 ffff8801d9235040 0000000000000000 000000010000000c
raw: ffffea00074360a0 ffff8801d944d848 ffff8801d9bdd6c0 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801d9235a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801d9235a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801d9235b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffff8801d9235b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8801d9235c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
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