Re: [syzbot] [keyrings?] [lsm?] WARNING in __mod_timer

[Thomas Gleixner <tglx@linutronix.de>]

On Sun, Feb 26 2023 at 19:55, syzbot wrote:
> ODEBUG: assert_init not available (active state 0) object: ffffffff8d4fcbc0 object type: timer_list hint: key_gc_timer_func+0x0/0x80 security/keys/gc.c:117

>  WARNING: CPU: 1 PID: 10646 at lib/debugobjects.c:512 debug_object_assert_init+0x1f2/0x240 lib/debugobjects.c:899
>  debug_assert_init kernel/time/timer.c:837 [inline]
>  __mod_timer+0x10d/0xf40 kernel/time/timer.c:1020
>  key_reject_and_link+0x3f5/0x6e0 security/keys/key.c:610
>  key_negate_and_link include/linux/key-type.h:187 [inline]
>  complete_request_key security/keys/request_key.c:64 [inline]
>  call_sbin_request_key+0xa7b/0xcd0 security/keys/request_key.c:213
>  construct_key security/keys/request_key.c:244 [inline]
>  construct_key_and_link security/keys/request_key.c:503 [inline]
>  request_key_and_link+0x11e3/0x18e0 security/keys/request_key.c:637
>  __do_sys_request_key security/keys/keyctl.c:222 [inline]
>  __se_sys_request_key+0x271/0x3b0 security/keys/keyctl.c:167

This is odd. The timer object is statically allocated via
DEFINE_TIMER(). That macro sets

       timer.entry.next = TIMER_ENTRY_STATIC

which is used to detect statically allocated timer objects via
timer_is_static_object() and that checks for:

     timer.entry.pprev == NULL && timer.entry.next == TIMER_ENTRY_STATIC

The only function which touches key_gc_timer is

    key_reject_and_link()
      mod_timer()
        __mod_timer()
          debug_assert_init()
            debug_timer_assert_init()
              debug_object_assert_init()
                if (!lookup_object()) {
                   if (!check_for_static_object()) <- Invokes timer_is_static_object()
                      WARN()

If this is the first invocation of mod_timer(&key_gc_timer,...) then
key_gc_timer is corrupted.

If this is not the first invocation of mod_timer(&key_gc_timer,...) then
the debugobjects hash is corrupted.

Either way neither the timer code nor debugobjects have been changed
since the 6.2 release and certainly are innocent here.

That smells like a nasty memory corruption issue and the two other
syzbot reports which arrived in my filtered inbox:

 https://lore.kernel.org/all/000000000000d7894b05f5924787@google.com
 https://lore.kernel.org/all/000000000000840dae05f5a7fb53@google.com

point to memory corruption as well.

The first one has a C reproducer. Can that be used for bisection?

Thanks,

        tglx