Skip to content

Memory leak in 'msgparse.c' in 'parse_edns_options_from_query(...)' #1324

Closed

Description

@TimofeyGritsun

Dynamic memory allocated in 'msgparse.c' by calling 'edns_opt_list_append(...)' at lines: 989, 1032, 1094, 1130, 1142; and lost at the end of the scope.
In 'edns_opt_list_append(...)' dynamic memory is allocated for new element 'struct edns_option* opt' by calling 'regional_alloc(...)' and is not freed.

Activity

  1. wenxuan70 commented on Aug 30, 2025

    @wenxuan70
    Contributor

    In fact, the outer parse_edns_from_query_pkt uses worker->scratchpad as region. When it fails, all memory blocks will be released.

    regional_free_all(worker->scratchpad);

  2. added a commit that references this issue on Sep 1, 2025
  3. wcawijngaards commented on Sep 1, 2025

    @wcawijngaards
    Member

    It looks like both posts are right. The memory from edns_opt_list_append is allocated in the region. That region is freed with the region later, in the daemon/worker.c file. After searching through the code to make sure, I saw a case in the worker.c file where the region with the edns opt list was not freed correctly.

    The commit fixes that the region, where the edns opt list is allocated, is freed in a case with ratelimit. That would stop memory from leaking into the region, it is freed every time.

    I am not sure if I caught the issue that is being reported, though, since the allocation in a region is freed later. Is there something more that needs to be fixed, for the memory leak? If the issue is resolved, that is fine as well. It is nice that a bug was fixed already :-) .

  4. TimofeyGritsun commented on Sep 2, 2025

    @TimofeyGritsun
    Author

    Thanks!
    There is one more thing:
    In "configparser.y" at lines 1170-1173 after checking for NULL pointer 'cfg_parser->cfg->http_endpoint' is dereferenced.
    It may lead to UB, since 'yyeror("out of memory") does not stop the execution, to my knowledge.

  5. wcawijngaards commented on Sep 2, 2025

    @wcawijngaards
    Member

    That is fixed in the commit, so it does not dereference the null pointer. The code is improved for the error case, where the error does not stop the execution there. Thank you for reporting that issue!

  6. added a commit that references this issue on Sep 3, 2025
    44c61ad
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions