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]
Message-ID: <CAOU40uAaFoZxyfW+c=nU-9At69JpwGW2_rvU9CEGQtfbAebMAQ@mail.gmail.com>
Date: Thu, 20 Nov 2025 12:56:34 +0800
From: Xianying Wang <wangxianying546@...il.com>
To: akpm@...ux-foundation.org
Cc: linux-kernel@...r.kernel.org
Subject: [BUG] WARNING in ___ratelimit

Hi,

I encountered a reproducible kernel WARNING in
___ratelimit()(lib/ratelimit.c)when fuzzing the sysctl interface using
syzkaller on Linux v6.17 and v6.18-rc2.This warning can be triggered
by writing a negative value into kernel.printk_ratelimit and then
generating audit messages that go through kauditd_printk_skb().

The reproducer does the following:

Write -1 to /proc/sys/kernel/printk_ratelimit:

echo -1 > /proc/sys/kernel/printk_ratelimit

(In my case this is done via a syzkaller pseudo-syscall:

syz_proc_sys_generated_322(..., 0xffffffffffffffff, ...),

which passes -1 to write_sysctl("/proc/sys/kernel/printk_ratelimit", ...).)

Trigger SELinux/audit activity that results in audit messages being
printed from the kauditd thread. For example:

open /proc/ /map_files via procfs, and

use fcntl(F_NOTIFY, ...) on that directory

The "kernel.printk_ratelimit" sysctl is backed by
printk_ratelimit_state.interval and uses proc_dointvec_jiffies as the
handler. This means that writing a negative value through the sysctl
will store a negative value (in jiffies) directly into
printk_ratelimit_state.interval.

It seems we should either reject negative values in the
kernel.printk_ratelimit sysctl (enforcing interval >= 0), or treat
negative values in a way that does not result in a WARN in
___ratelimit().

This can be reproduced on:

HEAD commit:

e5f0a698b34ed76002dc5cff3804a61c80233a7a

6fab32bb6508abbb8b7b1c5498e44f0c32320ed5

report: https://pastebin.com/raw/k0gcxLCT

console output : https://pastebin.com/raw/uPSJQxu0

console output v6.17.0:https://pastebin.com/raw/QyWeays9

kernel config : https://pastebin.com/raw/1grwrT16

C reproducer :https://pastebin.com/raw/72azKduF

Let me know if you need more details or testing.

Best regards,

Xianying

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ