linux-kernel - Re: [PATCH] locking/lockdep: fix null-ptr-deref in check_prev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 18 Nov 2022 11:17:21 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Yang Yingliang <yangyingliang@...wei.com>
Cc:     linux-kernel@...r.kernel.org, mingo@...hat.com, will@...nel.org,
        longman@...hat.com, boqun.feng@...il.com, bvanassche@....org
Subject: Re: [PATCH] locking/lockdep: fix null-ptr-deref in check_prev_add()

On Fri, Nov 18, 2022 at 04:31:02PM +0800, Yang Yingliang wrote:
> I got a null-ptr-deref report as following:
> 
> general protection fault, probably for non-canonical address 0xdffffc0000000008: 0000 [#1] PREEMPT SMP KASAN PTI
> KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047]
> CPU: 0 PID: 500 Comm: systemd-udevd Tainted: G        W          6.1.0-rc5-00144-gabd8ea84ca72-dirty #1320
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
> RIP: 0010:check_prevs_add+0x2f8/0x2780
> Call Trace:
>  <TASK>
>  __lock_acquire+0x2ae8/0x3d60
>  lock_acquire+0x195/0x4e0
>  fs_reclaim_acquire+0x119/0x160
>  kmem_cache_alloc_node+0x47/0x310
>  __alloc_skb+0x205/0x2d0
>  devlink_compat_running_version+0x10b/0x6a0
>  dev_ethtool+0x285/0x380
>  dev_ioctl+0x16c/0xff0
>  sock_do_ioctl+0x1ae/0x220
>  sock_ioctl+0x55f/0x600
>  __x64_sys_ioctl+0x156/0x1d0
>  do_syscall_64+0x37/0x90
>  entry_SYSCALL_64_after_hwframe+0x63/0xcd
> 
> If in use bit of lock_class is not set, hlock_class() returns NULL,

Why is that a valid premise?

That is; you think it is OK for a held_lock to not have an in-use
lock_class?

I'm thinking there's more to this problem you found.