Hi, perhaps someone has an idea where I can look into to solve this. I am building iscan packages when upgrading, because I patched the source to support later PNG and with some other fixes. Unfortunately after last upgrade I noticed that the newly build version does not work, however the version build on buster last year still does work. It is the same code and same build process. I don't know where to start looking. I ran through strace and there are few differences around threads and mmap, but as I am not so experienced, I can not decide if this is relevant.
Do you have any advice? thanks BR
deloptes via tde-devels wrote:
I ran through strace and there are few differences around threads and mmap, but as I am not so experienced, I can not decide if this is relevant.
I did some debugging and pinpointed sscanf. It is not reading strings properly. Do you have any idea what could be the reason for this?
see attached for an example where the format and the string are from the code and configuration respectively
TGH I do not understand why it is using %as there, but if %s is used it does not parse the hex values properly and segfaults when printing the strings.
On Mon May 8 2023 16:47:56 deloptes via tde-devels wrote:
I did some debugging and pinpointed sscanf. It is not reading strings properly. Do you have any idea what could be the reason for this?
see attached for an example where the format and the string are from the code and configuration respectively
%as is looking for a float so let's ignore that.
If we switch back to %s it's looking for a string which would be great except no memory has been allocated for the strings.
The attached works with both gcc and clang but the important thing to remember is NEVER NEVER NEVER use scanf or any variant thereof.
https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/dangers-c.html
--Mike
Mike Bird via tde-devels wrote:
%as is looking for a float so let's ignore that.
I found out %as means do not store (strip) the terminator \0.
If we switch back to %s it's looking for a string which would be great except no memory has been allocated for the strings.
The attached works with both gcc and clang but the important thing to remember is NEVER NEVER NEVER use scanf or any variant thereof.
What do you mean it works with gcc? I have debian with gcc-10 and it does following:
$ ./test String: interpreter usb 0x04b8 0x0142 /usr/lib/esci/libesci-interpreter-perfection-v330 /usr/share/esci/esfwad.bin vendor 4b8 product 142 library (null) firmware (null)
https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/dangers-c.html
I am not the owner of this code. It was working for the past 6y and as reported when compiled last year in Buster it works as well, but now compiled in Bullseye is not working. For me it is not the matter of using it or not, but a change somewhere either in gcc (Buster was using gcc-8) or in the libraries.
Also regarding the memory allocated. You are right. It is working if I allocate memory and use %s instead of %as. Why, oh, why?!
Is there some kind of flag or option for the compiler?
On Mon May 8 2023 23:18:45 deloptes via tde-devels wrote:
Mike Bird via tde-devels wrote:
%as is looking for a float so let's ignore that.
I found out %as means do not store (strip) the terminator \0.
Do you have a man page for that? The test code is not written to handle non-terminated strings. How would it know the lengths?
If we switch back to %s it's looking for a string which would be great except no memory has been allocated for the strings.
The attached works with both gcc and clang but the important thing to remember is NEVER NEVER NEVER use scanf or any variant thereof.
What do you mean it works with gcc? I have debian with gcc-10 and it does following:
My test.c attached to my previous email - sorry I should have chosen a different name to avoid confusion - works with gcc-10 and clang-11 in Debian 11.7 Bullseye.
$ ./test String: interpreter usb 0x04b8 0x0142 /usr/lib/esci/libesci-interpreter-perfection-v330 /usr/share/esci/esfwad.bin vendor 4b8 product 142 library (null) firmware (null)
https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/dangers-c.html
I am not the owner of this code. It was working for the past 6y and as reported when compiled last year in Buster it works as well, but now compiled in Bullseye is not working. For me it is not the matter of using it or not, but a change somewhere either in gcc (Buster was using gcc-8) or in the libraries.
Also regarding the memory allocated. You are right. It is working if I allocate memory and use %s instead of %as. Why, oh, why?!
Is there some kind of flag or option for the compiler?
%a currently means floating point.
%as used to be a non-standard and incompatible way of asking for memory to be assigned for the strings but it won't work unless you use special flags. The standards-compliant way to assign memory while scanning is %ms.
So a simple fix would be to change %as to %ms but it's hard to get it right - you have to free(3) the allocated memory but only if the sscanf actually some memory. The attached test3.c shows how to do this in this simple case.
--Mike
Mike Bird via tde-devels wrote:
On Mon May 8 2023 23:18:45 deloptes via tde-devels wrote:
Mike Bird via tde-devels wrote:
%as is looking for a float so let's ignore that.
I found out %as means do not store (strip) the terminator \0.
Do you have a man page for that? The test code is not written to handle non-terminated strings. How would it know the lengths?
There is some documentation to the code but not in this regards.
If we switch back to %s it's looking for a string which would be great except no memory has been allocated for the strings.
The attached works with both gcc and clang but the important thing to remember is NEVER NEVER NEVER use scanf or any variant thereof.
What do you mean it works with gcc? I have debian with gcc-10 and it does following:
My test.c attached to my previous email - sorry I should have chosen a different name to avoid confusion - works with gcc-10 and clang-11 in Debian 11.7 Bullseye.
OK, thank you!
$ ./test String: interpreter usb 0x04b8 0x0142 /usr/lib/esci/libesci-interpreter-perfection-v330 /usr/share/esci/esfwad.bin vendor 4b8 product 142 library (null) firmware (null)
https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/dangers-c.html
I am not the owner of this code. It was working for the past 6y and as reported when compiled last year in Buster it works as well, but now compiled in Bullseye is not working. For me it is not the matter of using it or not, but a change somewhere either in gcc (Buster was using gcc-8) or in the libraries.
Also regarding the memory allocated. You are right. It is working if I allocate memory and use %s instead of %as. Why, oh, why?!
Is there some kind of flag or option for the compiler?
%a currently means floating point.
%as used to be a non-standard and incompatible way of asking for memory to be assigned for the strings but it won't work unless you use special flags. The standards-compliant way to assign memory while scanning is %ms.
So a simple fix would be to change %as to %ms but it's hard to get it right - you have to free(3) the allocated memory but only if the sscanf actually some memory. The attached test3.c shows how to do this in this simple case.
--Mike
This was the solution. The code takes care of freeing the memory, but your example is excellent one.
Thank you
Anno domini 2023 Mon, 8 May 17:24:02 -0700 Mike Bird via tde-devels scripsit:
On Mon May 8 2023 16:47:56 deloptes via tde-devels wrote:
I did some debugging and pinpointed sscanf. It is not reading strings properly. Do you have any idea what could be the reason for this?
see attached for an example where the format and the string are from the code and configuration respectively
%as is looking for a float so let's ignore that.
If we switch back to %s it's looking for a string which would be great except no memory has been allocated for the strings.
The attached works with both gcc and clang but the important thing to remember is NEVER NEVER NEVER use scanf or any variant thereof.
https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/dangers-c.html
Sorry to spoil the party, but on this page contains errors (I have not read further ) "read(fd, &len, sizeof(len));" is utterly BS.
--Mike
-- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...
On Mon May 8 2023 23:41:03 Dr. Nikolaus Klepp via tde-devels wrote:
https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/dangers-c.html
Sorry to spoil the party, but on this page contains errors (I have not read further ) "read(fd, &len, sizeof(len));" is utterly BS.
That's a perfectly reasonable way to read a binary integer into len if you know that the integer to be read is compatible with the size_t of the arch. For example if you are merely piping data between parent and child processes.
However the result of the read should have been checked and then the data read into len should also have been thoroughly checked.
The examples exist to point out the dangers of not validating lengths and of confusing size_t, int, and unsigned int - all of which may be different.
--Mike
Anno domini 2023 Mon, 8 May 23:57:00 -0700 Mike Bird via tde-devels scripsit:
On Mon May 8 2023 23:41:03 Dr. Nikolaus Klepp via tde-devels wrote:
https://dwheeler.com/secure-programs/Secure-Programs-HOWTO/dangers-c.html
Sorry to spoil the party, but on this page contains errors (I have not read further ) "read(fd, &len, sizeof(len));" is utterly BS.
That's a perfectly reasonable way to read a binary integer into len if you know that the integer to be read is compatible with the size_t of the arch. For example if you are merely piping data between parent and child processes.
It's a good way to call for trouble when you have mixed architecture, which is by no means a outerworldisch thing today. If you control both sides of the pipe and you spoiled your own protocol ... don't know what to say, that would have been wrong anyways.
However the result of the read should have been checked and then the data read into len should also have been thoroughly checked.
The examples exist to point out the dangers of not validating lengths and of confusing size_t, int, and unsigned int - all of which may be different.
--Mike ____________________________________________________ tde-devels mailing list -- devels@trinitydesktop.org To unsubscribe send an email to devels-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinitydeskt...
-- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...
-
deloptes -
Dr. Nikolaus Klepp -
Mike Bird