linux-kernel - BUG: unable to handle kernel NULL pointer dereference in _find_first

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>] [day] [month] [year] [list]

Date:   Mon, 30 Oct 2023 20:26:41 +0900
From:   "Dae R. Jeong" <threeearcat@...il.com>
To:     brauner@...nel.org, mcgrof@...nel.org, dhowells@...hat.com,
        nick.alcock@...cle.com, code@...dh.me, ddiss@...e.de,
        linux-kernel@...r.kernel.org
Cc:     ywchoi@...ys.kaist.ac.kr
Subject: BUG: unable to handle kernel NULL pointer dereference in
 _find_first_bit

Hello,

It seems watch_queue_set_size() and post_one_notification() miss
memory barriers, potentially causing a kernel crash in the following
scenario:

CPU0                           CPU1
watch_queue_set_size()         post_one_notification()
-----                          -----
wqueue->notes_bitmap;
wqueue->nr_notes = nr_notes;
                               // In find_first_bit()
                               // In _find_first_bit()
                               for (idx = 0;
                                    idx * BITS_PER_LONG < wqueue->nr_notes;
                                    idx++) {
                                   wqueue->notes_bitmap[idx];
                               }

In the above scenario, it seems that nothing prevents reordering of
accesses to wqueue->notes_bitmap and wqueue->nr_notes in both
functions.

Our research prototype found the following issue, which seems to be
due to the above scenario.

BUG: kernel NULL pointer dereference, address: 0000000000000000
<...>
 _find_first_bit+0x18d/0x1a0 lib/find_bit.c:101
 find_first_bit include/linux/find.h:208 [inline]
 post_one_notification+0x197/0xbd0 kernel/watch_queue.c:115
 __post_watch_notification+0x5ac/0x1080 kernel/watch_queue.c:225
 post_watch_notification include/linux/watch_queue.h:108 [inline]
 notify_key security/keys/internal.h:197 [inline]
 __key_update security/keys/key.c:775 [inline]
 __key_create_or_update+0xec0/0xfb0 security/keys/key.c:968
 key_create_or_update+0x3e/0x50 security/keys/key.c:1011
 __do_sys_add_key security/keys/keyctl.c:134 [inline]
 __se_sys_add_key+0x2f3/0x3f0 security/keys/keyctl.c:74
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x50/0xa0 arch/x86/entry/common.c:82
 entry_SYSCALL_64_after_hwframe+0x63/0xcd


Please note that this issue is found by a research prototype which
significantly transforms a kernel binary. So, I can't guarantee that
the issue is not a false positive, although I tried my best to
analyze and understand the issue.


Best regards,
Dae R. Jeong