search

seccomp / libseccomp

The main libseccomp repository
GNU Lesser General Public License v2.1
791 stars 170 forks source link

BUG: fix read of uninitialized variable. #421

Closed chestnykh closed 9 months ago

chestnykh commented 9 months ago

tf_flag wasn't initialized and it is read at line 2016 before any initialization.

pcmoore commented 9 months ago

Is this based on manual code inspection or did you encounter a problem where tf_flag was actually read before it was initialized?

I ask this because immediately before line 2016 we have a NULL check on the c_prev variable which is always false the first time through the loop. On subsequent loop iterations tf_flag is guaranteed to be initialized due to the switch statement starting on line 2025.

However, if you've run into a problem where tf_flag is actually being read before it is initialized please let use know and we can work to fix it.

chestnykh commented 9 months ago

Is this based on manual code inspection or did you encounter a problem where tf_flag was actually read before it was initialized?

I ask this because immediately before line 2016 we have a NULL check on the c_prev variable which is always false the first time through the loop. On subsequent loop iterations tf_flag is guaranteed to be initialized due to the switch statement starting on line 2025.

However, if you've run into a problem where tf_flag is actually being read before it is initialized please let use know and we can work to fix it.

Yes, it's based on manual code inspection :)

pcmoore commented 9 months ago

Yes, it's based on manual code inspection :)

Thanks for the clarification. I appreciate the time you spent looking at the code, but I don't believe this is an actual bug as described above, and thus I don't believe this PR is needed.

I'll leave this PR open for a bit in case anyone wants to comment on this further, but as of right now I believe we can close this PR without merging.

chestnykh commented 9 months ago

Yes, it's based on manual code inspection :)

Thanks for the clarification. I appreciate the time you spent looking at the code, but I don't believe this is an actual bug as described above, and thus I don't believe this PR is needed.

I'll leave this PR open for a bit in case anyone wants to comment on this further, but as of right now I believe we can close this PR without merging.

No problem