AlmAck opened a new pull request, #20000:
URL: https://github.com/apache/nuttx/pull/20000

   ## Summary
   
   `fdlist_extend()` grows a task group's descriptor table to `row` rows of
   `CONFIG_NFILE_DESCRIPTORS_PER_BLOCK` entries each, and guards the growth
   against `OPEN_MAX`:
   
   ```c
   if (CONFIG_NFILE_DESCRIPTORS_PER_BLOCK * (orig_rows + 1) > OPEN_MAX)
     {
       fdlist_dump(list);
       return -EMFILE;
     }
   ```
   
   The check sizes the table at `orig_rows + 1`, which assumes the caller
   only ever grows by a single block. The function then allocates `row`
   rows, so the two agree only for growth by one.
   
   Callers do skip ahead:
   
   * `fdlist_dup3()` asks for `fd2 / CONFIG_NFILE_DESCRIPTORS_PER_BLOCK + 1`
   * `fdlist_dupfile()` asks for the row holding `minfd`
   * `fdlist_copy()` asks for the row holding a parent descriptor it is
     duplicating
   
   Any of those can request a row well past `orig_rows + 1`. Such a request
   passes the check, and the function then allocates and installs a table
   with more than `OPEN_MAX` descriptors.
   
   Check the row actually being requested instead. For single-block growth
   `row == orig_rows + 1` and the comparison is unchanged.
   
   ## Impact
   
   Affects the paths that grow the descriptor table by more than one block:
   `dup2()`/`dup3()` with a large target descriptor, `fcntl(F_DUPFD)` with a
   large `minfd`, and `posix_spawn`-style descriptor copying from a parent
   holding a high descriptor.
   
   With the defaults (8 per block, `OPEN_MAX` 256) a process holding one row
   that calls `dup2(fd, 400)` ends up with 51 rows — 408 descriptor slots
   against a 256 limit — instead of receiving `-EMFILE`.
   
   This is a limit-enforcement bug rather than memory corruption: the table
   stays internally consistent, it is simply larger than the process is
   entitled to, along with the memory for those rows.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to