RTEMS | aio_fsync.c: Use of uninitialised memory (#5102)

[Joel Sherrill (@joel)]

Joel Sherrill created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5102



## Summary

Coverity CID 1512532

Coverity notes that the rtems_aio_enqueue() call is using a field in the allocated _req_. Tracing the rtems_aio_enqueue() down through the layers, it eventually needs _req->next_prio.next_ to be NULL. The safest thing to do is likely to change malloc() to calloc().

```
 87
     	6. alloc_fn: Calling malloc which returns uninitialized memory. [Note: The source code implementation of the function has been overridden by a builtin model.]
     	7. assign: Assigning: req = malloc(28U), which points to uninitialized data.
 88  req = malloc( sizeof( rtems_aio_request ) );
     	8. Condition req == NULL, taking false branch.
 89  if ( req == NULL )
 90    rtems_set_errno_and_return_minus_one( EAGAIN );
 91
 92  /*
 93   * If O_SYNC != O_DSYNC, then this code needs to check for each individually.
 94   */
 95  req->aiocbp = aiocbp;
 96  req->op_type = AIO_OP_SYNC;
 97  
     	
CID 1512532: (#1 of 1): Uninitialized pointer read (UNINIT)
9. uninit_use_in_call: Using uninitialized value req->next_prio.next when calling rtems_aio_enqueue.[show details]
 98  return rtems_aio_enqueue( req );
```

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5102
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20240807/6259f041/attachment-0001.htm>