This structure collects count from multiple cred structures. Of course it
can't use a smaller type.
PR: 283747
Fixes: 37337709d3334f32650ba3a7c529fa013ed5e1f2
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 63187 Build 60071: arc lint + arc unit
Event Timeline
Comment Actions
Patch is obviously correct.
However, I have a hard time imagining this causing any practical overflow problem because, for that to happen, we would need more than 2Gi credentials references, which I really doubt has ever happened to the submitter of PR 283747 or anyone else for that matter. Am I missing something?
Comment Actions
I agree this is unlikely to be related to the panic reported in PR, given the first stacktrace I think something is going wrong in the network stack and after that all bets are off. I would probably start with checking what's the crash site code-wise. The 'Mar 7 09:38:18 pf-cam2 kernel: freeing uidinfo: uid = 884, sbsize = 115664' suggests something is not properly torn down.
The patch here does fix a real bug though.
Comment Actions
In the scope of this bug report, I have been shared a core privately, that was INVARIANTS build. It was in crunusebatch().
Comment Actions
Per my above comment the first crash does not look like it is cred-related -- something is going haywire with socket handling instead.
Note the second crash also has a warning about mismatch in socket space accounting.
Suppose the bug does not guarantee a crash on the socket side, but it does result in e.g., unrefing creds twice. Then crashing on cred manipulation is nothing special.