Created attachment 1758941 [details] Complete compiler diagnostic output Description of problem: Cannot build with -Werror=stringop-truncation, which is part of the usual hardening flags. Version-Release number of selected component (if applicable): All versions How reproducible: Steps to Reproduce: 1. Remove the line export CFLAGS="${CFLAGS} -Wno-error=stringop-truncation" from the spec file. 2. Build the RPM. 3. Observe the RPM build fails with an error. Actual results: Cannot build with -Werror=stringop-truncation. Expected results: Nothing in the code triggers these warnings. Additional info: Currently these warnings are still reported in the build, but are not treated as errors. These warnings look like real problems, and should be reported upstream. This bug is to track the problem, and any efforts to resolve it properly.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
Here is an example of the warnings about strncpy(). > In file included from /usr/include/string.h:519, > from isup.c:32: > In function 'strncpy', > inlined from 'isup_set_calling' at isup.c:2879:4, > inlined from 'isup_set_calling' at isup.c:2875:6: > /usr/include/bits/string_fortified.h:91:10: warning: 'strncpy' specified bound 64 equals destination size [-Wstringop-truncation] > 91 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > void isup_set_calling(struct isup_call *c, const char *calling, unsigned char calling_nai, unsigned char presentation_ind, unsigned char screening_ind) > { > if ((calling && calling[0]) || presentation_ind == SS7_PRESENTATION_ADDR_NOT_AVAILABLE) { > if (calling) { > strncpy(c->calling_party_num, calling, sizeof(c->calling_party_num)); > } else { > c->calling_party_num[0] = '\0'; > } > c->calling_nai = calling_nai; > c->presentation_ind = presentation_ind; > c->screening_ind = screening_ind; > } > } There are a number of similar warnings about strncpy() for other fields. In this case, the intent seems to be that the argument “calling” is copied into the struct field with null-termination, truncating any overlong string. But strncpy does not guarantee null-termination. It is likely that the code should have been something like: > if (calling) { > strncpy(c->calling_party_num, calling, sizeof(c->calling_party_num)); > c->calling_party_num[sizeof(c->calling_party_num) - 1U] = '\0'; > } else { ----- The other category of strncpy() warnings is like this: > In function 'strncpy', > inlined from 'isup_event_iam' at isup.c:4335:2: > /usr/include/bits/string_fortified.h:91:10: warning: 'strncpy' output may be truncated copying 50 bytes from a string of length 63 [-Wstringop-truncation] > 91 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest)); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ That comes from > strncpy(e->iam.called_party_num, c->called_party_num, sizeof(e->iam.called_party_num)); where e is an ss7_event discriminated union (from libss7.h), with the ss7_event_iam-type member active. That has “char called_party_num[50];”, which is indeed shorter than the called_party_num in “c”, which is a struct isup_call. What should be done in this case? Is truncation appropriate? It is already happening, only without null termination. ----- I intend to consult the upstream developers on IRC (Freenode #asterisk-dev) to see what they think of these warnings.
Upstream issue: https://issues.asterisk.org/jira/browse/SS7-64 Upstream developers have been busy but plan to look at it when they can.
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
FEDORA-2021-19406642b5 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2021-19406642b5
FEDORA-2021-19406642b5 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-17bf9d14f8 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-17bf9d14f8
FEDORA-2021-c5b708f363 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-c5b708f363
FEDORA-2021-91d42ce83e has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-91d42ce83e
FEDORA-2021-17bf9d14f8 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-17bf9d14f8` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-17bf9d14f8 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-dd64ecd715 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-dd64ecd715
FEDORA-EPEL-2021-37aab93b64 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-37aab93b64
FEDORA-2021-91d42ce83e has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-91d42ce83e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-91d42ce83e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-dd64ecd715 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-dd64ecd715 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-37aab93b64 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-37aab93b64 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-c5b708f363 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-c5b708f363` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-c5b708f363 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2021-dd64ecd715 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2021-37aab93b64 has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-c5b708f363 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-91d42ce83e has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-17bf9d14f8 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.