passing null values to upsc results in kernel segmentation fault

[desertwitch]

when bash scripting with upsc it could happen that null variables are passed to upsc by mistake, reproducible with the terminal command upsc $UPS@$HOST for example - which would result in: upsc @ when those variables are in fact not set and/or null.

upsc @ currently results in a kernel segmentation fault on latest master, see:

root@Tower:~# upsc $UPS@$HOST
Segmentation fault

Sep 14 20:06:27 Tower kernel: upsc[28685]: segfault at 8 ip 000014a0bbce4236 sp 00007ffd21f42468 error 4 in libc-2.37.so[14a0bbc58000+169000] likely on CPU 1 (core 1, socket 0)
Sep 14 20:06:27 Tower kernel: Code: 00 00 66 90 66 0f ef c0 66 0f ef c9 66 0f ef d2 66 0f ef db 48 89 f8 48 89 f9 48 81 e1 ff 0f 00 00 48 81 f9 cf 0f 00 00 77 6a <f3> 0f 6f 20 66 0f 74 e0 66 0f d7 d4 85 d2 74 04 0f bc c2 c3 48 83

is there a way to recover from such an (easy to happen) mistake better than with a segmentation fault - perhaps such a malformation in the arguments could be caught before it would throw the kernel in distress?

OS: Slackware 15.0, NUT compiled from master

[jimklimov]

Nice find, never hit that :) That's with master? Also, it is known as "segfault", not "kernel fault". Although your syslog emitter could be kernel's default catcher for null pointer dereference (what probably happens here).

…

On Thu, Sep 14, 2023, 20:16 Rysz ***@***.***> wrote: when bash scripting with upsc it could happen that null variables are passed to upsc by mistake, reproducible with the terminal command upsc $UPS@$HOST for example - which would result in: upsc @ when those variables are in fact not set and/or null. upsc @ currently results in a kernel segmentation fault, see: ***@***.***:~# upsc $UPS@$HOST Segmentation fault Sep 14 20:06:27 Tower kernel: upsc[28685]: segfault at 8 ip 000014a0bbce4236 sp 00007ffd21f42468 error 4 in libc-2.37.so[14a0bbc58000+169000] likely on CPU 1 (core 1, socket 0) Sep 14 20:06:27 Tower kernel: Code: 00 00 66 90 66 0f ef c0 66 0f ef c9 66 0f ef d2 66 0f ef db 48 89 f8 48 89 f9 48 81 e1 ff 0f 00 00 48 81 f9 cf 0f 00 00 77 6a <f3> 0f 6f 20 66 0f 74 e0 66 0f d7 d4 85 d2 74 04 0f bc c2 c3 48 83 is there a way to recover from such an (easy to happen) mistake better than with a kernel fault - perhaps such a malformation in the arguments could be caught before it would throw the kernel in distress? — Reply to this email directly, view it on GitHub <#2052>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMPTFART3BY44U2ZZL3MITX2NCWFANCNFSM6AAAAAA4YRNSJU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[desertwitch]

yes, compiled from today's state of master branch
indeed - seg fault - shouldn't raise github issues from the train ;-)

[jimklimov]

Thanks! PR #2053 should solve this:

$ ./clients/upsc @
upscli_splitname: xstrdup failed
Error: invalid UPS definition.
Required format: upsname[@hostname[:port]]

[desertwitch]

confirmed working on my system now - thanks a lot