LibArchive: Fix fixed-width fields unbounded reads and PAX size OOM

[Miriam-R-coder]

Description

This PR addresses two security-relevant findings in LibArchive's tar parser reported in #26773:

1. Unbounded strlen() on fixed-width fields (Issue A): Replaced __builtin_strlen with strnlen inside get_field_as_string_view to prevent out-of-bounds memory reads on non-NUL terminated fields (such as m_link_name, m_magic, m_version, and m_prefix).
2. PAX memory amplification (Issue B): Added a safety threshold checking if the declared PAX extended-header size exceeds 1 MiB before triggering ByteBuffer::create_zeroed(), mitigating potential Out-Of-Memory (OOM) amplification attacks.

Fixes #26773

[BuggieBot]

Hello!

One or more of the commit messages in this PR do not match the SerenityOS code submission policy, please check the lint_commits CI job for more details on which commits were flagged and why.
Please do not close this PR and open another, instead modify your commit message(s) with git commit --amend and force push those changes to update this PR.

[Hendiadyoin1]

As the Commit linter suggests, please use namespaced and imperative commit titles, like:

LibArchive: Use strnlen for bounded strings in tar archives

or

LibArchive/Tar: Validate the PAX header

changes look good otherwise

[Hendiadyoin1]

Is there an easy way to test this?
if so please add a test

[Hendiadyoin1]

To change the commit titles after the fact you can use git rebase HEAD~2 -i and change the pick to reword or r
or watch this video for more info https://youtu.be/ElRzTuYln0M

[timschumi]

It's been some time since I wrote this, could we stream in the PAX content instead and then (maybe) enforce an arbitrary size limit on the individual entry instead?

[Miriam-R-coder]

Thanks @timschumi! Streaming the PAX content definitely sounds like the right long-term fix to avoid loading everything into memory. However, that might require a larger refactor of TarStream. Would it be acceptable to keep this 1 MiB threshold as a quick, temporary safety guard for now, and open a separate issue to track the refactoring of PAX parsing into a stream?

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions!

[Carmel0]

@timschumi Hi, just the issue reporter here, noticed this went stale. Is the 1 MiB cap fine as a stopgap (with the streaming refactor as a follow-up issue), or what would be needed for this to land?