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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).