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

Memory issues caused by erroneous sizeof usage and others #125

Closed
ericonr opened this issue Apr 6, 2022 · 1 comment · Fixed by #137
Closed

Memory issues caused by erroneous sizeof usage and others #125

ericonr opened this issue Apr 6, 2022 · 1 comment · Fixed by #137
Assignees
Labels

Comments

@ericonr
Copy link
Member

ericonr commented Apr 6, 2022

Thankfully, it seems most of these code paths aren't in use at the moment.

Loops through struct with an uint32_t pointer but using sizeof(board_diagnostic_t) directly (without dividing by 4), as if it were an unsigned char pointer (causes a buffer overflow). I think this is wrong in general with aliasing restrictions (a memcpy'd buffer would be more correct), but we do pass -fno-strict-aliasing to the compiler, so that part shouldn't be a concern.

uint32_t *buffer = (uint32_t *)diag;
/* Send all bytes sequentially, except the last record (FMC slot status), whose address is 0xFF */
for( i = 0; i < sizeof(board_diagnostic_t)- 1; i++) {
write_fpga_dword( i, buffer[i] );
}
write_fpga_dword( 0xFF, buffer[i] );

Does memset(buffer, size, value) instead of memset(buffer, value, size). I'm not sure this memset needs to be here at all, since it immediately reads the I2C information into the buffer, therefore initializing it (unless the expectation after the I2C read is the presence of a null byte in the buffer). Should probably be replaced by a stack array, by setting a maximum size for the buffer.

memset( read_data, read_len, 0 );

Uses sizeof(hpm_page) when hpm_page is a pointer, making most calculations based on it wrong; this is happening all across the file. At least for the first memset call, sizeof(hpm_page) should probably be replaced with PAYLOAD_HPM_PAGE_SIZE, which is the size passed to the allocator.

uint8_t *hpm_page = NULL;
uint8_t hpm_pg_index;
uint32_t hpm_page_addr;
uint8_t payload_hpm_prepare_comp( void )
{
/* Initialize variables */
if (hpm_page != NULL) {
vPortFree(hpm_page);
}
hpm_page = (uint8_t *) pvPortMalloc(PAYLOAD_HPM_PAGE_SIZE);
if (hpm_page == NULL) {
/* Malloc failed */
return IPMI_CC_OUT_OF_SPACE;
}
memset(hpm_page, 0xFF, sizeof(hpm_page));

@ericonr ericonr added the bug label Apr 6, 2022
ericonr added a commit that referenced this issue Apr 8, 2022
This flag, since it removes builtin function usage entirely, can remove
opportunity for potential compiler optimizations to be applied in some
places, and, more importantly, some extra diagnostic warnings that can
appear when the compiler uses the builtin versions of functions (which
is what happened to point out the issues in [1]).

Unfortunately, removing the flag breaks our build. Using
-fno-builtin-printf is enough to fix it, so a safe assumption is that
when using builtin printf(), the compiler can switch it for different
functions (say, puts()), which we don't have our own implementation for,
meaning the libc version is used and that one requires some extra
functions for the underlying stdio implementation to work.

[1] #125
augustofg pushed a commit that referenced this issue Jun 9, 2022
This flag, since it removes builtin function usage entirely, can remove
opportunity for potential compiler optimizations to be applied in some
places, and, more importantly, some extra diagnostic warnings that can
appear when the compiler uses the builtin versions of functions (which
is what happened to point out the issues in [1]).

Unfortunately, removing the flag breaks our build. Using
-fno-builtin-printf is enough to fix it, so a safe assumption is that
when using builtin printf(), the compiler can switch it for different
functions (say, puts()), which we don't have our own implementation for,
meaning the libc version is used and that one requires some extra
functions for the underlying stdio implementation to work.

[1] #125
This was referenced May 16, 2023
@gustavosr8 gustavosr8 linked a pull request May 29, 2023 that will close this issue
@augustofg
Copy link
Member

This was introduced by c692454, it worked before because hpm_page was defined as a constant sized array. I understand the rational of avoiding using pre-allocated memory for rarely used functions, but dynamic allocation comes with its own risks when dealing with systems that lack a MMU. Anyway #137 should fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants