Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
On Mon, 15 Apr 2024 14:17:10 +0200, =?utf-8?B?0KHRgtGA0LDRhdC40ZrQsCDQoNCw0LTQu NGb?= wrote: > Just to clarify, this particular instance of this issue seems to be related t > o > terminfo. > > In general, as I stated earlier, the log message > > ... [program_name]: vfprintf %s NULL in "[format_string]" > > is output whenever NULL is passed to the *printf family of functions. That > could be vfprintf, but also printf, fprintf, sprintf... and so on and so fort > h. > The inconvenient part of this otherwise very useful mechanism of detecting > incorrect code is that there is no precise indication of the location in the > source code which is incorrectly written in this manner. It could be the > program itself, or it could be one of the libraries it uses, as is likely the > case here. The only clue is the format string in the message, which could be > not distinctive enough. I believe this is fixed by: CVSROOT:/cvs Module name:src Changes by: mill...@cvs.openbsd.org 2024/04/12 08:10:28 Modified files: lib/libcurses/tinfo: read_entry.c Log message: Avoid snprintf() of NULL when _nc_get_source() returns NULL. The filename buffer is not actually used in this case but it is safer to set it to the empty string than to leave it uninitialized. OK tb@
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
On Mon, Apr 15, 2024 at 02:25:04AM +, Jeremy Mates wrote: > TL;DR it's TERMINFO related or when ~/.terminfo exists and no TERM file > exists therein. Also trying to read "none" (or maybe also "none.db" when > the TERMINFO thing happens) from the current working directory might not > be a good idea, if an attacker can put naughty things into either of > those files and a sh or ksh or whatever is run in a suitable directory? > hi. i have actually been seeing these for months, but just ignored them. i'm not sure your theory covers everything though: $ echo $TERM wsvt25 $ ls -l ~/.terminfo/w total 12 -r--r--r-- 1 jmc jmc 1597 Apr 15 06:27 wsvt25 -rw-r--r-- 1 jmc jmc 1522 Aug 1 2020 wsvt25-noacs -rw-r--r-- 1 jmc jmc 865 Aug 1 2020 wsvt25-ul $ tail /var/log/messages Apr 15 06:56:21 manila reorder_kernel: kernel relinking done Apr 15 06:57:03 manila -ksh: vfprintf %s NULL in "%.*s" Apr 15 06:57:17 manila last message repeated 4 times Apr 15 06:57:17 manila ksh: vfprintf %s NULL in "%.*s" Apr 15 06:57:17 manila mutt: vfprintf %s NULL in "%.*s" Apr 15 06:57:42 manila -ksh: vfprintf %s NULL in "%.*s" Apr 15 06:59:12 manila sh: vfprintf %s NULL in "%.*s" Apr 15 06:59:12 manila vim: vfprintf %s NULL in "%.*s" Apr 15 07:00:18 manila ksh: vfprintf %s NULL in "%.*s" Apr 15 07:02:35 manila ksh: vfprintf %s NULL in "%.*s" that's basically me logging in, starting tmux (4 shells+mutt). so i'm not sure it's exactly as you describe. curious... jmc
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
Дана 24/04/15 02:25AM, Jeremy Mates написа: > TL;DR it's TERMINFO related or when ~/.terminfo exists and no TERM file > exists therein. Also trying to read "none" (or maybe also "none.db" when > the TERMINFO thing happens) from the current working directory might not > be a good idea, if an attacker can put naughty things into either of > those files and a sh or ksh or whatever is run in a suitable directory? Just to clarify, this particular instance of this issue seems to be related to terminfo. In general, as I stated earlier, the log message ... [program_name]: vfprintf %s NULL in "[format_string]" is output whenever NULL is passed to the *printf family of functions. That could be vfprintf, but also printf, fprintf, sprintf... and so on and so forth. The inconvenient part of this otherwise very useful mechanism of detecting incorrect code is that there is no precise indication of the location in the source code which is incorrectly written in this manner. It could be the program itself, or it could be one of the libraries it uses, as is likely the case here. The only clue is the format string in the message, which could be not distinctive enough.
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
TL;DR it's TERMINFO related or when ~/.terminfo exists and no TERM file
exists therein. Also trying to read "none" (or maybe also "none.db" when
the TERMINFO thing happens) from the current working directory might not
be a good idea, if an attacker can put naughty things into either of
those files and a sh or ksh or whatever is run in a suitable directory?
On 2024-04-08 15:30:11 +, Jeremy Mates wrote:
> 79510 ksh NAMI "none.db"
> 79510 ksh RET open -1 errno 2 No such file or directory
> 79510 ksh CALL mprotect(0x4e89f6c1000,0x1000,0x3)
> 79510 ksh RET mprotect 0
> 79510 ksh CALL mprotect(0x4e89f6c1000,0x1000,0x1)
> 79510 ksh RET mprotect 0
> 79510 ksh CALL open(0x744b97b1eed0,0x1)
> 79510 ksh NAMI "none"
> 79510 ksh RET open -1 errno 2 No such file or directory
> 79510 ksh CALL sendsyslog(0x744b97b1c140,35,0<>)
> 79510 ksh GIO fd -1 wrote 35 bytes
>"<10>ksh: vfprintf %s NULL in "%.*s""
There are two instances of "none" in the ncurses code; setting TERMPATH
to "" and recompiling results in hits for ".db" in my custom
(and very incomplete) ~/.terminfo directory where to tigger this error
~/.terminfo/r/rxvt-unicode-256color does not exist, but that file does
exist in /usr/share/terminfo (and also /usr/local/share/terminfo but
that looks to be last in the list and is not consulted).
62759 rogueCALL fcntl(1,F_ISATTY)
62759 rogueRET fcntl 1
... (various kbind calls removed)
62759 rogueCALL issetugid()
62759 rogueRET issetugid 0
...
62759 rogueCALL issetugid()
62759 rogueRET issetugid 0
...
62759 rogueCALL stat(0xbd1b58b8700,0xbd1b5893c00)
62759 rogueNAMI "/home/jmates/.terminfo"
62759 rogueSTRU struct stat { dev=1035, ino=9504797, mode=drwx--
, nlink=5, uid=1000<"jmates">, gid=1000<"jmates">, rdev=37949602,
atime=1664240431<"Sep 27 01:00:31 2022">.902138053, mtime=1713140694<"Apr 15
00:24:54 2024">.605888358, ctime=1713140694<"Apr 15 00:24:54 2024">.605888358,
size=512, blocks=8, blksize=32768, flags=0x0, gen=0x0 }
62759 rogueRET stat 0
62759 rogueCALL stat(0xbd1b58b8717,0xbd1b5893c80)
62759 rogueNAMI "/usr/share/terminfo"
62759 rogueSTRU struct stat { dev=1029, ino=77975, mode=drwxr-xr-x ,
nlink=44, uid=0<"root">, gid=0<"wheel">, rdev=347089, atime=1710969405<"Mar 20
21:16:45 2024">, mtime=1710969405<"Mar 20 21:16:45 2024">,
ctime=1712330397<"Apr 5 15:19:57 2024">.280403075, size=1024, blocks=4,
blksize=16384, flags=0x0, gen=0x0 }
62759 rogueRET stat 0
62759 rogueCALL stat(0xbd1b58b872b,0xbd1b5893d00)
62759 rogueNAMI "/usr/local/share/terminfo"
62759 rogueSTRU struct stat { dev=1031, ino=1398, mode=drwxr-xr-x ,
nlink=4, uid=0<"root">, gid=0<"wheel">, rdev=27828, atime=1664242579<"Sep 27
01:36:19 2022">.894146606, mtime=1699341912<"Nov 7 07:25:12 2023">.868578098,
ctime=1699341912<"Nov 7 07:25:12 2023">.868578098, size=512, blocks=4,
blksize=16384, flags=0x0, gen=0x0 }
62759 rogueRET stat 0
62759 rogueCALL stat(0xbd1b58b8759,0xbd1b5893d80)
62759 rogueNAMI ""
62759 rogueRET stat -1 errno 2 No such file or directory
...
62759 rogueCALL stat(0xbd1b58b8700,0x798526d4f508)
62759 rogueNAMI "/home/jmates/.terminfo"
62759 rogueSTRU struct stat { dev=1035, ino=9504797, mode=drwx--
, nlink=5, uid=1000<"jmates">, gid=1000<"jmates">, rdev=37949602,
atime=1664240431<"Sep 27 01:00:31 2022">.902138053, mtime=1713140694<"Apr 15
00:24:54 2024">.605888358, ctime=1713140694<"Apr 15 00:24:54 2024">.605888358,
size=512, blocks=8, blksize=32768, flags=0x0, gen=0x0 }
62759 rogueRET stat 0
...
62759 rogueCALL access(0x798526d57640,0x4)
62759 rogueNAMI "/home/jmates/.terminfo/r/rxvt-unicode-256color"
62759 rogueRET access -1 errno 2 No such file or directory
...
62759 rogueCALL issetugid()
62759 rogueRET issetugid 0
62759 rogueCALL issetugid()
62759 rogueRET issetugid 0
...
62759 rogueCALL issetugid()
62759 rogueRET issetugid 0
...
62759 rogueCALL open(0x798526d4b960,0x1)
62759 rogueNAMI ".db"
62759 rogueRET open -1 errno 2 No such file or directory
62759 rogueCALL
mprotect(0xbd21fb19000,0x1000,0x3)
62759 rogueRET mprotect 0
62759 rogueCALL mprotect(0xbd21fb19000,0x1000,0x1)
62759 rogueRET mprotect 0
62759 rogueCALL open(0x798526d4f230,0x1)
62759 rogueNAMI ""
62759 rogueRET open -1 errno 2 No such file or directory
...
62759 rogueCALL sendsyslog(0x798526d4c4a0,37,0<>)
62759 rogueGIO fd -1 wrote 37 bytes
"<10>rogue: vfprintf %s NULL in "%.*s""
62759 rogueRET
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
On Thu, Apr 11, 2024 at 10:10:20AM +0200, Eivind Eide wrote: It is possible that I have missed important context here, but with a bare environment with only essentials like $HOME defined and no ~/.terminfo directory (as opposed to an empty one), do the odd messages still appear? After rm -rf ~/.terminfo/ the message is gone (regardless of environmental variables). FWIW I'm getting a lot more of the same messages without ~/.terminfo than with. I'm using kitty (the terminal) to log into openbsd using ssh, and I've been distributing ~/.terminfo/x/xterm-kitty (and using TERM=xterm-kitty). Starting with 7.5 I was suddenly seeing weird characters appear when using tmux (where TERM=tmux-256color) on openbsd. Copying /usr/share/terminfo/t/tmux-256color to ~/.terminfo/t/tmux-256color seemed to solved this. With this setup I've been seeing maybe 2x 'sh: vfprintf %s NULL in "%.*s"' in /var/log/messages a day. Removing ~/.terminfo entirely (and installing kitty so I have a working terminfo) immediately started throwing *a lot* more of those lines into /var/log/messages, with a lot of other prefixes. The messages stop again if I copy back ~/.terminfo/x/xterm-kitty (and t/tmux-256color when using tmux), though I'll probably still get the occasional one, as before. -- Dennis Eriksen
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
> It is possible that I have missed important context here, but with a > bare environment with only essentials like $HOME defined and no > ~/.terminfo directory (as opposed to an empty one), do the odd messages > still appear? After rm -rf ~/.terminfo/ the message is gone (regardless of environmental variables). -- Eivind Eide "ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD" - Oceania Association of Autonomous Astronauts
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
On Thu, Apr 11, 2024 at 09:41:47AM +0200, Eivind Eide wrote: > > HOME="/home/eivind" > > That's the environmental variable that triggers the message if an > empty ~/.terminfo/ directory is present in my home. It is possible that I have missed important context here, but with a bare environment with only essentials like $HOME defined and no ~/.terminfo directory (as opposed to an empty one), do the odd messages still appear? -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
> UPDATE: If the ~/.terminfo/ directory EXIST in users home but the > termcap file is missing, the behaviour returns. > It's to late now, but I will do the tests and report back tomorrow. And... The winner is: HOME="/home/eivind" That's the environmental variable that triggers the message if an empty ~/.terminfo/ directory is present in my home. -- Eivind Eide "ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD" - Oceania Association of Autonomous Astronauts
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
> Now I wanted to start testing environmental variables so I completely > removed the ~/.terminfo/ directory, expecting the previous behavior to > return. However, I cannot reproduce! I even tried rebooting, but no. I > have no rational explanation for this. UPDATE: If the ~/.terminfo/ directory EXIST in users home but the termcap file is missing, the behaviour returns. It's to late now, but I will do the tests and report back tomorrow. -- Eivind Eide "ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD" - Oceania Association of Autonomous Astronauts
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
> Given 'if I do "env -i TERM=tmux-256color mutt" mutt opens WITHOUT > triggering the message', that implies that one of the other variables > set would be triggering it, can you either figure out which one or > show the list so someone else can try to replicate it please? Yes, I would really like to do so. However, something really weird happened. The described behaviour was consistent and persistent after upgrade to 7.5, also across reboot. Due to Jeremy Mates mail, I tested copying termcap files to my home directory, and the behaviour stopped. Now I wanted to start testing environmental variables so I completely removed the ~/.terminfo/ directory, expecting the previous behavior to return. However, I cannot reproduce! I even tried rebooting, but no. I have no rational explanation for this. -- Eivind Eide "ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD" - Oceania Association of Autonomous Astronautsmi
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
On 2024-04-09, Why 42? The lists account. wrote:
>
> On Sat, Apr 06, 2024 at 02:42:25PM +0200, Eivind Eide wrote:
>> After upgrading to 7.5 amd64 -stable (and all ports updated) I get
>> these messages in /var/log/messages. This is with bash from ports
>> inside tmux over SSH:
>>
>> tmux: vfprintf %s NULL in "%.*s"
>> bash: vfprintf %s NULL in "%.*s"
>> multitail: vfprintf %s NULL in "%.*s"
>> vim: vfprintf %s NULL in "%.*s"
>
> FYI, I grepped my messages and saw something similar:
> mjoelnir:~ 9.04 14:10:46 % grep printf /var/log/messages
> Apr 4 18:22:26 mjoelnir tumblerd: vfprintf %s NULL in "Unable to find part
> with type='%s' for '%s'"
> Apr 8 13:57:02 mjoelnir wrapper-2.0: vfprintf %s NULL in "day=%s, sun={%s,
> %s, %s, %s}, moon={%s, %s, %s, %s, %s} "
Those aren't much of a surprise - and the strings are unique enough
they should be easy to track down.
It's the one from tmux or more likely libcurses that's a surprise
(and imho more worth looking into).
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
"Why 42? The lists account." writes: Tumbler is something to do with D-Bus and is also a required package by/for XFCE. Yeah, Tumbler / tumblerd is a service, accessible via D-Bus, that generates thumbnails for files, e.g. in ~/.cache/thumbnails or equivalent. (But i'm not an XFCE user myself.) Alexis.
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
On 2024-04-09, Eivind Eide wrote: >>The log message no longer appears after running >> >>cp /usr/share/terminfo/x/xterm-256color ~/.terminfo/x/ > > Indeed! After > mkdir -p ~/.terminfo/t/ > cp /usr/share/terminfo/t/tmux-256color ~/.terminfo/t/ > (and the same for other termcaps used) > those messages are gone from /var/log/messages. That shouldn't be necessary. Given 'if I do "env -i TERM=tmux-256color mutt" mutt opens WITHOUT triggering the message', that implies that one of the other variables set would be triggering it, can you either figure out which one or show the list so someone else can try to replicate it please? -- Please keep replies on the mailing list.
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
On Sat, Apr 06, 2024 at 02:42:25PM +0200, Eivind Eide wrote:
> After upgrading to 7.5 amd64 -stable (and all ports updated) I get
> these messages in /var/log/messages. This is with bash from ports
> inside tmux over SSH:
>
> tmux: vfprintf %s NULL in "%.*s"
> bash: vfprintf %s NULL in "%.*s"
> multitail: vfprintf %s NULL in "%.*s"
> vim: vfprintf %s NULL in "%.*s"
FYI, I grepped my messages and saw something similar:
mjoelnir:~ 9.04 14:10:46 % grep printf /var/log/messages
Apr 4 18:22:26 mjoelnir tumblerd: vfprintf %s NULL in "Unable to find part
with type='%s' for '%s'"
Apr 4 18:22:26 mjoelnir tumblerd: vfprintf %s NULL in "Unable to find part
with type='%s' for '%s'"
Apr 8 13:57:02 mjoelnir wrapper-2.0: vfprintf %s NULL in "day=%s, sun={%s, %s,
%s, %s}, moon={%s, %s, %s, %s, %s} "
Apr 8 13:57:02 mjoelnir wrapper-2.0: vfprintf %s NULL in "day=%s, sun={%s, %s,
%s, %s}, moon={%s, %s, %s, %s, %s} "
Apr 9 13:57:06 mjoelnir wrapper-2.0: vfprintf %s NULL in "day=%s, sun={%s, %s,
%s, %s}, moon={%s, %s, %s, %s, %s} "
Apr 9 13:57:06 mjoelnir wrapper-2.0: vfprintf %s NULL in "day=%s, sun={%s, %s,
%s, %s}, moon={%s, %s, %s, %s, %s} "
The "wrapper-2.0" program is, I think, part of XFCE, I see that name in
the desktop panel configuraion. Tumbler is something to do with D-Bus and
is also a required package by/for XFCE.
Cheers,
Robb.
mjoelnir:~ 9.04 14:11:01 % uname -a
OpenBSD mjoelnir.fritz.box 7.5 GENERIC.MP#18 amd64
mjoelnir:~ 9.04 14:10:54 % echo $TERM
rxvt-unicode-256color
mjoelnir:~ 9.04 14:10:50 % locale
LANG=
LC_COLLATE=C
LC_CTYPE=en_US.UTF-8
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_MESSAGES="C"
LC_ALL=
mjoelnir:~ 9.04 14:11:04 % egrep -v '^(#|$)' .xsession
NO_AT_BRIDGE=1 ; export NO_AT_BRIDGE
LC_CTYPE="en_US.UTF-8"; export LC_CTYPE
LC_COLLATE=C; export LC_COLLATE
xrandr --dpi 109
xset +fp /usr/local/share/fonts/Hack
xset +fp /usr/local/share/fonts/terminus
xset +fp /usr/local/share/fonts/victor-mono
/usr/local/bin/startxfce4
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
>The log message no longer appears after running > >cp /usr/share/terminfo/x/xterm-256color ~/.terminfo/x/ Indeed! After mkdir -p ~/.terminfo/t/ cp /usr/share/terminfo/t/tmux-256color ~/.terminfo/t/ (and the same for other termcaps used) those messages are gone from /var/log/messages. -- Eivind Eide "ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD" - Oceania Association of Autonomous Astronauts
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
Given logger foo;xterm -tn xterm-256color -e ktrace -di /bin/ksh the log message 'ksh: vfprintf %s NULL in "%.*s"' appears when ~/.terminfo/x/xterm/xterm-256color does not exist. The log message no longer appears after running cp /usr/share/terminfo/x/xterm-256color ~/.terminfo/x/ and comes back after deleting the ~/.terminfo/x/xterm-256color file. The kdump when the log message happens runs along the lines of: 79510 ksh CALL access(0x744b97b272e0,0x4) 79510 ksh NAMI "/home/jmates/.terminfo/x/xterm-256color" 79510 ksh RET access -1 errno 2 No such file or directory 79510 ksh CALL issetugid() 79510 ksh RET issetugid 0 79510 ksh CALL issetugid() 79510 ksh RET issetugid 0 79510 ksh CALL issetugid() 79510 ksh RET issetugid 0 79510 ksh CALL open(0x744b97b1b600,0x1) 79510 ksh NAMI "none.db" 79510 ksh RET open -1 errno 2 No such file or directory 79510 ksh CALL mprotect(0x4e89f6c1000,0x1000,0x3) 79510 ksh RET mprotect 0 79510 ksh CALL mprotect(0x4e89f6c1000,0x1000,0x1) 79510 ksh RET mprotect 0 79510 ksh CALL open(0x744b97b1eed0,0x1) 79510 ksh NAMI "none" 79510 ksh RET open -1 errno 2 No such file or directory 79510 ksh CALL sendsyslog(0x744b97b1c140,35,0<>) 79510 ksh GIO fd -1 wrote 35 bytes "<10>ksh: vfprintf %s NULL in "%.*s"" 79510 ksh RET sendsyslog 0
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
On 2024-04-08, Eivind Eide wrote: > 24/04/06 06:04PM, Stuart Henderson: >> The fact that these all started hitting this with the same printf string >> (including tmux, which is in base) makes me wonder if it's coming from a >> library, the most likely being libcurses which was updated between 7.4 >> and 7.5 (which all of those use). >> >> Try to ascertain what's going on when that message is logged. ktrace >> might give some clues. > > Yes, I've been using these apps through numerous releases of OpenBSD > on this apu2 and this have never been triggered until I upgraded to > 7.5. > As pointed out, it also affects prominent members of base; tmux, top, ksh. > What seems to be in common for these apps are the version bump in > libcurses, that would be my guess too. > I tried passing different TERM, no change. I did "env -i mutt" but it > resulted in "Error opening terminal: unknown.". > But if I do "env -i TERM=tmux-256color mutt" mutt opens WITHOUT > triggering the message. > OK. So I've tried to unset various environmental variables one after > another trying to hunt this down to one variable, but so far, no luck! > I don't understand anything 'bout ktrace, but when I have the time I > could try to look into that... It might be easier to try adding them one by one to the env -i line. If you can find the variable that's triggering it then hopefully others will be able to replicate the problem and track it down. -- Please keep replies on the mailing list.
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
24/04/06 06:04PM, Stuart Henderson: > The fact that these all started hitting this with the same printf string > (including tmux, which is in base) makes me wonder if it's coming from a > library, the most likely being libcurses which was updated between 7.4 > and 7.5 (which all of those use). > > Try to ascertain what's going on when that message is logged. ktrace > might give some clues. Yes, I've been using these apps through numerous releases of OpenBSD on this apu2 and this have never been triggered until I upgraded to 7.5. As pointed out, it also affects prominent members of base; tmux, top, ksh. What seems to be in common for these apps are the version bump in libcurses, that would be my guess too. I tried passing different TERM, no change. I did "env -i mutt" but it resulted in "Error opening terminal: unknown.". But if I do "env -i TERM=tmux-256color mutt" mutt opens WITHOUT triggering the message. OK. So I've tried to unset various environmental variables one after another trying to hunt this down to one variable, but so far, no luck! I don't understand anything 'bout ktrace, but when I have the time I could try to look into that... -- Eivind Eide "ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD" - Oceania Association of Autonomous Astronauts
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
Дана 24/04/07 10:11AM, Stuart Henderson написа: > Yes. It's very common though, especially when constructing strings for > debug logging. I see this a lot with software in the GNOME ecosystem > using sprintf for this. Programmers who pass NULL to %s format specifier are writing incorrect code, whatever project they are contributing to. Mainstream projects like GNOME are a mess, and only getting worse with every iteration anyway. > That's interesting about the compiler optimisation for printf->puts, > though I think it won't be used in many cases where the pointer nay be > null so many uses of this won't trigger crashes for that reason. Keep in mind the quoted answer states this about gcc. I'm not sure about Clang/LLVM. In any case, passing NULL to %s specifier in *printf is incorrect code.
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
On 2024-04-06, Страхиња Радић wrote: > Дана 24/04/06 06:04PM, Stuart Henderson написа: >> The fact that these all started hitting this with the same printf string >> (including tmux, which is in base) makes me wonder if it's coming from a >> library, the most likely being libcurses which was updated between 7.4 >> and 7.5 (which all of those use). >> >> Try to ascertain what's going on when that message is logged. ktrace >> might give some clues. > > Of course, the package containing the code passing NULL to *printf should be > identified first, and the bug report should be sent to that package. It is > entirely possible that it is libcurses or another library. In the case of > dunst, it was dunst. libcurses and tmux are not packages, they are in the base OS. > Passing NULL to *printf is Undefined Behavior in C, and there is a > StackOverflow answer detailing the reasons at [1]. > > [1]: https://stackoverflow.com/a/11589500 Yes. It's very common though, especially when constructing strings for debug logging. I see this a lot with software in the GNOME ecosystem using sprintf for this. That's interesting about the compiler optimisation for printf->puts, though I think it won't be used in many cases where the pointer nay be null so many uses of this won't trigger crashes for that reason. -- Please keep replies on the mailing list.
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
Дана 24/04/06 06:04PM, Stuart Henderson написа: > The fact that these all started hitting this with the same printf string > (including tmux, which is in base) makes me wonder if it's coming from a > library, the most likely being libcurses which was updated between 7.4 > and 7.5 (which all of those use). > > Try to ascertain what's going on when that message is logged. ktrace > might give some clues. Of course, the package containing the code passing NULL to *printf should be identified first, and the bug report should be sent to that package. It is entirely possible that it is libcurses or another library. In the case of dunst, it was dunst. Passing NULL to *printf is Undefined Behavior in C, and there is a StackOverflow answer detailing the reasons at [1]. [1]: https://stackoverflow.com/a/11589500
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
On 2024-04-06, Страхиња Радић wrote: > Дана 24/04/06 02:42PM, Eivind Eide написа: >> tmux: vfprintf %s NULL in "%.*s" >> bash: vfprintf %s NULL in "%.*s" >> multitail: vfprintf %s NULL in "%.*s" >> vim: vfprintf %s NULL in "%.*s" > > This happens in OpenBSD when a program passes NULL pointer to *printf family > of > functions. The bug reports should be directed upstream to individual > packages. The fact that these all started hitting this with the same printf string (including tmux, which is in base) makes me wonder if it's coming from a library, the most likely being libcurses which was updated between 7.4 and 7.5 (which all of those use). Try to ascertain what's going on when that message is logged. ktrace might give some clues. Alternatively try to identify what's triggering it (this isn't normal - I don't recall ever seeing that from tmux/vim myself) - could be an environment variable. Can you reproduce it if you reset the environment (env -i)? How about if you use a different TERM?
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
Дана 24/04/06 02:42PM, Eivind Eide написа: > tmux: vfprintf %s NULL in "%.*s" > bash: vfprintf %s NULL in "%.*s" > multitail: vfprintf %s NULL in "%.*s" > vim: vfprintf %s NULL in "%.*s" This happens in OpenBSD when a program passes NULL pointer to *printf family of functions. The bug reports should be directed upstream to individual packages. See, for example, a similar issue I filed to dunst's Github[1]. Apparently, some developers think passing NULL to *printf is a-okay. [1]: https://github.com/dunst-project/dunst/issues/1305
