Skip to content

Fixed some potential null derefs in coreclr#123939

Open
tpa95 wants to merge 20 commits intodotnet:mainfrom
tpa95:fix/coreclr-null-derefs
Open

Fixed some potential null derefs in coreclr#123939
tpa95 wants to merge 20 commits intodotnet:mainfrom
tpa95:fix/coreclr-null-derefs

Conversation

@tpa95
Copy link
Contributor

@tpa95 tpa95 commented Feb 3, 2026

Fixed some potential null pointer dereferences in inspect.cpp and virtual.cpp. The errors were discovered using the Svace static analyzer. I didn't observe any in practice.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
Reporter: Pavel Tikhomirov (Tihomirov-P@gaz-is.ru).
Organization: Gazinformservice (resp@gaz-is.ru).

tpa95 added 2 commits February 3, 2026 10:18
If an error occurs while executing the mprotect function, execution will jump to the error label, where the pRetVal null pointer will be dereferenced.
The bug was introduced in commit 835fa74 - prior to this, the pRetVal variable was assigned the value of StartBoundary before calling mprotect.
Added missing checks before calling CdStartField. In CdStartField, if typeHandle.IsNull() == true, the mod argument is dereferenced, which is null in all affected calls.
@dotnet-policy-service dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Feb 3, 2026
Comment on lines +718 to +719
pRetVal = (void *) StartBoundary;

Copy link
Member

@huoyaoyuan huoyaoyuan Feb 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is affecting the munmap call in error branch.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. If mprotect fails, we jump to error before pRetVal is assigned, so munmap(pRetVal, MemSize) ends up being called with NULL.
Also, I can instead call munmap((void*)StartBoundary, MemSize) in the error branch.
But in the previous version of the code, before commit 435bff2, pRetVal was initialized before calling mprotect.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fyi @janvorli

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its not clear to me that calling munmap(NULL, ...) would cause a NULL-deref but it did seem like the intent of the code was to unmap the memory on error. Calling munmap(StartBoundary, ...) might be a clearer way to write that but I'll let @janvorli decide.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the munmap would likely fail with EINVAL and would not dereference NULL. But maybe that if the size is large enough to reach memory mapped by some other mapping, it could cause it to be unmapped. The doc doesn't explicitly specify the behavior.
Also, the memory reserved in this case would leak.
So the fix looks good.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @janvorli . Would you prefer moving pRetVal = (void*)StartBoundary; before mprotect, or changing the error-path cleanup to call munmap((void*)StartBoundary, MemSize) instead? I can update the PR accordingly.

@tpa95
Copy link
Contributor Author

tpa95 commented Feb 19, 2026

Hi @agocke, @janvorli, @noahfalk. Could you please take a look when you have a moment and let me know if this is ready to merge or if you’d like changes? Thanks!

@agocke
Copy link
Member

agocke commented Feb 19, 2026

@elinor-fung could you also take a look?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-PAL-coreclr community-contribution Indicates that the PR has been added by a community member

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants

Comments