Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug]: app_sms: Compilation failure in DEVMODE due to stringop-overflow error #1088

Open
1 task done
InterLinked1 opened this issue Jan 24, 2025 · 3 comments · May be fixed by #1089
Open
1 task done

[bug]: app_sms: Compilation failure in DEVMODE due to stringop-overflow error #1088

InterLinked1 opened this issue Jan 24, 2025 · 3 comments · May be fixed by #1089
Assignees
Labels
bug support-level-extended Functionality with extended support level

Comments

@InterLinked1
Copy link
Contributor

InterLinked1 commented Jan 24, 2025

Severity

Major

Versions

22.2.0-rc1

Components/Modules

app_sms

Operating Environment

Fedora 42

Frequency of Occurrence

Constant

Issue Description

gcc 15 warning about possible writing beyond bounds of a buffer.

Looks like a false positive to me since there is a check for each byte if the end of the buffer has been reached, and the bounds are correct, but it's possible I've missed something...

Relevant log output

[CCi] app_stack.i -> app_stack.o
In function 'packsms8',
    inlined from 'sms_exec' at app_sms.c:1997:76:
app_sms.c:470:24: error: writing 32 bytes into a region of size 6 [-Werror=stringop-overflow=]
  470 |                 o[p++] = u;
      |                 ~~~~~~~^~~
app_sms.c: In function 'sms_exec':
app_sms.c:450:23: note: at offset [134, 140] into destination object 'dummy' of size 140
  450 |         unsigned char dummy[SMSLEN_8];
      |                       ^~~~~
cc1: all warnings being treated as errors
make[1]: *** [/usr/src/asterisk-22.2.0-rc1/Makefile.rules:151: app_sms.o] Error 1

Asterisk Issue Guidelines

  • Yes, I have read the Asterisk Issue Guidelines
InterLinked1 added a commit to InterLinked1/asterisk that referenced this issue Jan 24, 2025
Ignore gcc warning about writing 32 bytes into a region of size 6,
since we check that we don't go out of bounds for each byte.

Resolves: asterisk#1088
@jcolp jcolp added support-level-extended Functionality with extended support level and removed triage labels Jan 24, 2025
@seanbright
Copy link
Contributor

Does putting an explicit cast there work? I don't know where it is getting 32 bytes from, u is a long.

o[p++] = (unsigned char) u;

@InterLinked1
Copy link
Contributor Author

Does putting an explicit cast there work? I don't know where it is getting 32 bytes from, u is a long.

o[p++] = (unsigned char) u;

Nope.

gcc -o /dev/null -c app_sms.i -pthread -I/usr/src/asterisk-22.2.0-rc1/include   -I/usr/include/libxml2 -DWITH_GZFILEOP -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations   -g3 -Werror -Wunused -Wdeclaration-after-statement -Wtrampolines -Wundef -Wmissing-format-attribute -Wformat=2 -O0  -march=native -fPIC -DAST_MODULE=\"app_sms\" -DAST_MODULE_SELF_SYM=__internal_app_sms_self    -O3 -fno-partial-inlining
In function 'packsms8',
    inlined from 'sms_exec' at app_sms.c:1997:76:
app_sms.c:470:24: error: writing 32 bytes into a region of size 6 [-Werror=stringop-overflow=]
  470 |                 o[p++] = (unsigned char) u;
      |                 ~~~~~~~^~~~~~~~~~~~~~~~~~~
app_sms.c: In function 'sms_exec':
app_sms.c:450:23: note: at offset [134, 140] into destination object 'dummy' of size 140
  450 |         unsigned char dummy[SMSLEN_8];
      |                       ^~~~~
cc1: all warnings being treated as errors
make[1]: *** [/usr/src/asterisk-22.2.0-rc1/Makefile.rules:150: app_sms.o] Error 1
make[1]: Leaving directory '/usr/src/asterisk-22.2.0-rc1/apps'
make: *** [Makefile:396: apps] Error 2

@seanbright
Copy link
Contributor

Just my 2 cents but I’d wait for gcc 15 to be released. This seems like a compiler bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug support-level-extended Functionality with extended support level
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants