fix: misc socketpair fds problems

[therealbobo]

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area API-version

/area build

/area CI

/area driver-kmod

/area driver-bpf

/area driver-modern-bpf

/area libscap-engine-bpf

/area libscap-engine-gvisor

/area libscap-engine-kmod

/area libscap-engine-modern-bpf

/area libscap-engine-nodriver

/area libscap-engine-noop

/area libscap-engine-source-plugin

/area libscap-engine-savefile

/area libscap

/area libpman

/area libsinsp

/area tests

/area proposals

Does this PR require a change in the driver versions?

/version driver-API-version-major

/version driver-API-version-minor

/version driver-API-version-patch

/version driver-SCHEMA-version-major

/version driver-SCHEMA-version-minor

/version driver-SCHEMA-version-patch

What this PR does / why we need it:

This fixes:

• incorrect ret value handling in bpf and modern bpf (syscall is successful only if ret=0)
• wrongly add 2 fds with the name number (e.g. fd1=-1 and fd2=-1 in syscall failure scenarios)

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

NONE

[github-actions]

Please double check driver/API_VERSION file. See versioning.

/hold

[LucaGuerra]

I would like to take a second to appreciate the beauty of this bug.

If fd1 equals to fd2, which may happen at syscall failure, the following would happen

auto fdi1 = m_inspector->build_fdinfo();
...
auto fdi2 = fdi1->clone();
evt->set_fd_info(evt->get_tinfo()->add_fd(fd1, std::move(fdi1)));
evt->get_tinfo()->add_fd(fd2, std::move(fdi2));

Meaning that first set_fd_info is called with the new object fdi1 created for fd1, but then the entry for fd1 (which is the same as fd2) is overwritten, meaning that the pointer stored by set_fd_info is now invalid, leading to a UaF later on. Thanks to the ASan report and @therealbobo 's great work (the report does not fully point out the issue) we got this out before we released this thing anywhere! Great job @therealbobo .

[poiana]

LGTM label has been added.

Git tree hash: a9bbf149149e08af370af8dcf306c7d7f6ad3ae7

[poiana]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: leogr, LucaGuerra, therealbobo

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [LucaGuerra,leogr]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[leogr]

/milestone 0.15.0

[leogr]

Please double check driver/API_VERSION file. See versioning.

/hold

false positive

/hold cancel