From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dmitry Vyukov Subject: Re: general protection fault in qdisc_hash_add Date: Fri, 18 May 2018 11:14:07 +0200 Message-ID: References: <20180518083820.GM8958@leo.usersys.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: syzkaller , Paolo Abeni , Marcelo Ricardo Leitner , netdev To: Hangbin Liu Return-path: Received: from mail-pl0-f67.google.com ([209.85.160.67]:38339 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753089AbeERJO2 (ORCPT ); Fri, 18 May 2018 05:14:28 -0400 Received: by mail-pl0-f67.google.com with SMTP id c11-v6so4240460plr.5 for ; Fri, 18 May 2018 02:14:28 -0700 (PDT) In-Reply-To: <20180518083820.GM8958@leo.usersys.redhat.com> Sender: netdev-owner@vger.kernel.org List-ID: On Fri, May 18, 2018 at 10:38 AM, Hangbin Liu wrote: > Hi Dmitry, > > I got a kasan GPF error when run netlink sched test. The syzkaller log fi= le > and call trace attached. > > What interested me is the TCA_RED_PARMS. Here is the log > > r0 =3D socket$nl_route(0x10, 0x3, 0x0) > ioctl$sock_SIOCGIFINDEX(r0, 0x8933, &(0x7f0000000740)=3D{'lo\x00', 0x0}) > sendmsg$nl_route_sched(r0, &(0x7f00000000c0)=3D{&(0x7f0000000000)=3D{0x10= }, 0xc, &(0x7f0000000180)=3D{&(0x7f00000002c0)=3D@newqdisc=3D{0x148, 0x24, = 0x421, 0x0, 0x0, {0x0, r1, {}, {0x0, 0xffff}}, [@qdisc_kind_options=3D@q_re= d=3D{{0x8, 0x1, 'red\x00'}, {0x11c, 0x2, [@TCA_RED_PARMS=3D{0x14, 0x1, {0x0= , 0x0, 0x0, 0x1f}}, @TCA_RED_STAB=3D{0x104, 0x2, "18ac558f2dba9315851070f6e= 8d2533e755bb93a10146fbf3450d1c5096ce5e8e25674655d985acf1dde6c6283858c71ba0c= 8c2ba63e82d8168ddaccb0e656849ad10cc603fdac12346de63f934064095e194ee7a3d129c= cc57b3c15056f2c5b04584fa0986e2e284a1b4d74577f7b61c20772219d7c01a8f2164d27a0= 74a37f6af6ea6415d6d80c578ff5e656f5bedf074b2d38a8b5b119ba1ef5e206952614d9951= ef4027a8bc397208890380c6d6a1ec9994cfceef8675ab30395cc0115a850a4a327a0019590= 3f1d6272567b734776754842f7c4d87da1b4cea9a7330329e290b1d7a7bb77f4e87640340c6= c6d704655bd351f47a09af6e2f37583ea5b7e"}]}}]}, 0x148}, 0x1}, 0x0) > > > From the log it sendmsg with TCA_RED_PARMS=3D{0x14, 0x1, {0x0, 0x0, 0x0, = 0x1f}}. > But we defined tc_red_qopt like > tc_red_qopt { > limit int32 > qth_min int32 > qth_max int32 > Wlog int8[0:32] > Plog int8[0:32] > Scell_log int8[0:32] > flag int8[0:8] > } > > The items in the structer seems missmatch. Would you help explain how > syzkaller fuzz the structer? TCA_RED_PARMS union option is defined as: q_red_options [ TCA_RED_PARMS nlattr[TCA_RED_PARMS, tc_red_qopt] ... ] [varlen] and nlattr is defined as: type nlattr[TYPE, PAYLOAD] nlattr_t[const[TYPE, int16], PAYLOAD] type nlattr_t[TYPE, PAYLOAD] { nla_len len[parent, int16] nla_type TYPE payload PAYLOAD } [packed, align_4] So here: @TCA_RED_PARMS=3D{0x14, 0x1, {0x0, 0x0, 0x0, 0x1f}} first 2 numbers are nlattr len and type, and then the inner struct is tc_red_qopt with truncated trailing zero values.