From: Leon Romanovsky <leon@kernel.org>
To: David Miller <davem@davemloft.net>,
johannes@sipsolutions.net, kuba@kernel.org
Cc: netdev@vger.kernel.org, kernel-team@fb.com, jiri@resnulli.us,
andrew@lunn.ch, mkubecek@suse.cz,
Saeed Mahameed <saeedm@nvidia.com>
Subject: Re: [PATCH net-next v2 0/7] ethtool: allow dumping policies to user space
Date: Wed, 7 Oct 2020 09:27:54 +0300 [thread overview]
Message-ID: <20201007062754.GU1874917@unreal> (raw)
In-Reply-To: <20201006.062618.628708952352439429.davem@davemloft.net>
On Tue, Oct 06, 2020 at 06:26:18AM -0700, David Miller wrote:
> From: Johannes Berg <johannes@sipsolutions.net>
> Date: Tue, 06 Oct 2020 08:43:17 +0200
>
> > On Mon, 2020-10-05 at 15:07 -0700, Jakub Kicinski wrote:
> >> Hi!
> >>
> >> This series wires up ethtool policies to ops, so they can be
> >> dumped to user space for feature discovery.
> >>
> >> First patch wires up GET commands, and second patch wires up SETs.
> >>
> >> The policy tables are trimmed to save space and LoC.
> >>
> >> Next - take care of linking up nested policies for the header
> >> (which is the policy what we actually care about). And once header
> >> policy is linked make sure that attribute range validation for flags
> >> is done by policy, not a conditions in the code. New type of policy
> >> is needed to validate masks (patch 6).
> >>
> >> Netlink as always staying a step ahead of all the other kernel
> >> API interfaces :)
> ...
> > Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
>
> Series applied, thanks everyone.
Hi Dave, Johannes and Jakub
This series and my guess that it comes from ff419afa4310 ("ethtool: trim policy tables")
generates the following KASAN out-of-bound error.
[ 187.278416] ==================================================================
[ 187.282872] BUG: KASAN: slab-out-of-bounds in strset_parse_request+0x3ef/0x480
[ 187.284499] Read of size 8 at addr ffff88828db2b158 by task ethtool/3949
[ 187.285927]
[ 187.286406] CPU: 0 PID: 3949 Comm: ethtool Not tainted 5.9.0-rc8_master_8f9ef66 #1
[ 187.288135] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[ 187.290526] Call Trace:
[ 187.291190] dump_stack+0x9a/0xd0
[ 187.292028] ? strset_parse_request+0x3ef/0x480
[ 187.293069] print_address_description.constprop.0+0x1c/0x220
[ 187.294331] ? nla_get_range_signed+0x540/0x540
[ 187.295373] ? strset_parse_request+0x3ef/0x480
[ 187.296421] ? strset_parse_request+0x3ef/0x480
[ 187.297458] kasan_report.cold+0x1f/0x37
[ 187.298387] ? strset_parse_request+0x3ef/0x480
[ 187.299422] strset_parse_request+0x3ef/0x480
[ 187.300434] ? ethnl_default_dumpit+0xcd0/0xcd0
[ 187.301483] ? strset_cleanup_data+0xd0/0xd0
[ 187.302489] ethnl_default_parse+0xb3/0x110
[ 187.303476] ethnl_default_doit+0x223/0x950
[ 187.304454] ? ethnl_reply_init+0x1b0/0x1b0
[ 187.305433] ? __nla_parse+0x22/0x25
[ 187.306292] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x15e/0x230
[ 187.307708] genl_family_rcv_msg_doit+0x1e9/0x2f0
[ 187.308797] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230
[ 187.310218] ? register_lock_class+0x1650/0x1650
[ 187.311273] genl_rcv_msg+0x27f/0x4a0
[ 187.312166] ? genl_get_cmd+0x3c0/0x3c0
[ 187.313074] ? lock_acquire+0x1da/0x9c0
[ 187.313978] ? genl_rcv+0x15/0x40
[ 187.314788] ? ethnl_reply_init+0x1b0/0x1b0
[ 187.315766] ? ethnl_default_parse+0x110/0x110
[ 187.316781] ? ethnl_fill_reply_header.part.0+0x2d0/0x2d0
[ 187.317998] ? get_order+0x20/0x20
[ 187.318840] ? check_flags+0x60/0x60
[ 187.319712] netlink_rcv_skb+0x124/0x350
[ 187.320642] ? genl_get_cmd+0x3c0/0x3c0
[ 187.321558] ? netlink_ack+0x8b0/0x8b0
[ 187.322462] ? __might_fault+0xef/0x1a0
[ 187.323383] genl_rcv+0x24/0x40
[ 187.324199] netlink_unicast+0x433/0x700
[ 187.325157] ? netlink_attachskb+0x6f0/0x6f0
[ 187.326151] ? __alloc_skb+0x32a/0x530
[ 187.327048] netlink_sendmsg+0x6f1/0xbd0
[ 187.328010] ? netlink_unicast+0x700/0x700
[ 187.328996] ? netlink_unicast+0x700/0x700
[ 187.329953] sock_sendmsg+0xb0/0xe0
[ 187.330824] __sys_sendto+0x193/0x240
[ 187.331736] ? __x64_sys_getpeername+0xb0/0xb0
[ 187.332781] ? do_raw_spin_unlock+0x54/0x220
[ 187.333794] ? __up_read+0x1a1/0x7b0
[ 187.334738] __x64_sys_sendto+0xdd/0x1b0
[ 187.335718] ? syscall_enter_from_user_mode+0x1d/0x50
[ 187.336889] do_syscall_64+0x2d/0x40
[ 187.337744] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 187.338949] RIP: 0033:0x7fe429352efa
[ 187.339870] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 76 c3 0f 1f 44 00 00 55 48 83 ec 30 44 89 4c
[ 187.343971] RSP: 002b:00007ffc105fc268 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
[ 187.345764] RAX: ffffffffffffffda RBX: 000000000198c430 RCX: 00007fe429352efa
[ 187.347386] RDX: 0000000000000028 RSI: 000000000198c4a0 RDI: 0000000000000004
[ 187.349015] RBP: 000000000198c4a0 R08: 00007fe42941e000 R09: 000000000000000c
[ 187.350637] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000042f4f0
[ 187.352239] R13: 000000000197c3a0 R14: 000000000197c2a0 R15: 000000000197c3a0
[ 187.353791]
[ 187.354283] Allocated by task 3949:
[ 187.355145] kasan_save_stack+0x1b/0x40
[ 187.356067] __kasan_kmalloc.constprop.0+0xc2/0xd0
[ 187.357182] genl_family_rcv_msg_attrs_parse.constprop.0+0xb5/0x230
[ 187.358567] genl_family_rcv_msg_doit+0xc7/0x2f0
[ 187.359651] genl_rcv_msg+0x27f/0x4a0
[ 187.360519] netlink_rcv_skb+0x124/0x350
[ 187.361464] genl_rcv+0x24/0x40
[ 187.362260] netlink_unicast+0x433/0x700
[ 187.363177] netlink_sendmsg+0x6f1/0xbd0
[ 187.364096] sock_sendmsg+0xb0/0xe0
[ 187.364959] __sys_sendto+0x193/0x240
[ 187.365885] __x64_sys_sendto+0xdd/0x1b0
[ 187.366797] do_syscall_64+0x2d/0x40
[ 187.367695] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 187.368900]
[ 187.369400] The buggy address belongs to the object at ffff88828db2b140
[ 187.369400] which belongs to the cache kmalloc-32 of size 32
[ 187.372134] The buggy address is located 24 bytes inside of
[ 187.372134] 32-byte region [ffff88828db2b140, ffff88828db2b160)
[ 187.374713] The buggy address belongs to the page:
[ 187.375884] page:00000000980aee13 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88828db2bc80 pfn:0x28db2b
[ 187.378286] flags: 0x8000000000000200(slab)
[ 187.379318] raw: 8000000000000200 ffffea0009be8a80 0000001b0000001b ffff8882a3043a40
[ 187.381156] raw: ffff88828db2bc80 0000000080400039 00000001ffffffff 0000000000000000
[ 187.382973] page dumped because: kasan: bad access detected
[ 187.384252]
[ 187.384747] Memory state around the buggy address:
[ 187.385825] ffff88828db2b000: fb fb fb fb fc fc fc fc fb fb fb fb fc fc fc fc
[ 187.387479] ffff88828db2b080: fb fb fb fb fc fc fc fc 00 00 00 fc fc fc fc fc
[ 187.389103] >ffff88828db2b100: fb fb fb fb fc fc fc fc 00 00 00 fc fc fc fc fc
[ 187.390707] ^
[ 187.392050] ffff88828db2b180: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
[ 187.393693] ffff88828db2b200: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
[ 187.395314] ==================================================================
next prev parent reply other threads:[~2020-10-07 6:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-05 22:07 [PATCH net-next v2 0/7] ethtool: allow dumping policies to user space Jakub Kicinski
2020-10-05 22:07 ` [PATCH net-next v2 1/7] ethtool: wire up get policies to ops Jakub Kicinski
2020-10-05 22:07 ` [PATCH net-next v2 2/7] ethtool: wire up set " Jakub Kicinski
2020-10-05 22:07 ` [PATCH net-next v2 3/7] ethtool: trim policy tables Jakub Kicinski
2020-10-08 9:12 ` Eric Dumazet
2020-10-08 9:13 ` Johannes Berg
2020-10-08 9:15 ` Johannes Berg
2020-10-08 15:09 ` Eric Dumazet
2020-10-05 22:07 ` [PATCH net-next v2 4/7] ethtool: link up ethnl_header_policy as a nested policy Jakub Kicinski
2020-10-05 22:07 ` [PATCH net-next v2 5/7] netlink: create helpers for checking type is an int Jakub Kicinski
2020-10-05 22:07 ` [PATCH net-next v2 6/7] netlink: add mask validation Jakub Kicinski
2020-10-05 22:07 ` [PATCH net-next v2 7/7] ethtool: specify which header flags are supported per command Jakub Kicinski
2020-10-06 6:43 ` [PATCH net-next v2 0/7] ethtool: allow dumping policies to user space Johannes Berg
2020-10-06 13:26 ` David Miller
2020-10-07 6:27 ` Leon Romanovsky [this message]
2020-10-07 7:30 ` Johannes Berg
2020-10-07 8:24 ` Leon Romanovsky
2020-10-07 8:29 ` Johannes Berg
2020-10-07 8:33 ` Leon Romanovsky
2020-10-07 10:47 ` Leon Romanovsky
2020-10-07 8:52 ` Michal Kubecek
2020-10-07 10:48 ` Leon Romanovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201007062754.GU1874917@unreal \
--to=leon@kernel.org \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=jiri@resnulli.us \
--cc=johannes@sipsolutions.net \
--cc=kernel-team@fb.com \
--cc=kuba@kernel.org \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=saeedm@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.