Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-and-tested-by: syzbot+b53a9c0d1ea4ad62da8b@syzkaller.appspotmail.com

Tested on:

commit:         fff5a5e7 Merge tag 'for-linus' of git://git.armlinux.o..
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=1658d89fc80000
kernel config:  https://syzkaller.appspot.com/x/.config?x=ea09b0836073ee4
dashboard link: https://syzkaller.appspot.com/bug?extid=b53a9c0d1ea4ad62da8b
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
patch:          https://syzkaller.appspot.com/x/patch.diff?x=10d7cd5bc80000

Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-and-tested-by: syzbot+b53a9c0d1ea4ad62da8b@syzkaller.appspotmail.com

Tested on:

commit:         6078d01d net/sched: qdisc_destroy() old ingress and cl..
git tree:       https://gitlab.com/tammela/net.git peilin-patches
console output: https://syzkaller.appspot.com/x/log.txt?x=111cf24d280000
kernel config:  https://syzkaller.appspot.com/x/.config?x=b22b5699e8595bcd
dashboard link: https://syzkaller.appspot.com/bug?extid=b53a9c0d1ea4ad62da8b
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

Note: no patches were applied.
Note: testing is done by a robot and is best-effort only.

Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[Pedro Tammela]

#syz test: https://gitlab.com/tammela/net.git peilin-patches
Let's try with https then...

Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[syzbot]

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

failed to checkout kernel repo git://gitlab.com/tammela/net.git/peilin-patches: failed to run ["git" "fetch" "--force" "71d757925c19d8f23c660d1e07af98f28b9c6977" "peilin-patches"]: exit status 128
fatal: read error: Connection reset by peer



Tested on:

commit:         [unknown 
git tree:       git://gitlab.com/tammela/net.git peilin-patches
dashboard link: https://syzkaller.appspot.com/bug?extid=b53a9c0d1ea4ad62da8b
compiler:       

Note: no patches were applied.

Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[Pedro Tammela]

#syz test: git://gitlab.com/tammela/net.git peilin-patches

Double checking with syzbot

Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[Vlad Buslov]

On Thu 27 Apr 2023 at 10:35, Peilin Ye <yepeilin.cs@gmail.com> wrote:
> Hi Pedro, Vlad,
>
> On Thu, Apr 27, 2023 at 03:26:03PM +0300, Vlad Buslov wrote:
>> On Wed 26 Apr 2023 at 16:42, Peilin Ye <yepeilin.cs@gmail.com> wrote:
>> > As we can see there're interleaving mini_qdisc_pair_swap() calls between
>> > Qdisc A and B, causing all kinds of troubles, including the UAF (thread
>> > 2 writing to mini Qdisc a1's rcu_state after Qdisc A has already been
>> > freed) reported by syzbot.
>> 
>> Great analysis! However, it is still not quite clear to me how threads 1
>> and 2 access each other RCU state when q->miniqp is a private memory of
>> the Qdisc, so 1 should only see A->miniqp and 2 only B->miniqp. And both
>> miniqps should be protected from deallocation by reference that lockless
>> RTM_NEWTFILTER obtains.
>
> Thanks for taking a look!
>
> To elaborate, p_miniq is a pointer of pointer of struct mini_Qdisc,
> initialized in ingress_init() to point to eth0->miniq_ingress, which
> isn't private to A or B.
>
> In other words, both A->miniqp->p_miniq and B->miniqp->p_miniq point to
> eth0->miniq_ingress.
>
> For your reference, roughly speaking, mini_qdisc_pair_swap() does this:
>
>   miniq_old = dev->miniq_ingress;
>
>   if (destroying) {
>           dev->miniq_ingress = NULL;
>   } else {
>           rcu_wait();
>           dev->miniq_ingress = miniq_new;
>   }
>
>   if (miniq_old)
>           miniq_old->rcu_state = ...
>
> On Wed 26 Apr 2023 at 16:42, Peilin Ye <yepeilin.cs@gmail.com> wrote:
>>  Thread 1               A's refcnt   Thread 2
>>   RTM_NEWQDISC (A, locked)
>>    qdisc_create(A)               1
>>    qdisc_graft(A)                9
>>
>>   RTM_NEWTFILTER (X, lockless)
>>    __tcf_qdisc_find(A)          10
>>    tcf_chain0_head_change(A)
>>  ! mini_qdisc_pair_swap(A)
>
>   1. A adds its first filter,
>      miniq_old (eth0->miniq_ingress) is NULL,
>      RCU wait starts,
>      RCU wait ends,
>      change eth0->miniq_ingress to A's mini Qdisc.
>
>>             |                        RTM_NEWQDISC (B, locked)
>>             |                    2    qdisc_graft(B)
>>             |                    1    notify_and_destroy(A)
>>             |
>>             |                        RTM_NEWTFILTER (Y, lockless)
>>             |                         tcf_chain0_head_change(B)
>>             |                       ! mini_qdisc_pair_swap(B)
>
>                       2. B adds its first filter,
>                          miniq_old (eth0->miniq_ingress) is A's mini Qdisc,
>                          RCU wait starts,
>
>>    tcf_block_release(A)          0             |
>>    qdisc_destroy(A)                            |
>>    tcf_chain0_head_change_cb_del(A)            |
>>  ! mini_qdisc_pair_swap(A)                     |
>
>   3. A destroys itself,
>      miniq_old (eth0->miniq_ingress) is A's mini Qdisc,
>      (destroying, so no RCU wait)
>      change eth0->miniq_ingress to NULL,
>      update miniq_old, or A's mini Qdisc's RCU state,
>      A is freed.
>
>                       2. RCU wait ends,
> 		         change eth0->miniq_ingress to B's mini Qdisc,
> 	 use-after-free: update miniq_old, or A's mini Qdisc's RCU state.

Thanks for the clarification.

>
> I hope this helps.  Sorry I didn't go into details; this UAF isn't the
> only thing that is unacceptable here:
>
> Consider B.  We add a filter Y to B, expecting ingress packets on eth0
> to go through Y.  Then all of a sudden, A sets eth0->miniq_ingress to
> NULL during its destruction, so packets will not find Y at all on
> datapath (sch_handle_ingress()).  New filter becomes invisible - this is
> already buggy enough :-/
>
> So I think B's first call to mini_qdisc_pair_swap() should happen after
> A's last call (in ingress_destroy()), which is what I am trying to
> achieve here.

Makes sense to me.

Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[Peilin Ye]

Hi Pedro, Vlad,

On Thu, Apr 27, 2023 at 03:26:03PM +0300, Vlad Buslov wrote:
> On Wed 26 Apr 2023 at 16:42, Peilin Ye <yepeilin.cs@gmail.com> wrote:
> > As we can see there're interleaving mini_qdisc_pair_swap() calls between
> > Qdisc A and B, causing all kinds of troubles, including the UAF (thread
> > 2 writing to mini Qdisc a1's rcu_state after Qdisc A has already been
> > freed) reported by syzbot.
> 
> Great analysis! However, it is still not quite clear to me how threads 1
> and 2 access each other RCU state when q->miniqp is a private memory of
> the Qdisc, so 1 should only see A->miniqp and 2 only B->miniqp. And both
> miniqps should be protected from deallocation by reference that lockless
> RTM_NEWTFILTER obtains.

Thanks for taking a look!

To elaborate, p_miniq is a pointer of pointer of struct mini_Qdisc,
initialized in ingress_init() to point to eth0->miniq_ingress, which
isn't private to A or B.

In other words, both A->miniqp->p_miniq and B->miniqp->p_miniq point to
eth0->miniq_ingress.

For your reference, roughly speaking, mini_qdisc_pair_swap() does this:

  miniq_old = dev->miniq_ingress;

  if (destroying) {
          dev->miniq_ingress = NULL;
  } else {
          rcu_wait();
          dev->miniq_ingress = miniq_new;
  }

  if (miniq_old)
          miniq_old->rcu_state = ...

On Wed 26 Apr 2023 at 16:42, Peilin Ye <yepeilin.cs@gmail.com> wrote:
>  Thread 1               A's refcnt   Thread 2
>   RTM_NEWQDISC (A, locked)
>    qdisc_create(A)               1
>    qdisc_graft(A)                9
>
>   RTM_NEWTFILTER (X, lockless)
>    __tcf_qdisc_find(A)          10
>    tcf_chain0_head_change(A)
>  ! mini_qdisc_pair_swap(A)

  1. A adds its first filter,
     miniq_old (eth0->miniq_ingress) is NULL,
     RCU wait starts,
     RCU wait ends,
     change eth0->miniq_ingress to A's mini Qdisc.

>             |                        RTM_NEWQDISC (B, locked)
>             |                    2    qdisc_graft(B)
>             |                    1    notify_and_destroy(A)
>             |
>             |                        RTM_NEWTFILTER (Y, lockless)
>             |                         tcf_chain0_head_change(B)
>             |                       ! mini_qdisc_pair_swap(B)

                      2. B adds its first filter,
                         miniq_old (eth0->miniq_ingress) is A's mini Qdisc,
                         RCU wait starts,

>    tcf_block_release(A)          0             |
>    qdisc_destroy(A)                            |
>    tcf_chain0_head_change_cb_del(A)            |
>  ! mini_qdisc_pair_swap(A)                     |

  3. A destroys itself,
     miniq_old (eth0->miniq_ingress) is A's mini Qdisc,
     (destroying, so no RCU wait)
     change eth0->miniq_ingress to NULL,
     update miniq_old, or A's mini Qdisc's RCU state,
     A is freed.

                      2. RCU wait ends,
		         change eth0->miniq_ingress to B's mini Qdisc,
	 use-after-free: update miniq_old, or A's mini Qdisc's RCU state.

I hope this helps.  Sorry I didn't go into details; this UAF isn't the
only thing that is unacceptable here:

Consider B.  We add a filter Y to B, expecting ingress packets on eth0
to go through Y.  Then all of a sudden, A sets eth0->miniq_ingress to
NULL during its destruction, so packets will not find Y at all on
datapath (sch_handle_ingress()).  New filter becomes invisible - this is
already buggy enough :-/

So I think B's first call to mini_qdisc_pair_swap() should happen after
A's last call (in ingress_destroy()), which is what I am trying to
achieve here.

Thanks,
Peilin Ye

Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[Vlad Buslov]

Hi Peilin,

On Wed 26 Apr 2023 at 16:42, Peilin Ye <yepeilin.cs@gmail.com> wrote:
> +Cc: Vlad Buslov, Hillf Danton
>
> Hi all,
>
> On Mon, Apr 17, 2023 at 04:00:11PM -0700, Peilin Ye wrote:
>> I also reproduced this UAF using the syzkaller reproducer in the report
>> (the C reproducer did not work for me for unknown reasons).  I will look
>> into this.
>
> Currently, multiple ingress (clsact) Qdiscs can access the per-netdev
> *miniq_ingress (*miniq_egress) pointer concurrently.  This is
> unfortunately true in two senses:
>
> 1. We allow adding ingress (clsact) Qdiscs under parents other than
> TC_H_INGRESS (TC_H_CLSACT):
>
>   $ ip link add ifb0 numtxqueues 8 type ifb
>   $ echo clsact > /proc/sys/net/core/default_qdisc
>   $ tc qdisc add dev ifb0 handle 1: root mq
>   $ tc qdisc show dev ifb0
>   qdisc mq 1: root
>   qdisc clsact 0: parent 1:8
>   qdisc clsact 0: parent 1:7
>   qdisc clsact 0: parent 1:6
>   qdisc clsact 0: parent 1:5
>   qdisc clsact 0: parent 1:4
>   qdisc clsact 0: parent 1:3
>   qdisc clsact 0: parent 1:2
>   qdisc clsact 0: parent 1:1
>
> This is obviously racy and should be prohibited.  I've started working
> on patches to fix this.  The syz repro for this UAF adds ingress Qdiscs
> under TC_H_ROOT, by the way.


Hmm, didn't realize it was the case.

>
> 2. After introducing RTNL-lockless RTM_{NEW,DEL,GET}TFILTER requests
> [1], it is possible that, when replacing ingress (clsact) Qdiscs, the
> old one can access *miniq_{in,e}gress concurrently with the new one.  For
> example, the syz repro does something like the following:
>
>   Thread 1 creates sch_ingress Qdisc A (containing mini Qdisc a1 and a2),
>   then adds a cls_flower filter X to Qdisc A.
>
>   Thread 2 creates sch_ingress Qdisc B (containing mini Qdisc b1 and b2)
>   to replace Qdisc A, then adds a cls_flower filter Y to Qdisc B.
>
>   Device has 8 TXQs.
>
>  Thread 1               A's refcnt   Thread 2
>   RTM_NEWQDISC (A, locked)    
>    qdisc_create(A)               1
>    qdisc_graft(A)                9
>
>   RTM_NEWTFILTER (X, lockless)
>    __tcf_qdisc_find(A)          10
>    tcf_chain0_head_change(A)
>  ! mini_qdisc_pair_swap(A)           
>             |                        RTM_NEWQDISC (B, locked)
>             |                    2    qdisc_graft(B)
>             |                    1    notify_and_destroy(A)
>             |                                  
>             |                        RTM_NEWTFILTER (Y, lockless)
>             |                         tcf_chain0_head_change(B)
>             |                       ! mini_qdisc_pair_swap(B)
>    tcf_block_release(A)          0             |
>    qdisc_destroy(A)                            |
>    tcf_chain0_head_change_cb_del(A)            |
>  ! mini_qdisc_pair_swap(A)                     |
>             |                                  |
>            ...                                ...
>
> As we can see there're interleaving mini_qdisc_pair_swap() calls between
> Qdisc A and B, causing all kinds of troubles, including the UAF (thread
> 2 writing to mini Qdisc a1's rcu_state after Qdisc A has already been
> freed) reported by syzbot.

Great analysis! However, it is still not quite clear to me how threads 1
and 2 access each other RCU state when q->miniqp is a private memory of
the Qdisc, so 1 should only see A->miniqp and 2 only B->miniqp. And both
miniqps should be protected from deallocation by reference that lockless
RTM_NEWTFILTER obtains.

>
> To fix this, I'm cooking a patch that, when replacing ingress (clsact)
> Qdiscs, in qdisc_graft():
>
>   I.  We should make sure there's no on-the-fly lockless filter requests
>       for the old Qdisc, and return -EBUSY if there's any (or can/should
>       we wait in RTM_NEWQDISC handler?)
>
>   II. We should destory the old Qdisc before publishing the new one
>       (i.e. setting it to dev_ingress_queue(dev)->qdisc_sleeping, so
>       that subsequent filter requests can see it), because
>       {ingress,clsact}_destroy() also call mini_qdisc_pair_swap(), which
>       sets *miniq_{in,e}gress to NULL

Another approach would be to somehow detect concurrent Qdisc replace and
return -EAGAIN from tcf_chain_tp_insert() before calling
tcf_chain0_head_change(). This would leverage existing cls_api
functionality that automatically retries after releasing all references
to chain/tp and obtaining them again instead of messing with qdisc api.
However, since I still didn't fully grasp the issue it is hard for me to
reason whether such approach would be possible to implement in this
case.

>
> Future Qdiscs that support RTNL-lockless cls_ops, if any, won't need
> this fix, as long as their ->chain_head_change() don't access
> out-of-Qdisc-scope data, like pointers in struct net_device.
>
> Do you think this is the right way to go?  Thanks!
>
> [1] Thanks Hillf Danton for the hint:
>     https://syzkaller.appspot.com/text?tag=Patch&x=10d7cd5bc80000
>
> Thanks,
> Peilin Ye

Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[Pedro Tammela]

On 26/04/2023 20:42, Peilin Ye wrote:
> +Cc: Vlad Buslov, Hillf Danton
> 
> Hi all,
> 
> On Mon, Apr 17, 2023 at 04:00:11PM -0700, Peilin Ye wrote:
>> I also reproduced this UAF using the syzkaller reproducer in the report
>> (the C reproducer did not work for me for unknown reasons).  I will look
>> into this.
> 
> Currently, multiple ingress (clsact) Qdiscs can access the per-netdev
> *miniq_ingress (*miniq_egress) pointer concurrently.  This is
> unfortunately true in two senses:
> 
> 1. We allow adding ingress (clsact) Qdiscs under parents other than
> TC_H_INGRESS (TC_H_CLSACT):
> 
>    $ ip link add ifb0 numtxqueues 8 type ifb
>    $ echo clsact > /proc/sys/net/core/default_qdisc
>    $ tc qdisc add dev ifb0 handle 1: root mq
>    $ tc qdisc show dev ifb0
>    qdisc mq 1: root
>    qdisc clsact 0: parent 1:8
>    qdisc clsact 0: parent 1:7
>    qdisc clsact 0: parent 1:6
>    qdisc clsact 0: parent 1:5
>    qdisc clsact 0: parent 1:4
>    qdisc clsact 0: parent 1:3
>    qdisc clsact 0: parent 1:2
>    qdisc clsact 0: parent 1:1
> 
> This is obviously racy and should be prohibited.  I've started working
> on patches to fix this.  The syz repro for this UAF adds ingress Qdiscs
> under TC_H_ROOT, by the way.
> 
> 2. After introducing RTNL-lockless RTM_{NEW,DEL,GET}TFILTER requests
> [1], it is possible that, when replacing ingress (clsact) Qdiscs, the
> old one can access *miniq_{in,e}gress concurrently with the new one.  For
> example, the syz repro does something like the following:
> 
>    Thread 1 creates sch_ingress Qdisc A (containing mini Qdisc a1 and a2),
>    then adds a cls_flower filter X to Qdisc A.
> 
>    Thread 2 creates sch_ingress Qdisc B (containing mini Qdisc b1 and b2)
>    to replace Qdisc A, then adds a cls_flower filter Y to Qdisc B.
> 
>    Device has 8 TXQs.
> 
>   Thread 1               A's refcnt   Thread 2
>    RTM_NEWQDISC (A, locked)
>     qdisc_create(A)               1
>     qdisc_graft(A)                9
> 
>    RTM_NEWTFILTER (X, lockless)
>     __tcf_qdisc_find(A)          10
>     tcf_chain0_head_change(A)
>   ! mini_qdisc_pair_swap(A)
>              |                        RTM_NEWQDISC (B, locked)
>              |                    2    qdisc_graft(B)
>              |                    1    notify_and_destroy(A)
>              |
>              |                        RTM_NEWTFILTER (Y, lockless)
>              |                         tcf_chain0_head_change(B)
>              |                       ! mini_qdisc_pair_swap(B)
>     tcf_block_release(A)          0             |
>     qdisc_destroy(A)                            |
>     tcf_chain0_head_change_cb_del(A)            |
>   ! mini_qdisc_pair_swap(A)                     |
>              |                                  |
>             ...                                ...
> 
> As we can see there're interleaving mini_qdisc_pair_swap() calls between
> Qdisc A and B, causing all kinds of troubles, including the UAF (thread
> 2 writing to mini Qdisc a1's rcu_state after Qdisc A has already been
> freed) reported by syzbot.

Thanks for the analysis. It makes total sense.
After going through the call chains, please correct me if my ELI5 is wrong:

'clsact_init()' is called for B when dev has miniq_ingress set to 'A', 
therefore copying a pointer to the miniq_qdisc with lifetime bound to 
'A' in a miniq_qdisc_pair with lifetime bound to 'B' therefore raising 
an UAF after A is destroyed and B is manipulated.

> 
> To fix this, I'm cooking a patch that, when replacing ingress (clsact)
> Qdiscs, in qdisc_graft():
> 
>    I.  We should make sure there's no on-the-fly lockless filter requests
>        for the old Qdisc, and return -EBUSY if there's any (or can/should
>        we wait in RTM_NEWQDISC handler?
Makes sense.

> 
>    II. We should destory the old Qdisc before publishing the new one
>        (i.e. setting it to dev_ingress_queue(dev)->qdisc_sleeping, so
>        that subsequent filter requests can see it), because
>        {ingress,clsact}_destroy() also call mini_qdisc_pair_swap(), which
>        sets *miniq_{in,e}gress to NULL >
> Future Qdiscs that support RTNL-lockless cls_ops, if any, won't need
> this fix, as long as their ->chain_head_change() don't access
> out-of-Qdisc-scope data, like pointers in struct net_device.

Probably worth a comment somewhere in the code

> 
> Do you think this is the right way to go?  Thanks!
> 
> [1] Thanks Hillf Danton for the hint:
>      https://syzkaller.appspot.com/text?tag=Patch&x=10d7cd5bc80000
> 
> Thanks,
> Peilin Ye
> 

Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[Peilin Ye]

+Cc: Vlad Buslov, Hillf Danton

Hi all,

On Mon, Apr 17, 2023 at 04:00:11PM -0700, Peilin Ye wrote:
> I also reproduced this UAF using the syzkaller reproducer in the report
> (the C reproducer did not work for me for unknown reasons).  I will look
> into this.

Currently, multiple ingress (clsact) Qdiscs can access the per-netdev
*miniq_ingress (*miniq_egress) pointer concurrently.  This is
unfortunately true in two senses:

1. We allow adding ingress (clsact) Qdiscs under parents other than
TC_H_INGRESS (TC_H_CLSACT):

  $ ip link add ifb0 numtxqueues 8 type ifb
  $ echo clsact > /proc/sys/net/core/default_qdisc
  $ tc qdisc add dev ifb0 handle 1: root mq
  $ tc qdisc show dev ifb0
  qdisc mq 1: root
  qdisc clsact 0: parent 1:8
  qdisc clsact 0: parent 1:7
  qdisc clsact 0: parent 1:6
  qdisc clsact 0: parent 1:5
  qdisc clsact 0: parent 1:4
  qdisc clsact 0: parent 1:3
  qdisc clsact 0: parent 1:2
  qdisc clsact 0: parent 1:1

This is obviously racy and should be prohibited.  I've started working
on patches to fix this.  The syz repro for this UAF adds ingress Qdiscs
under TC_H_ROOT, by the way.

2. After introducing RTNL-lockless RTM_{NEW,DEL,GET}TFILTER requests
[1], it is possible that, when replacing ingress (clsact) Qdiscs, the
old one can access *miniq_{in,e}gress concurrently with the new one.  For
example, the syz repro does something like the following:

  Thread 1 creates sch_ingress Qdisc A (containing mini Qdisc a1 and a2),
  then adds a cls_flower filter X to Qdisc A.

  Thread 2 creates sch_ingress Qdisc B (containing mini Qdisc b1 and b2)
  to replace Qdisc A, then adds a cls_flower filter Y to Qdisc B.

  Device has 8 TXQs.

 Thread 1               A's refcnt   Thread 2
  RTM_NEWQDISC (A, locked)    
   qdisc_create(A)               1
   qdisc_graft(A)                9

  RTM_NEWTFILTER (X, lockless)
   __tcf_qdisc_find(A)          10
   tcf_chain0_head_change(A)
 ! mini_qdisc_pair_swap(A)           
            |                        RTM_NEWQDISC (B, locked)
            |                    2    qdisc_graft(B)
            |                    1    notify_and_destroy(A)
            |                                  
            |                        RTM_NEWTFILTER (Y, lockless)
            |                         tcf_chain0_head_change(B)
            |                       ! mini_qdisc_pair_swap(B)
   tcf_block_release(A)          0             |
   qdisc_destroy(A)                            |
   tcf_chain0_head_change_cb_del(A)            |
 ! mini_qdisc_pair_swap(A)                     |
            |                                  |
           ...                                ...

As we can see there're interleaving mini_qdisc_pair_swap() calls between
Qdisc A and B, causing all kinds of troubles, including the UAF (thread
2 writing to mini Qdisc a1's rcu_state after Qdisc A has already been
freed) reported by syzbot.

To fix this, I'm cooking a patch that, when replacing ingress (clsact)
Qdiscs, in qdisc_graft():

  I.  We should make sure there's no on-the-fly lockless filter requests
      for the old Qdisc, and return -EBUSY if there's any (or can/should
      we wait in RTM_NEWQDISC handler?)

  II. We should destory the old Qdisc before publishing the new one
      (i.e. setting it to dev_ingress_queue(dev)->qdisc_sleeping, so
      that subsequent filter requests can see it), because
      {ingress,clsact}_destroy() also call mini_qdisc_pair_swap(), which
      sets *miniq_{in,e}gress to NULL

Future Qdiscs that support RTNL-lockless cls_ops, if any, won't need
this fix, as long as their ->chain_head_change() don't access
out-of-Qdisc-scope data, like pointers in struct net_device.

Do you think this is the right way to go?  Thanks!

[1] Thanks Hillf Danton for the hint:
    https://syzkaller.appspot.com/text?tag=Patch&x=10d7cd5bc80000

Thanks,
Peilin Ye

Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[syzbot]

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

==================================================================
BUG: KASAN: slab-use-after-free in mini_qdisc_pair_swap+0x1c2/0x1f0 net/sched/sch_generic.c:1573
Write of size 8 at addr ffff88806348a308 by task syz-executor.0/8529

CPU: 1 PID: 8529 Comm: syz-executor.0 Not tainted 6.3.0-rc3-syzkaller-00026-gfff5a5e7f528-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:319
 print_report mm/kasan/report.c:430 [inline]
 kasan_report+0x11c/0x130 mm/kasan/report.c:536
 mini_qdisc_pair_swap+0x1c2/0x1f0 net/sched/sch_generic.c:1573
 tcf_chain_head_change_item net/sched/cls_api.c:495 [inline]
 tcf_chain0_head_change.isra.0+0xb9/0x120 net/sched/cls_api.c:509
 tcf_chain_tp_insert net/sched/cls_api.c:1826 [inline]
 tcf_chain_tp_insert_unique net/sched/cls_api.c:1875 [inline]
 tc_new_tfilter+0x1d77/0x2200 net/sched/cls_api.c:2268
 rtnetlink_rcv_msg+0x996/0xd50 net/core/rtnetlink.c:6165
 netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
 netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
 netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
 sock_sendmsg_nosec net/socket.c:724 [inline]
 sock_sendmsg+0xde/0x190 net/socket.c:747
 ____sys_sendmsg+0x334/0x900 net/socket.c:2501
 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2555
 __sys_sendmmsg+0x18f/0x460 net/socket.c:2641
 __do_sys_sendmmsg net/socket.c:2670 [inline]
 __se_sys_sendmmsg net/socket.c:2667 [inline]
 __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2667
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7ffaaee8c0f9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffaafc5e168 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
RAX: ffffffffffffffda RBX: 00007ffaaefac120 RCX: 00007ffaaee8c0f9
RDX: 040000000000009f RSI: 00000000200002c0 RDI: 0000000000000007
RBP: 00007ffaaeee7b39 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffe97997fbf R14: 00007ffaafc5e300 R15: 0000000000022000
 </TASK>

Allocated by task 8524:
 kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 ____kasan_kmalloc mm/kasan/common.c:374 [inline]
 ____kasan_kmalloc mm/kasan/common.c:333 [inline]
 __kasan_kmalloc+0xa2/0xb0 mm/kasan/common.c:383
 kasan_kmalloc include/linux/kasan.h:196 [inline]
 __do_kmalloc_node mm/slab_common.c:967 [inline]
 __kmalloc_node+0x61/0x1a0 mm/slab_common.c:974
 kmalloc_node include/linux/slab.h:610 [inline]
 kzalloc_node include/linux/slab.h:731 [inline]
 qdisc_alloc+0xb0/0xb30 net/sched/sch_generic.c:938
 qdisc_create+0xce/0x1040 net/sched/sch_api.c:1244
 tc_modify_qdisc+0x488/0x1a40 net/sched/sch_api.c:1680
 rtnetlink_rcv_msg+0x43d/0xd50 net/core/rtnetlink.c:6174
 netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
 netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
 netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
 sock_sendmsg_nosec net/socket.c:724 [inline]
 sock_sendmsg+0xde/0x190 net/socket.c:747
 ____sys_sendmsg+0x334/0x900 net/socket.c:2501
 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2555
 __sys_sendmmsg+0x18f/0x460 net/socket.c:2641
 __do_sys_sendmmsg net/socket.c:2670 [inline]
 __se_sys_sendmmsg net/socket.c:2667 [inline]
 __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2667
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Freed by task 21:
 kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 kasan_save_free_info+0x2e/0x40 mm/kasan/generic.c:521
 ____kasan_slab_free mm/kasan/common.c:236 [inline]
 ____kasan_slab_free+0x160/0x1c0 mm/kasan/common.c:200
 kasan_slab_free include/linux/kasan.h:162 [inline]
 slab_free_hook mm/slub.c:1781 [inline]
 slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1807
 slab_free mm/slub.c:3787 [inline]
 __kmem_cache_free+0xaf/0x2d0 mm/slub.c:3800
 rcu_do_batch kernel/rcu/tree.c:2112 [inline]
 rcu_core+0x814/0x1960 kernel/rcu/tree.c:2372
 __do_softirq+0x1d4/0x905 kernel/softirq.c:571

Last potentially related work creation:
 kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
 __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:491
 __call_rcu_common.constprop.0+0x99/0x7e0 kernel/rcu/tree.c:2622
 qdisc_put_unlocked+0x73/0x90 net/sched/sch_generic.c:1097
 tcf_block_release+0x86/0x90 net/sched/cls_api.c:1362
 tc_new_tfilter+0xa2b/0x2200 net/sched/cls_api.c:2333
 rtnetlink_rcv_msg+0x996/0xd50 net/core/rtnetlink.c:6165
 netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
 netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
 netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
 sock_sendmsg_nosec net/socket.c:724 [inline]
 sock_sendmsg+0xde/0x190 net/socket.c:747
 ____sys_sendmsg+0x334/0x900 net/socket.c:2501
 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2555
 __sys_sendmmsg+0x18f/0x460 net/socket.c:2641
 __do_sys_sendmmsg net/socket.c:2670 [inline]
 __se_sys_sendmmsg net/socket.c:2667 [inline]
 __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2667
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Second to last potentially related work creation:
 kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
 __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:491
 __call_rcu_common.constprop.0+0x99/0x7e0 kernel/rcu/tree.c:2622
 rhashtable_rehash_table lib/rhashtable.c:348 [inline]
 rht_deferred_worker+0xb24/0x1ce0 lib/rhashtable.c:432
 process_one_work+0x991/0x15c0 kernel/workqueue.c:2390
 worker_thread+0x669/0x1090 kernel/workqueue.c:2537
 kthread+0x2e8/0x3a0 kernel/kthread.c:376
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308

The buggy address belongs to the object at ffff88806348a000
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 776 bytes inside of
 freed 1024-byte region [ffff88806348a000, ffff88806348a400)

The buggy address belongs to the physical page:
page:ffffea00018d2200 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x63488
head:ffffea00018d2200 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
anon flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000010200 ffff888012441dc0 0000000000000000 dead000000000001
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0x1d20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL), pid 8117, tgid 8111 (syz-executor.3), ts 126042830210, free_ts 15956815362
 prep_new_page mm/page_alloc.c:2552 [inline]
 get_page_from_freelist+0x1190/0x2e20 mm/page_alloc.c:4325
 __alloc_pages+0x1cb/0x4a0 mm/page_alloc.c:5591
 alloc_pages+0x1aa/0x270 mm/mempolicy.c:2283
 alloc_slab_page mm/slub.c:1851 [inline]
 allocate_slab+0x25f/0x390 mm/slub.c:1998
 new_slab mm/slub.c:2051 [inline]
 ___slab_alloc+0xa91/0x1400 mm/slub.c:3193
 __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3292
 __slab_alloc_node mm/slub.c:3345 [inline]
 slab_alloc_node mm/slub.c:3442 [inline]
 __kmem_cache_alloc_node+0x136/0x320 mm/slub.c:3491
 kmalloc_trace+0x26/0xe0 mm/slab_common.c:1061
 kmalloc include/linux/slab.h:580 [inline]
 kzalloc include/linux/slab.h:720 [inline]
 fl_init+0x45/0x2c0 net/sched/cls_flower.c:351
 tcf_proto_create net/sched/cls_api.c:398 [inline]
 tc_new_tfilter+0xecf/0x2200 net/sched/cls_api.c:2260
 rtnetlink_rcv_msg+0x996/0xd50 net/core/rtnetlink.c:6165
 netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
 netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
 netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
 sock_sendmsg_nosec net/socket.c:724 [inline]
 sock_sendmsg+0xde/0x190 net/socket.c:747
 ____sys_sendmsg+0x334/0x900 net/socket.c:2501
page last free stack trace:
 reset_page_owner include/linux/page_owner.h:24 [inline]
 free_pages_prepare mm/page_alloc.c:1453 [inline]
 free_pcp_prepare+0x5d5/0xa50 mm/page_alloc.c:1503
 free_unref_page_prepare mm/page_alloc.c:3387 [inline]
 free_unref_page+0x1d/0x490 mm/page_alloc.c:3482
 free_contig_range+0xb5/0x180 mm/page_alloc.c:9531
 destroy_args+0x6c4/0x920 mm/debug_vm_pgtable.c:1023
 debug_vm_pgtable+0x242a/0x4640 mm/debug_vm_pgtable.c:1403
 do_one_initcall+0x102/0x540 init/main.c:1310
 do_initcall_level init/main.c:1383 [inline]
 do_initcalls init/main.c:1399 [inline]
 do_basic_setup init/main.c:1418 [inline]
 kernel_init_freeable+0x696/0xc00 init/main.c:1638
 kernel_init+0x1e/0x2c0 init/main.c:1526
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308

Memory state around the buggy address:
 ffff88806348a200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff88806348a280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff88806348a300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                      ^
 ffff88806348a380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff88806348a400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================


Tested on:

commit:         fff5a5e7 Merge tag 'for-linus' of git://git.armlinux.o..
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=10cf71c0280000
kernel config:  https://syzkaller.appspot.com/x/.config?x=ea09b0836073ee4
dashboard link: https://syzkaller.appspot.com/bug?extid=b53a9c0d1ea4ad62da8b
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
patch:          https://syzkaller.appspot.com/x/patch.diff?x=16fa5f23c80000

Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[Peilin Ye]

Hi all,

On Mon, Apr 03, 2023 at 11:58:44AM -0400, Jamal Hadi Salim wrote:
> To provide more update:
> Happens on single processor before Seth's patches; and only on
> multi-processor after Seth's patches.
> Theory is: there is a logic bug in the miniqdisc rcu visibility. Feels
> like the freeing of the structure is done without rcu involvement.
> Jiri/Cong maybe you can take a look since youve been dabbling in
> miniqdisc? The reproducer worked for me and Pedro 100% of the time.

I also reproduced this UAF using the syzkaller reproducer in the report
(the C reproducer did not work for me for unknown reasons).  I will look
into this.

Thanks,
Peilin Ye

Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[Jamal Hadi Salim]

To provide more update:
Happens on single processor before Seth's patches; and only on
multi-processor after Seth's patches.
Theory is: there is a logic bug in the miniqdisc rcu visibility. Feels
like the freeing of the structure is done without rcu involvement.
Jiri/Cong maybe you can take a look since youve been dabbling in
miniqdisc? The reproducer worked for me and Pedro 100% of the time.

cheers,
jamal

On Wed, Mar 29, 2023 at 3:07 PM Pedro Tammela <pctammela@mojatatu.com> wrote:
>
> On 29/03/2023 00:37, Seth Forshee wrote:
> > On Tue, Mar 28, 2023 at 06:47:33PM -0700, Jakub Kicinski wrote:
> >> Seth, does this looks related to commit 267463823adb ("net: sch:
> >> eliminate unnecessary RCU waits in mini_qdisc_pair_swap()")
> >> by any chance?
> >
> > I don't see how it could be. The memory being written is part of the
> > qdisc private memory, and tc_new_tfilter() takes a reference to the
> > qdisc. If that memory has been freed doesn't it mean that something has
> > done an unbalanced qdisc_put()?
> >
>
> Reverting Seth's patches (85c0c3eb9a66 and 267463823adb) leads to these
> traces with the reproducer:
> [   52.704956][    C0] ------------[ cut here ]------------
> [   52.705568][    C0] ODEBUG: free active (active state 1) object:0
> [   52.706542][    C0] WARNING: CPU: 0 PID: 0 at lib/debugobjects.c0
> [   52.707283][    C0] Modules linked in:
> [   52.707602][    C0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.0
> [   52.708304][    C0] Hardware name: QEMU Standard PC (i440FX + PI4
> [   52.709032][    C0] RIP: 0010:debug_print_object+0x196/0x290
> [   52.709509][    C0] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85e
> [   52.711011][    C0] RSP: 0018:ffffc90000007cd0 EFLAGS: 00010282
> [   52.711510][    C0] RAX: 0000000000000000 RBX: 0000000000000003 0
> [   52.712125][    C0] RDX: ffffffff8c495800 RSI: ffffffff814b96d7 1
> [   52.712748][    C0] RBP: 0000000000000001 R08: 0000000000000001 0
> [   52.713370][    C0] R10: 0000000000000000 R11: 203a47554245444f 0
> [   52.713983][    C0] R13: ffffffff8aa6e960 R14: 0000000000000000 8
> [   52.714609][    C0] FS:  0000000000000000(0000) GS:ffff8881f5a000
> [   52.715356][    C0] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008003
> [   52.715863][    C0] CR2: 000055914686f020 CR3: 000000011e856000 0
> [   52.716486][    C0] Call Trace:
> [   52.716742][    C0]  <IRQ>
> [   52.716969][    C0]  debug_check_no_obj_freed+0x302/0x420
> [   52.717423][    C0]  slab_free_freelist_hook+0xec/0x1c0
> [   52.717848][    C0]  ? rcu_core+0x818/0x1930
> [   52.718204][    C0]  __kmem_cache_free+0xaf/0x2e0
> [   52.718590][    C0]  rcu_core+0x818/0x1930
> [   52.718938][    C0]  ? rcu_report_dead+0x610/0x610
> [   52.719328][    C0]  __do_softirq+0x1d4/0x8ef
> [   52.719689][    C0]  __irq_exit_rcu+0x11d/0x190
> [   52.720062][    C0]  irq_exit_rcu+0x9/0x20
> [   52.720402][    C0]  sysvec_apic_timer_interrupt+0x97/0xc0
> [   52.720842][    C0]  </IRQ>
> [   52.721070][    C0]  <TASK>
> [   52.721300][    C0]  asm_sysvec_apic_timer_interrupt+0x1a/0x20
> [   52.721779][    C0] RIP: 0010:default_idle+0xf/0x20
> [   52.722172][    C0] Code: 89 07 49 c7 c0 08 00 00 00 4d 29 c8 4c5
> [   52.723631][    C0] RSP: 0018:ffffffff8c407e30 EFLAGS: 00000202
> [   52.724096][    C0] RAX: 000000000007897f RBX: 0000000000000000 6
> [   52.724702][    C0] RDX: 0000000000000000 RSI: 0000000000000001 0
> [   52.725335][    C0] RBP: ffffffff8c495800 R08: 0000000000000001 b
> [   52.725957][    C0] R10: ffffed103eb46d95 R11: 0000000000000000 0
> [   52.726550][    C0] R13: 0000000000000000 R14: ffffffff8e7834d0 0
> [   52.727162][    C0]  ? ct_kernel_exit+0x1d6/0x240
> [   52.727542][    C0]  default_idle_call+0x67/0xa0
> [   52.727912][    C0]  do_idle+0x31e/0x3e0
> [   52.728241][    C0]  ? arch_cpu_idle_exit+0x30/0x30
> [   52.728635][    C0]  cpu_startup_entry+0x18/0x20
> [   52.729006][    C0]  rest_init+0x16d/0x2b0
> [   52.729338][    C0]  ? regulator_has_full_constraints+0x9/0x20
> [   52.729815][    C0]  ? trace_init_perf_perm_irq_work_exit+0x20/00
> [   52.730309][    C0]  arch_call_rest_init+0x13/0x30
> [   52.730703][    C0]  start_kernel+0x352/0x4c0
> [   52.731087][    C0]  secondary_startup_64_no_verify+0xce/0xdb
> [   52.731611][    C0]  </TASK>
> [   52.731870][    C0] Kernel panic - not syncing: kernel: panic_on.
> [   52.732445][    C0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.0
> [   52.733140][    C0] Hardware name: QEMU Standard PC (i440FX + PI4
> [   52.733867][    C0] Call Trace:
> [   52.734143][    C0]  <IRQ>
> [   52.734380][    C0]  dump_stack_lvl+0xd9/0x150
> [   52.734769][    C0]  panic+0x684/0x730
> [   52.735082][    C0]  ? panic_smp_self_stop+0x90/0x90
> [   52.735322][    C0]  ? show_trace_log_lvl+0x285/0x390
> [   52.735322][    C0]  ? debug_print_object+0x196/0x290
> [   52.735322][    C0]  check_panic_on_warn+0xb1/0xc0
> [   52.735322][    C0]  __warn+0xf2/0x390
> [   52.735322][    C0]  ? debug_print_object+0x196/0x290
> [   52.735322][    C0]  report_bug+0x2dd/0x500
> [   52.735322][    C0]  handle_bug+0x3c/0x70
> [   52.735322][    C0]  exc_invalid_op+0x18/0x50
> [   52.735322][    C0]  asm_exc_invalid_op+0x1a/0x20
> [   52.735322][    C0] RIP: 0010:debug_print_object+0x196/0x290
> [   52.735322][    C0] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85e
> [   52.735322][    C0] RSP: 0018:ffffc90000007cd0 EFLAGS: 00010282
> [   52.735322][    C0] RAX: 0000000000000000 RBX: 0000000000000003 0
> [   52.735322][    C0] RDX: ffffffff8c495800 RSI: ffffffff814b96d7 1
> [   52.735322][    C0] RBP: 0000000000000001 R08: 0000000000000001 0
> [   52.735322][    C0] R10: 0000000000000000 R11: 203a47554245444f 0
> [   52.735322][    C0] R13: ffffffff8aa6e960 R14: 0000000000000000 8
> [   52.735322][    C0]  ? __warn_printk+0x187/0x310
> [   52.735322][    C0]  debug_check_no_obj_freed+0x302/0x420
> [   52.735322][    C0]  slab_free_freelist_hook+0xec/0x1c0
> [   52.735322][    C0]  ? rcu_core+0x818/0x1930
> [   52.735322][    C0]  __kmem_cache_free+0xaf/0x2e0
> [   52.735322][    C0]  rcu_core+0x818/0x1930
> [   52.735322][    C0]  ? rcu_report_dead+0x610/0x610
> [   52.735322][    C0]  __do_softirq+0x1d4/0x8ef
> [   52.735322][    C0]  __irq_exit_rcu+0x11d/0x190
> [   52.735322][    C0]  irq_exit_rcu+0x9/0x20
> [   52.735322][    C0]  sysvec_apic_timer_interrupt+0x97/0xc0
> [   52.735322][    C0]  </IRQ>
> [   52.735322][    C0]  <TASK>
> [   52.735322][    C0]  asm_sysvec_apic_timer_interrupt+0x1a/0x20
> [   52.735322][    C0] RIP: 0010:default_idle+0xf/0x20
> [   52.735322][    C0] Code: 89 07 49 c7 c0 08 00 00 00 4d 29 c8 4c5
> [   52.735322][    C0] RSP: 0018:ffffffff8c407e30 EFLAGS: 00000202
> [   52.735322][    C0] RAX: 000000000007897f RBX: 0000000000000000 6
> [   52.735322][    C0] RDX: 0000000000000000 RSI: 0000000000000001 0
> [   52.735322][    C0] RBP: ffffffff8c495800 R08: 0000000000000001 b
> [   52.735322][    C0] R10: ffffed103eb46d95 R11: 0000000000000000 0
> [   52.735322][    C0] R13: 0000000000000000 R14: ffffffff8e7834d0 0
> [   52.735322][    C0]  ? ct_kernel_exit+0x1d6/0x240
> [   52.735322][    C0]  default_idle_call+0x67/0xa0
> [   52.735322][    C0]  do_idle+0x31e/0x3e0
> [   52.735322][    C0]  ? arch_cpu_idle_exit+0x30/0x30
> [   52.735322][    C0]  cpu_startup_entry+0x18/0x20
> [   52.735322][    C0]  rest_init+0x16d/0x2b0
> [   52.735322][    C0]  ? regulator_has_full_constraints+0x9/0x20
> [   52.735322][    C0]  ? trace_init_perf_perm_irq_work_exit+0x20/00
> [   52.735322][    C0]  arch_call_rest_init+0x13/0x30
> [   52.735322][    C0]  start_kernel+0x352/0x4c0
> [   52.735322][    C0]  secondary_startup_64_no_verify+0xce/0xdb
> [   52.735322][    C0]  </TASK>
> [   52.735322][    C0] Kernel Offset: disabled
> [   52.735322][    C0] Rebooting in 86400 seconds..
>
>

Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[Pedro Tammela]

On 29/03/2023 00:37, Seth Forshee wrote:
> On Tue, Mar 28, 2023 at 06:47:33PM -0700, Jakub Kicinski wrote:
>> Seth, does this looks related to commit 267463823adb ("net: sch:
>> eliminate unnecessary RCU waits in mini_qdisc_pair_swap()")
>> by any chance?
> 
> I don't see how it could be. The memory being written is part of the
> qdisc private memory, and tc_new_tfilter() takes a reference to the
> qdisc. If that memory has been freed doesn't it mean that something has
> done an unbalanced qdisc_put()?
> 

Reverting Seth's patches (85c0c3eb9a66 and 267463823adb) leads to these 
traces with the reproducer:
[   52.704956][    C0] ------------[ cut here ]------------
[   52.705568][    C0] ODEBUG: free active (active state 1) object:0
[   52.706542][    C0] WARNING: CPU: 0 PID: 0 at lib/debugobjects.c0
[   52.707283][    C0] Modules linked in:
[   52.707602][    C0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.0
[   52.708304][    C0] Hardware name: QEMU Standard PC (i440FX + PI4
[   52.709032][    C0] RIP: 0010:debug_print_object+0x196/0x290
[   52.709509][    C0] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85e
[   52.711011][    C0] RSP: 0018:ffffc90000007cd0 EFLAGS: 00010282
[   52.711510][    C0] RAX: 0000000000000000 RBX: 0000000000000003 0
[   52.712125][    C0] RDX: ffffffff8c495800 RSI: ffffffff814b96d7 1
[   52.712748][    C0] RBP: 0000000000000001 R08: 0000000000000001 0
[   52.713370][    C0] R10: 0000000000000000 R11: 203a47554245444f 0
[   52.713983][    C0] R13: ffffffff8aa6e960 R14: 0000000000000000 8
[   52.714609][    C0] FS:  0000000000000000(0000) GS:ffff8881f5a000
[   52.715356][    C0] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008003
[   52.715863][    C0] CR2: 000055914686f020 CR3: 000000011e856000 0
[   52.716486][    C0] Call Trace:
[   52.716742][    C0]  <IRQ>
[   52.716969][    C0]  debug_check_no_obj_freed+0x302/0x420
[   52.717423][    C0]  slab_free_freelist_hook+0xec/0x1c0
[   52.717848][    C0]  ? rcu_core+0x818/0x1930
[   52.718204][    C0]  __kmem_cache_free+0xaf/0x2e0
[   52.718590][    C0]  rcu_core+0x818/0x1930
[   52.718938][    C0]  ? rcu_report_dead+0x610/0x610
[   52.719328][    C0]  __do_softirq+0x1d4/0x8ef
[   52.719689][    C0]  __irq_exit_rcu+0x11d/0x190
[   52.720062][    C0]  irq_exit_rcu+0x9/0x20
[   52.720402][    C0]  sysvec_apic_timer_interrupt+0x97/0xc0
[   52.720842][    C0]  </IRQ>
[   52.721070][    C0]  <TASK>
[   52.721300][    C0]  asm_sysvec_apic_timer_interrupt+0x1a/0x20
[   52.721779][    C0] RIP: 0010:default_idle+0xf/0x20
[   52.722172][    C0] Code: 89 07 49 c7 c0 08 00 00 00 4d 29 c8 4c5
[   52.723631][    C0] RSP: 0018:ffffffff8c407e30 EFLAGS: 00000202
[   52.724096][    C0] RAX: 000000000007897f RBX: 0000000000000000 6
[   52.724702][    C0] RDX: 0000000000000000 RSI: 0000000000000001 0
[   52.725335][    C0] RBP: ffffffff8c495800 R08: 0000000000000001 b
[   52.725957][    C0] R10: ffffed103eb46d95 R11: 0000000000000000 0
[   52.726550][    C0] R13: 0000000000000000 R14: ffffffff8e7834d0 0
[   52.727162][    C0]  ? ct_kernel_exit+0x1d6/0x240
[   52.727542][    C0]  default_idle_call+0x67/0xa0
[   52.727912][    C0]  do_idle+0x31e/0x3e0
[   52.728241][    C0]  ? arch_cpu_idle_exit+0x30/0x30
[   52.728635][    C0]  cpu_startup_entry+0x18/0x20
[   52.729006][    C0]  rest_init+0x16d/0x2b0
[   52.729338][    C0]  ? regulator_has_full_constraints+0x9/0x20
[   52.729815][    C0]  ? trace_init_perf_perm_irq_work_exit+0x20/00
[   52.730309][    C0]  arch_call_rest_init+0x13/0x30
[   52.730703][    C0]  start_kernel+0x352/0x4c0
[   52.731087][    C0]  secondary_startup_64_no_verify+0xce/0xdb
[   52.731611][    C0]  </TASK>
[   52.731870][    C0] Kernel panic - not syncing: kernel: panic_on.
[   52.732445][    C0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.0
[   52.733140][    C0] Hardware name: QEMU Standard PC (i440FX + PI4
[   52.733867][    C0] Call Trace:
[   52.734143][    C0]  <IRQ>
[   52.734380][    C0]  dump_stack_lvl+0xd9/0x150
[   52.734769][    C0]  panic+0x684/0x730
[   52.735082][    C0]  ? panic_smp_self_stop+0x90/0x90
[   52.735322][    C0]  ? show_trace_log_lvl+0x285/0x390
[   52.735322][    C0]  ? debug_print_object+0x196/0x290
[   52.735322][    C0]  check_panic_on_warn+0xb1/0xc0
[   52.735322][    C0]  __warn+0xf2/0x390
[   52.735322][    C0]  ? debug_print_object+0x196/0x290
[   52.735322][    C0]  report_bug+0x2dd/0x500
[   52.735322][    C0]  handle_bug+0x3c/0x70
[   52.735322][    C0]  exc_invalid_op+0x18/0x50
[   52.735322][    C0]  asm_exc_invalid_op+0x1a/0x20
[   52.735322][    C0] RIP: 0010:debug_print_object+0x196/0x290
[   52.735322][    C0] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85e
[   52.735322][    C0] RSP: 0018:ffffc90000007cd0 EFLAGS: 00010282
[   52.735322][    C0] RAX: 0000000000000000 RBX: 0000000000000003 0
[   52.735322][    C0] RDX: ffffffff8c495800 RSI: ffffffff814b96d7 1
[   52.735322][    C0] RBP: 0000000000000001 R08: 0000000000000001 0
[   52.735322][    C0] R10: 0000000000000000 R11: 203a47554245444f 0
[   52.735322][    C0] R13: ffffffff8aa6e960 R14: 0000000000000000 8
[   52.735322][    C0]  ? __warn_printk+0x187/0x310
[   52.735322][    C0]  debug_check_no_obj_freed+0x302/0x420
[   52.735322][    C0]  slab_free_freelist_hook+0xec/0x1c0
[   52.735322][    C0]  ? rcu_core+0x818/0x1930
[   52.735322][    C0]  __kmem_cache_free+0xaf/0x2e0
[   52.735322][    C0]  rcu_core+0x818/0x1930
[   52.735322][    C0]  ? rcu_report_dead+0x610/0x610
[   52.735322][    C0]  __do_softirq+0x1d4/0x8ef
[   52.735322][    C0]  __irq_exit_rcu+0x11d/0x190
[   52.735322][    C0]  irq_exit_rcu+0x9/0x20
[   52.735322][    C0]  sysvec_apic_timer_interrupt+0x97/0xc0
[   52.735322][    C0]  </IRQ>
[   52.735322][    C0]  <TASK>
[   52.735322][    C0]  asm_sysvec_apic_timer_interrupt+0x1a/0x20
[   52.735322][    C0] RIP: 0010:default_idle+0xf/0x20
[   52.735322][    C0] Code: 89 07 49 c7 c0 08 00 00 00 4d 29 c8 4c5
[   52.735322][    C0] RSP: 0018:ffffffff8c407e30 EFLAGS: 00000202
[   52.735322][    C0] RAX: 000000000007897f RBX: 0000000000000000 6
[   52.735322][    C0] RDX: 0000000000000000 RSI: 0000000000000001 0
[   52.735322][    C0] RBP: ffffffff8c495800 R08: 0000000000000001 b
[   52.735322][    C0] R10: ffffed103eb46d95 R11: 0000000000000000 0
[   52.735322][    C0] R13: 0000000000000000 R14: ffffffff8e7834d0 0
[   52.735322][    C0]  ? ct_kernel_exit+0x1d6/0x240
[   52.735322][    C0]  default_idle_call+0x67/0xa0
[   52.735322][    C0]  do_idle+0x31e/0x3e0
[   52.735322][    C0]  ? arch_cpu_idle_exit+0x30/0x30
[   52.735322][    C0]  cpu_startup_entry+0x18/0x20
[   52.735322][    C0]  rest_init+0x16d/0x2b0
[   52.735322][    C0]  ? regulator_has_full_constraints+0x9/0x20
[   52.735322][    C0]  ? trace_init_perf_perm_irq_work_exit+0x20/00
[   52.735322][    C0]  arch_call_rest_init+0x13/0x30
[   52.735322][    C0]  start_kernel+0x352/0x4c0
[   52.735322][    C0]  secondary_startup_64_no_verify+0xce/0xdb
[   52.735322][    C0]  </TASK>
[   52.735322][    C0] Kernel Offset: disabled
[   52.735322][    C0] Rebooting in 86400 seconds..

Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[Seth Forshee]

On Tue, Mar 28, 2023 at 06:47:33PM -0700, Jakub Kicinski wrote:
> Seth, does this looks related to commit 267463823adb ("net: sch:
> eliminate unnecessary RCU waits in mini_qdisc_pair_swap()")
> by any chance?

I don't see how it could be. The memory being written is part of the
qdisc private memory, and tc_new_tfilter() takes a reference to the
qdisc. If that memory has been freed doesn't it mean that something has
done an unbalanced qdisc_put()?

> On Thu, 23 Mar 2023 17:52:40 -0700 syzbot wrote:
> > Hello,
> > 
> > syzbot found the following issue on:
> > 
> > HEAD commit:    fff5a5e7f528 Merge tag 'for-linus' of git://git.armlinux.o..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=11884731c80000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=aaa4b45720ca0519
> > dashboard link: https://syzkaller.appspot.com/bug?extid=b53a9c0d1ea4ad62da8b
> > compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=15d1497ac80000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11eed636c80000
> > 
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/33a184f98b9d/disk-fff5a5e7.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/3d75f967571e/vmlinux-fff5a5e7.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/4eeb8edbdc7e/bzImage-fff5a5e7.xz
> > 
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+b53a9c0d1ea4ad62da8b@syzkaller.appspotmail.com
> > 
> > ==================================================================
> > BUG: KASAN: slab-use-after-free in mini_qdisc_pair_swap+0x1c2/0x1f0 net/sched/sch_generic.c:1573
> > Write of size 8 at addr ffff888045b31308 by task syz-executor690/14901
> > 
> > CPU: 0 PID: 14901 Comm: syz-executor690 Not tainted 6.3.0-rc3-syzkaller-00026-gfff5a5e7f528 #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
> > Call Trace:
> >  <TASK>
> >  __dump_stack lib/dump_stack.c:88 [inline]
> >  dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
> >  print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:319
> >  print_report mm/kasan/report.c:430 [inline]
> >  kasan_report+0x11c/0x130 mm/kasan/report.c:536
> >  mini_qdisc_pair_swap+0x1c2/0x1f0 net/sched/sch_generic.c:1573
> >  tcf_chain_head_change_item net/sched/cls_api.c:495 [inline]
> >  tcf_chain0_head_change.isra.0+0xb9/0x120 net/sched/cls_api.c:509
> >  tcf_chain_tp_insert net/sched/cls_api.c:1826 [inline]
> >  tcf_chain_tp_insert_unique net/sched/cls_api.c:1875 [inline]
> >  tc_new_tfilter+0x1de6/0x2290 net/sched/cls_api.c:2266
> >  rtnetlink_rcv_msg+0x996/0xd50 net/core/rtnetlink.c:6165
> >  netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
> >  netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
> >  netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
> >  netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
> >  sock_sendmsg_nosec net/socket.c:724 [inline]
> >  sock_sendmsg+0xde/0x190 net/socket.c:747
> >  ____sys_sendmsg+0x334/0x900 net/socket.c:2501
> >  ___sys_sendmsg+0x110/0x1b0 net/socket.c:2555
> >  __sys_sendmmsg+0x18f/0x460 net/socket.c:2641
> >  __do_sys_sendmmsg net/socket.c:2670 [inline]
> >  __se_sys_sendmmsg net/socket.c:2667 [inline]
> >  __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2667
> >  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> >  do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
> >  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> > RIP: 0033:0x7f4f11222579
> > Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 31 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> > RSP: 002b:00007f4f11184208 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
> > RAX: ffffffffffffffda RBX: 00007f4f112ab2a8 RCX: 00007f4f11222579
> > RDX: 040000000000009f RSI: 00000000200002c0 RDI: 0000000000000007
> > RBP: 00007f4f112ab2a0 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4f112ab2ac
> > R13: 00007fffc8e5214f R14: 00007f4f11184300 R15: 0000000000022000
> >  </TASK>
> > 
> > Allocated by task 14898:
> >  kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
> >  kasan_set_track+0x25/0x30 mm/kasan/common.c:52
> >  ____kasan_kmalloc mm/kasan/common.c:374 [inline]
> >  ____kasan_kmalloc mm/kasan/common.c:333 [inline]
> >  __kasan_kmalloc+0xa2/0xb0 mm/kasan/common.c:383
> >  kasan_kmalloc include/linux/kasan.h:196 [inline]
> >  __do_kmalloc_node mm/slab_common.c:967 [inline]
> >  __kmalloc_node+0x61/0x1a0 mm/slab_common.c:974
> >  kmalloc_node include/linux/slab.h:610 [inline]
> >  kzalloc_node include/linux/slab.h:731 [inline]
> >  qdisc_alloc+0xb0/0xb30 net/sched/sch_generic.c:938
> >  qdisc_create+0xce/0x1040 net/sched/sch_api.c:1244
> >  tc_modify_qdisc+0x488/0x1a40 net/sched/sch_api.c:1680
> >  rtnetlink_rcv_msg+0x43d/0xd50 net/core/rtnetlink.c:6174
> >  netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
> >  netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
> >  netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
> >  netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
> >  sock_sendmsg_nosec net/socket.c:724 [inline]
> >  sock_sendmsg+0xde/0x190 net/socket.c:747
> >  ____sys_sendmsg+0x334/0x900 net/socket.c:2501
> >  ___sys_sendmsg+0x110/0x1b0 net/socket.c:2555
> >  __sys_sendmmsg+0x18f/0x460 net/socket.c:2641
> >  __do_sys_sendmmsg net/socket.c:2670 [inline]
> >  __se_sys_sendmmsg net/socket.c:2667 [inline]
> >  __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2667
> >  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> >  do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
> >  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> > 
> > Freed by task 21:
> >  kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
> >  kasan_set_track+0x25/0x30 mm/kasan/common.c:52
> >  kasan_save_free_info+0x2e/0x40 mm/kasan/generic.c:521
> >  ____kasan_slab_free mm/kasan/common.c:236 [inline]
> >  ____kasan_slab_free+0x160/0x1c0 mm/kasan/common.c:200
> >  kasan_slab_free include/linux/kasan.h:162 [inline]
> >  slab_free_hook mm/slub.c:1781 [inline]
> >  slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1807
> >  slab_free mm/slub.c:3787 [inline]
> >  __kmem_cache_free+0xaf/0x2d0 mm/slub.c:3800
> >  rcu_do_batch kernel/rcu/tree.c:2112 [inline]
> >  rcu_core+0x814/0x1960 kernel/rcu/tree.c:2372
> >  __do_softirq+0x1d4/0x905 kernel/softirq.c:571
> > 
> > Last potentially related work creation:
> >  kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
> >  __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:491
> >  __call_rcu_common.constprop.0+0x99/0x7e0 kernel/rcu/tree.c:2622
> >  qdisc_put_unlocked+0x73/0x90 net/sched/sch_generic.c:1097
> >  tcf_block_release+0x86/0x90 net/sched/cls_api.c:1362
> >  tc_new_tfilter+0xa35/0x2290 net/sched/cls_api.c:2331
> >  rtnetlink_rcv_msg+0x996/0xd50 net/core/rtnetlink.c:6165
> >  netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
> >  netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
> >  netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
> >  netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
> >  sock_sendmsg_nosec net/socket.c:724 [inline]
> >  sock_sendmsg+0xde/0x190 net/socket.c:747
> >  ____sys_sendmsg+0x334/0x900 net/socket.c:2501
> >  ___sys_sendmsg+0x110/0x1b0 net/socket.c:2555
> >  __sys_sendmmsg+0x18f/0x460 net/socket.c:2641
> >  __do_sys_sendmmsg net/socket.c:2670 [inline]
> >  __se_sys_sendmmsg net/socket.c:2667 [inline]
> >  __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2667
> >  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> >  do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
> >  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> > 
> > The buggy address belongs to the object at ffff888045b31000
> >  which belongs to the cache kmalloc-1k of size 1024
> > The buggy address is located 776 bytes inside of
> >  freed 1024-byte region [ffff888045b31000, ffff888045b31400)
> > 
> > The buggy address belongs to the physical page:
> > page:ffffea000116cc00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888045b37000 pfn:0x45b30
> > head:ffffea000116cc00 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> > anon flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
> > raw: 00fff00000010200 ffff888012441dc0 0000000000000000 dead000000000001
> > raw: ffff888045b37000 000000008010000d 00000001ffffffff 0000000000000000
> > page dumped because: kasan: bad access detected
> > page_owner tracks the page as allocated
> > page last allocated via order 3, migratetype Unmovable, gfp_mask 0x1d20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL), pid 14184, tgid 14168 (syz-executor690), ts 420322459064, free_ts 15493742100
> >  prep_new_page mm/page_alloc.c:2552 [inline]
> >  get_page_from_freelist+0x1190/0x2e20 mm/page_alloc.c:4325
> >  __alloc_pages+0x1cb/0x4a0 mm/page_alloc.c:5591
> >  alloc_pages+0x1aa/0x270 mm/mempolicy.c:2283
> >  alloc_slab_page mm/slub.c:1851 [inline]
> >  allocate_slab+0x25f/0x390 mm/slub.c:1998
> >  new_slab mm/slub.c:2051 [inline]
> >  ___slab_alloc+0xa91/0x1400 mm/slub.c:3193
> >  __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3292
> >  __slab_alloc_node mm/slub.c:3345 [inline]
> >  slab_alloc_node mm/slub.c:3442 [inline]
> >  __kmem_cache_alloc_node+0x136/0x320 mm/slub.c:3491
> >  kmalloc_trace+0x26/0xe0 mm/slab_common.c:1061
> >  kmalloc include/linux/slab.h:580 [inline]
> >  kmalloc_array include/linux/slab.h:635 [inline]
> >  kcalloc include/linux/slab.h:667 [inline]
> >  fl_change+0x1cf/0x4ac0 net/sched/cls_flower.c:2175
> >  tc_new_tfilter+0x97c/0x2290 net/sched/cls_api.c:2310
> >  rtnetlink_rcv_msg+0x996/0xd50 net/core/rtnetlink.c:6165
> >  netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
> >  netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
> >  netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
> >  netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
> >  sock_sendmsg_nosec net/socket.c:724 [inline]
> >  sock_sendmsg+0xde/0x190 net/socket.c:747
> >  ____sys_sendmsg+0x334/0x900 net/socket.c:2501
> > page last free stack trace:
> >  reset_page_owner include/linux/page_owner.h:24 [inline]
> >  free_pages_prepare mm/page_alloc.c:1453 [inline]
> >  free_pcp_prepare+0x5d5/0xa50 mm/page_alloc.c:1503
> >  free_unref_page_prepare mm/page_alloc.c:3387 [inline]
> >  free_unref_page+0x1d/0x490 mm/page_alloc.c:3482
> >  free_contig_range+0xb5/0x180 mm/page_alloc.c:9531
> >  destroy_args+0x6c4/0x920 mm/debug_vm_pgtable.c:1023
> >  debug_vm_pgtable+0x242a/0x4640 mm/debug_vm_pgtable.c:1403
> >  do_one_initcall+0x102/0x540 init/main.c:1310
> >  do_initcall_level init/main.c:1383 [inline]
> >  do_initcalls init/main.c:1399 [inline]
> >  do_basic_setup init/main.c:1418 [inline]
> >  kernel_init_freeable+0x696/0xc00 init/main.c:1638
> >  kernel_init+0x1e/0x2c0 init/main.c:1526
> >  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
> > 
> > Memory state around the buggy address:
> >  ffff888045b31200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >  ffff888045b31280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > >ffff888045b31300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb  
> >                       ^
> >  ffff888045b31380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >  ffff888045b31400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ==================================================================
> > 
> > 
> > ---
> > This report 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 issue. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> > syzbot can test patches for this issue, for details see:
> > https://goo.gl/tpsmEJ#testing-patches
> 

Re: [syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[Jakub Kicinski]

Seth, does this looks related to commit 267463823adb ("net: sch:
eliminate unnecessary RCU waits in mini_qdisc_pair_swap()")
by any chance?

On Thu, 23 Mar 2023 17:52:40 -0700 syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    fff5a5e7f528 Merge tag 'for-linus' of git://git.armlinux.o..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=11884731c80000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=aaa4b45720ca0519
> dashboard link: https://syzkaller.appspot.com/bug?extid=b53a9c0d1ea4ad62da8b
> compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=15d1497ac80000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11eed636c80000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/33a184f98b9d/disk-fff5a5e7.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/3d75f967571e/vmlinux-fff5a5e7.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/4eeb8edbdc7e/bzImage-fff5a5e7.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+b53a9c0d1ea4ad62da8b@syzkaller.appspotmail.com
> 
> ==================================================================
> BUG: KASAN: slab-use-after-free in mini_qdisc_pair_swap+0x1c2/0x1f0 net/sched/sch_generic.c:1573
> Write of size 8 at addr ffff888045b31308 by task syz-executor690/14901
> 
> CPU: 0 PID: 14901 Comm: syz-executor690 Not tainted 6.3.0-rc3-syzkaller-00026-gfff5a5e7f528 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
> Call Trace:
>  <TASK>
>  __dump_stack lib/dump_stack.c:88 [inline]
>  dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
>  print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:319
>  print_report mm/kasan/report.c:430 [inline]
>  kasan_report+0x11c/0x130 mm/kasan/report.c:536
>  mini_qdisc_pair_swap+0x1c2/0x1f0 net/sched/sch_generic.c:1573
>  tcf_chain_head_change_item net/sched/cls_api.c:495 [inline]
>  tcf_chain0_head_change.isra.0+0xb9/0x120 net/sched/cls_api.c:509
>  tcf_chain_tp_insert net/sched/cls_api.c:1826 [inline]
>  tcf_chain_tp_insert_unique net/sched/cls_api.c:1875 [inline]
>  tc_new_tfilter+0x1de6/0x2290 net/sched/cls_api.c:2266
>  rtnetlink_rcv_msg+0x996/0xd50 net/core/rtnetlink.c:6165
>  netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
>  netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
>  netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
>  netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
>  sock_sendmsg_nosec net/socket.c:724 [inline]
>  sock_sendmsg+0xde/0x190 net/socket.c:747
>  ____sys_sendmsg+0x334/0x900 net/socket.c:2501
>  ___sys_sendmsg+0x110/0x1b0 net/socket.c:2555
>  __sys_sendmmsg+0x18f/0x460 net/socket.c:2641
>  __do_sys_sendmmsg net/socket.c:2670 [inline]
>  __se_sys_sendmmsg net/socket.c:2667 [inline]
>  __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2667
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> RIP: 0033:0x7f4f11222579
> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 31 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f4f11184208 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
> RAX: ffffffffffffffda RBX: 00007f4f112ab2a8 RCX: 00007f4f11222579
> RDX: 040000000000009f RSI: 00000000200002c0 RDI: 0000000000000007
> RBP: 00007f4f112ab2a0 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4f112ab2ac
> R13: 00007fffc8e5214f R14: 00007f4f11184300 R15: 0000000000022000
>  </TASK>
> 
> Allocated by task 14898:
>  kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
>  kasan_set_track+0x25/0x30 mm/kasan/common.c:52
>  ____kasan_kmalloc mm/kasan/common.c:374 [inline]
>  ____kasan_kmalloc mm/kasan/common.c:333 [inline]
>  __kasan_kmalloc+0xa2/0xb0 mm/kasan/common.c:383
>  kasan_kmalloc include/linux/kasan.h:196 [inline]
>  __do_kmalloc_node mm/slab_common.c:967 [inline]
>  __kmalloc_node+0x61/0x1a0 mm/slab_common.c:974
>  kmalloc_node include/linux/slab.h:610 [inline]
>  kzalloc_node include/linux/slab.h:731 [inline]
>  qdisc_alloc+0xb0/0xb30 net/sched/sch_generic.c:938
>  qdisc_create+0xce/0x1040 net/sched/sch_api.c:1244
>  tc_modify_qdisc+0x488/0x1a40 net/sched/sch_api.c:1680
>  rtnetlink_rcv_msg+0x43d/0xd50 net/core/rtnetlink.c:6174
>  netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
>  netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
>  netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
>  netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
>  sock_sendmsg_nosec net/socket.c:724 [inline]
>  sock_sendmsg+0xde/0x190 net/socket.c:747
>  ____sys_sendmsg+0x334/0x900 net/socket.c:2501
>  ___sys_sendmsg+0x110/0x1b0 net/socket.c:2555
>  __sys_sendmmsg+0x18f/0x460 net/socket.c:2641
>  __do_sys_sendmmsg net/socket.c:2670 [inline]
>  __se_sys_sendmmsg net/socket.c:2667 [inline]
>  __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2667
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> 
> Freed by task 21:
>  kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
>  kasan_set_track+0x25/0x30 mm/kasan/common.c:52
>  kasan_save_free_info+0x2e/0x40 mm/kasan/generic.c:521
>  ____kasan_slab_free mm/kasan/common.c:236 [inline]
>  ____kasan_slab_free+0x160/0x1c0 mm/kasan/common.c:200
>  kasan_slab_free include/linux/kasan.h:162 [inline]
>  slab_free_hook mm/slub.c:1781 [inline]
>  slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1807
>  slab_free mm/slub.c:3787 [inline]
>  __kmem_cache_free+0xaf/0x2d0 mm/slub.c:3800
>  rcu_do_batch kernel/rcu/tree.c:2112 [inline]
>  rcu_core+0x814/0x1960 kernel/rcu/tree.c:2372
>  __do_softirq+0x1d4/0x905 kernel/softirq.c:571
> 
> Last potentially related work creation:
>  kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
>  __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:491
>  __call_rcu_common.constprop.0+0x99/0x7e0 kernel/rcu/tree.c:2622
>  qdisc_put_unlocked+0x73/0x90 net/sched/sch_generic.c:1097
>  tcf_block_release+0x86/0x90 net/sched/cls_api.c:1362
>  tc_new_tfilter+0xa35/0x2290 net/sched/cls_api.c:2331
>  rtnetlink_rcv_msg+0x996/0xd50 net/core/rtnetlink.c:6165
>  netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
>  netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
>  netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
>  netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
>  sock_sendmsg_nosec net/socket.c:724 [inline]
>  sock_sendmsg+0xde/0x190 net/socket.c:747
>  ____sys_sendmsg+0x334/0x900 net/socket.c:2501
>  ___sys_sendmsg+0x110/0x1b0 net/socket.c:2555
>  __sys_sendmmsg+0x18f/0x460 net/socket.c:2641
>  __do_sys_sendmmsg net/socket.c:2670 [inline]
>  __se_sys_sendmmsg net/socket.c:2667 [inline]
>  __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2667
>  do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>  do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> 
> The buggy address belongs to the object at ffff888045b31000
>  which belongs to the cache kmalloc-1k of size 1024
> The buggy address is located 776 bytes inside of
>  freed 1024-byte region [ffff888045b31000, ffff888045b31400)
> 
> The buggy address belongs to the physical page:
> page:ffffea000116cc00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888045b37000 pfn:0x45b30
> head:ffffea000116cc00 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
> anon flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
> raw: 00fff00000010200 ffff888012441dc0 0000000000000000 dead000000000001
> raw: ffff888045b37000 000000008010000d 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
> page_owner tracks the page as allocated
> page last allocated via order 3, migratetype Unmovable, gfp_mask 0x1d20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL), pid 14184, tgid 14168 (syz-executor690), ts 420322459064, free_ts 15493742100
>  prep_new_page mm/page_alloc.c:2552 [inline]
>  get_page_from_freelist+0x1190/0x2e20 mm/page_alloc.c:4325
>  __alloc_pages+0x1cb/0x4a0 mm/page_alloc.c:5591
>  alloc_pages+0x1aa/0x270 mm/mempolicy.c:2283
>  alloc_slab_page mm/slub.c:1851 [inline]
>  allocate_slab+0x25f/0x390 mm/slub.c:1998
>  new_slab mm/slub.c:2051 [inline]
>  ___slab_alloc+0xa91/0x1400 mm/slub.c:3193
>  __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3292
>  __slab_alloc_node mm/slub.c:3345 [inline]
>  slab_alloc_node mm/slub.c:3442 [inline]
>  __kmem_cache_alloc_node+0x136/0x320 mm/slub.c:3491
>  kmalloc_trace+0x26/0xe0 mm/slab_common.c:1061
>  kmalloc include/linux/slab.h:580 [inline]
>  kmalloc_array include/linux/slab.h:635 [inline]
>  kcalloc include/linux/slab.h:667 [inline]
>  fl_change+0x1cf/0x4ac0 net/sched/cls_flower.c:2175
>  tc_new_tfilter+0x97c/0x2290 net/sched/cls_api.c:2310
>  rtnetlink_rcv_msg+0x996/0xd50 net/core/rtnetlink.c:6165
>  netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
>  netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
>  netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
>  netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
>  sock_sendmsg_nosec net/socket.c:724 [inline]
>  sock_sendmsg+0xde/0x190 net/socket.c:747
>  ____sys_sendmsg+0x334/0x900 net/socket.c:2501
> page last free stack trace:
>  reset_page_owner include/linux/page_owner.h:24 [inline]
>  free_pages_prepare mm/page_alloc.c:1453 [inline]
>  free_pcp_prepare+0x5d5/0xa50 mm/page_alloc.c:1503
>  free_unref_page_prepare mm/page_alloc.c:3387 [inline]
>  free_unref_page+0x1d/0x490 mm/page_alloc.c:3482
>  free_contig_range+0xb5/0x180 mm/page_alloc.c:9531
>  destroy_args+0x6c4/0x920 mm/debug_vm_pgtable.c:1023
>  debug_vm_pgtable+0x242a/0x4640 mm/debug_vm_pgtable.c:1403
>  do_one_initcall+0x102/0x540 init/main.c:1310
>  do_initcall_level init/main.c:1383 [inline]
>  do_initcalls init/main.c:1399 [inline]
>  do_basic_setup init/main.c:1418 [inline]
>  kernel_init_freeable+0x696/0xc00 init/main.c:1638
>  kernel_init+0x1e/0x2c0 init/main.c:1526
>  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
> 
> Memory state around the buggy address:
>  ffff888045b31200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  ffff888045b31280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >ffff888045b31300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb  
>                       ^
>  ffff888045b31380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  ffff888045b31400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
> 
> 
> ---
> This report 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 issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches

[syzbot] [net?] KASAN: slab-use-after-free Write in mini_qdisc_pair_swap

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    fff5a5e7f528 Merge tag 'for-linus' of git://git.armlinux.o..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=11884731c80000
kernel config:  https://syzkaller.appspot.com/x/.config?x=aaa4b45720ca0519
dashboard link: https://syzkaller.appspot.com/bug?extid=b53a9c0d1ea4ad62da8b
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=15d1497ac80000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=11eed636c80000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/33a184f98b9d/disk-fff5a5e7.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/3d75f967571e/vmlinux-fff5a5e7.xz
kernel image: https://storage.googleapis.com/syzbot-assets/4eeb8edbdc7e/bzImage-fff5a5e7.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+b53a9c0d1ea4ad62da8b@syzkaller.appspotmail.com

==================================================================
BUG: KASAN: slab-use-after-free in mini_qdisc_pair_swap+0x1c2/0x1f0 net/sched/sch_generic.c:1573
Write of size 8 at addr ffff888045b31308 by task syz-executor690/14901

CPU: 0 PID: 14901 Comm: syz-executor690 Not tainted 6.3.0-rc3-syzkaller-00026-gfff5a5e7f528 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:319
 print_report mm/kasan/report.c:430 [inline]
 kasan_report+0x11c/0x130 mm/kasan/report.c:536
 mini_qdisc_pair_swap+0x1c2/0x1f0 net/sched/sch_generic.c:1573
 tcf_chain_head_change_item net/sched/cls_api.c:495 [inline]
 tcf_chain0_head_change.isra.0+0xb9/0x120 net/sched/cls_api.c:509
 tcf_chain_tp_insert net/sched/cls_api.c:1826 [inline]
 tcf_chain_tp_insert_unique net/sched/cls_api.c:1875 [inline]
 tc_new_tfilter+0x1de6/0x2290 net/sched/cls_api.c:2266
 rtnetlink_rcv_msg+0x996/0xd50 net/core/rtnetlink.c:6165
 netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
 netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
 netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
 sock_sendmsg_nosec net/socket.c:724 [inline]
 sock_sendmsg+0xde/0x190 net/socket.c:747
 ____sys_sendmsg+0x334/0x900 net/socket.c:2501
 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2555
 __sys_sendmmsg+0x18f/0x460 net/socket.c:2641
 __do_sys_sendmmsg net/socket.c:2670 [inline]
 __se_sys_sendmmsg net/socket.c:2667 [inline]
 __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2667
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7f4f11222579
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 31 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f4f11184208 EFLAGS: 00000246 ORIG_RAX: 0000000000000133
RAX: ffffffffffffffda RBX: 00007f4f112ab2a8 RCX: 00007f4f11222579
RDX: 040000000000009f RSI: 00000000200002c0 RDI: 0000000000000007
RBP: 00007f4f112ab2a0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4f112ab2ac
R13: 00007fffc8e5214f R14: 00007f4f11184300 R15: 0000000000022000
 </TASK>

Allocated by task 14898:
 kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 ____kasan_kmalloc mm/kasan/common.c:374 [inline]
 ____kasan_kmalloc mm/kasan/common.c:333 [inline]
 __kasan_kmalloc+0xa2/0xb0 mm/kasan/common.c:383
 kasan_kmalloc include/linux/kasan.h:196 [inline]
 __do_kmalloc_node mm/slab_common.c:967 [inline]
 __kmalloc_node+0x61/0x1a0 mm/slab_common.c:974
 kmalloc_node include/linux/slab.h:610 [inline]
 kzalloc_node include/linux/slab.h:731 [inline]
 qdisc_alloc+0xb0/0xb30 net/sched/sch_generic.c:938
 qdisc_create+0xce/0x1040 net/sched/sch_api.c:1244
 tc_modify_qdisc+0x488/0x1a40 net/sched/sch_api.c:1680
 rtnetlink_rcv_msg+0x43d/0xd50 net/core/rtnetlink.c:6174
 netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
 netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
 netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
 sock_sendmsg_nosec net/socket.c:724 [inline]
 sock_sendmsg+0xde/0x190 net/socket.c:747
 ____sys_sendmsg+0x334/0x900 net/socket.c:2501
 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2555
 __sys_sendmmsg+0x18f/0x460 net/socket.c:2641
 __do_sys_sendmmsg net/socket.c:2670 [inline]
 __se_sys_sendmmsg net/socket.c:2667 [inline]
 __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2667
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Freed by task 21:
 kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
 kasan_set_track+0x25/0x30 mm/kasan/common.c:52
 kasan_save_free_info+0x2e/0x40 mm/kasan/generic.c:521
 ____kasan_slab_free mm/kasan/common.c:236 [inline]
 ____kasan_slab_free+0x160/0x1c0 mm/kasan/common.c:200
 kasan_slab_free include/linux/kasan.h:162 [inline]
 slab_free_hook mm/slub.c:1781 [inline]
 slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1807
 slab_free mm/slub.c:3787 [inline]
 __kmem_cache_free+0xaf/0x2d0 mm/slub.c:3800
 rcu_do_batch kernel/rcu/tree.c:2112 [inline]
 rcu_core+0x814/0x1960 kernel/rcu/tree.c:2372
 __do_softirq+0x1d4/0x905 kernel/softirq.c:571

Last potentially related work creation:
 kasan_save_stack+0x22/0x40 mm/kasan/common.c:45
 __kasan_record_aux_stack+0xbc/0xd0 mm/kasan/generic.c:491
 __call_rcu_common.constprop.0+0x99/0x7e0 kernel/rcu/tree.c:2622
 qdisc_put_unlocked+0x73/0x90 net/sched/sch_generic.c:1097
 tcf_block_release+0x86/0x90 net/sched/cls_api.c:1362
 tc_new_tfilter+0xa35/0x2290 net/sched/cls_api.c:2331
 rtnetlink_rcv_msg+0x996/0xd50 net/core/rtnetlink.c:6165
 netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
 netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
 netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
 sock_sendmsg_nosec net/socket.c:724 [inline]
 sock_sendmsg+0xde/0x190 net/socket.c:747
 ____sys_sendmsg+0x334/0x900 net/socket.c:2501
 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2555
 __sys_sendmmsg+0x18f/0x460 net/socket.c:2641
 __do_sys_sendmmsg net/socket.c:2670 [inline]
 __se_sys_sendmmsg net/socket.c:2667 [inline]
 __x64_sys_sendmmsg+0x9d/0x100 net/socket.c:2667
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd

The buggy address belongs to the object at ffff888045b31000
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 776 bytes inside of
 freed 1024-byte region [ffff888045b31000, ffff888045b31400)

The buggy address belongs to the physical page:
page:ffffea000116cc00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888045b37000 pfn:0x45b30
head:ffffea000116cc00 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
anon flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff)
raw: 00fff00000010200 ffff888012441dc0 0000000000000000 dead000000000001
raw: ffff888045b37000 000000008010000d 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Unmovable, gfp_mask 0x1d20c0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL), pid 14184, tgid 14168 (syz-executor690), ts 420322459064, free_ts 15493742100
 prep_new_page mm/page_alloc.c:2552 [inline]
 get_page_from_freelist+0x1190/0x2e20 mm/page_alloc.c:4325
 __alloc_pages+0x1cb/0x4a0 mm/page_alloc.c:5591
 alloc_pages+0x1aa/0x270 mm/mempolicy.c:2283
 alloc_slab_page mm/slub.c:1851 [inline]
 allocate_slab+0x25f/0x390 mm/slub.c:1998
 new_slab mm/slub.c:2051 [inline]
 ___slab_alloc+0xa91/0x1400 mm/slub.c:3193
 __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3292
 __slab_alloc_node mm/slub.c:3345 [inline]
 slab_alloc_node mm/slub.c:3442 [inline]
 __kmem_cache_alloc_node+0x136/0x320 mm/slub.c:3491
 kmalloc_trace+0x26/0xe0 mm/slab_common.c:1061
 kmalloc include/linux/slab.h:580 [inline]
 kmalloc_array include/linux/slab.h:635 [inline]
 kcalloc include/linux/slab.h:667 [inline]
 fl_change+0x1cf/0x4ac0 net/sched/cls_flower.c:2175
 tc_new_tfilter+0x97c/0x2290 net/sched/cls_api.c:2310
 rtnetlink_rcv_msg+0x996/0xd50 net/core/rtnetlink.c:6165
 netlink_rcv_skb+0x165/0x440 net/netlink/af_netlink.c:2574
 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]
 netlink_unicast+0x547/0x7f0 net/netlink/af_netlink.c:1365
 netlink_sendmsg+0x925/0xe30 net/netlink/af_netlink.c:1942
 sock_sendmsg_nosec net/socket.c:724 [inline]
 sock_sendmsg+0xde/0x190 net/socket.c:747
 ____sys_sendmsg+0x334/0x900 net/socket.c:2501
page last free stack trace:
 reset_page_owner include/linux/page_owner.h:24 [inline]
 free_pages_prepare mm/page_alloc.c:1453 [inline]
 free_pcp_prepare+0x5d5/0xa50 mm/page_alloc.c:1503
 free_unref_page_prepare mm/page_alloc.c:3387 [inline]
 free_unref_page+0x1d/0x490 mm/page_alloc.c:3482
 free_contig_range+0xb5/0x180 mm/page_alloc.c:9531
 destroy_args+0x6c4/0x920 mm/debug_vm_pgtable.c:1023
 debug_vm_pgtable+0x242a/0x4640 mm/debug_vm_pgtable.c:1403
 do_one_initcall+0x102/0x540 init/main.c:1310
 do_initcall_level init/main.c:1383 [inline]
 do_initcalls init/main.c:1399 [inline]
 do_basic_setup init/main.c:1418 [inline]
 kernel_init_freeable+0x696/0xc00 init/main.c:1638
 kernel_init+0x1e/0x2c0 init/main.c:1526
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308

Memory state around the buggy address:
 ffff888045b31200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888045b31280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888045b31300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                      ^
 ffff888045b31380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888045b31400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================


---
This report 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 issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches