Fix unsafe `st_uid` conversion to `int64_t` in `StatBuffer`

[LittleHuba]

Description

In the definition of StatBuffer in https://github.com/eclipse-score/baselibs/blob/main/score/os/stat.h#L43 the library score/os types st_uid to std::int64_t.

But POSIX defines the type as "an arithmetic type with appropriate length" and further "as an integer type" (https://pubs.opengroup.org/onlinepubs/007904875/basedefs/sys/types.h.html#tag_13_67).
There is no restriction, that it is a signed integer.

Thus, the static_cast in https://github.com/eclipse-score/baselibs/blob/main/score/os/stat_impl.cpp#L106 is unsound when the system uses as underlying type std::uint64_t and the user id is higher than std::numeric_limits<std::int64_t>::max().

Arguably this is rare to happen but also not ruled out. Therefore, this remains a safety issue.

CodeQL finding that raised this issue downstream: https://github.com/eclipse-score/communication/security/code-scanning/14104

Analysis results

No response

Solution

No response

Error Occurrence Rate

None

How to reproduce

No response

Supporting Information

No response

Classification

Minor

First Affected Release

not released (main)

Last Affected Release

not released (main)

Expected Fixed Release

before release (main)

Category

• Safety Relevant
• Security Relevant

[LittleHuba]

Please also check other members of that type. This seems to apply for st_gid as well.

[4og]

For those who don't have access to the Github code scanning page.

The CodeQL warning is raised on this line:
https://github.com/eclipse-score/communication/blob/8dcefe9ecedb5cb93375656957b416717a364d71/score/memory/shared/shared_memory_resource.cpp#L214

RULE-7-0-5: Integral promotion and the usual arithmetic conversions shall not change the signedness or the type
Usual arithmetic conversion from 'unsigned int' to 'long' changes signedness.