Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

log-pcap: fix segfault on lz4 compressed pcaps #6875

Closed
wants to merge 6 commits into from

Conversation

oxagast
Copy link

@oxagast oxagast commented Jan 27, 2022

Moved a file existence check to fix segfault if Suricata tries to write to an lz4 compressed .pcap file if you don't have permission to write to it. Also removed the previous code that would log this elsewhere, so you don't get double log entries.

https://redmine.openinfosecfoundation.org/issues/5022

@oxagast oxagast requested a review from a team as a code owner January 27, 2022 16:16
@codecov
Copy link

codecov bot commented Jan 27, 2022

Codecov Report

Merging #6875 (30960b2) into master (f8e1430) will decrease coverage by 0.16%.
The diff coverage is n/a.

❗ Current head 30960b2 differs from pull request most recent head 4fa3b55. Consider uploading reports for the commit 4fa3b55 to get more accurate results

@@            Coverage Diff             @@
##           master    #6875      +/-   ##
==========================================
- Coverage   77.72%   77.56%   -0.17%     
==========================================
  Files         628      628              
  Lines      186493   186921     +428     
==========================================
+ Hits       144959   144992      +33     
- Misses      41534    41929     +395     
Flag Coverage Δ
fuzzcorpus 57.72% <ø> (-0.67%) ⬇️
suricata-verify 53.54% <ø> (-0.54%) ⬇️
unittests 62.72% <ø> (-0.49%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Copy link
Author

@oxagast oxagast left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed the formatting so checks don't fail.

Copy link
Contributor

@jufajardini jufajardini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your interest in contributing to Suricata!

We would appreciate if you followed our code submission criteria :)
Especially:

  • commit message formatting
  • commit message and naming convention (so something like: log-pcap: fix segfault on lz4 compressed pcaps and then detail more in the commit body? )
  • don't add unnecessary commits (if the formatting fix covers your code changes only, please squash them ;) )

Also, have you signed the Suricata Contribution Agreement?

@oxagast oxagast changed the title Segfault on using lz4 compressed pcaps if you are unable to write to file log-pcap: fix segfault on lz4 compressed pcaps Jan 28, 2022
@oxagast
Copy link
Author

oxagast commented Jan 28, 2022

Hi,
Thanks for the tips. I've signed the contribution agreement, yes. I've also edited the title of the PR to reflect naming conventions. As for the second commit that was only edited formatting, I didn't think that it would allow a merge if the automated checks didn't pass. Now I'm not sure what you mean by squash the latest change with only formatting edits though, I didn't know there was a way to remove edits from the version tracker once they were committed and pushed. Is there a way to do that? Or do you just mean marge the two commits?

Edit: I think I figured out how to squash them with git merge master --squash.

commit 30960b2
Author: Marshall Whittaker <marshallwhittaker@gmail.com>
Date:   Thu Jan 27 13:52:56 2022 -0500

    Run the clang 9 formatting script on code fix for lz4 pcap segfault.

log-pcap: fix segfault on lz4 compressed pcaps
Copy link
Member

@victorjulien victorjulien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See inline comments

@@ -576,6 +576,12 @@ static int PcapLog (ThreadVars *t, void *thread_data, const Packet *p)
SCLogError(SC_ERR_FSEEK, "fseek failed: %s", strerror(errno));
return TM_ECODE_FAILED;
}
comp->file = fopen(pl->filename, "w");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see a check for comp->file here, which suggests it might be already open and this would leak the previous descriptor. We're in the packet path here, so we would call this for each packet.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If comp->file is null here, I think it means we didn't properly error check something during setup. I think the issue should be handled during setup/initialization (or file rotation)

src/log-pcap.c Outdated
"Error opening file for compressed output: %s",
strerror(errno));
/* took this out so that it won't print twice, but still would function
same SCLogError(SC_ERR_OPENING_FILE, "Error opening file for compressed output:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if removing output please just remove it instead of leaving it as a comment. It is fine to have a comment explaining why there is no error message here

@victorjulien victorjulien added the needs ticket Needs (link to) redmine ticket label Jan 28, 2022
@jufajardini
Copy link
Contributor

Hi, Thanks for the tips. I've signed the contribution agreement, yes. I've also edited the title of the PR to reflect naming conventions. As for the second commit that was only edited formatting, I didn't think that it would allow a merge if the automated checks didn't pass. Now I'm not sure what you mean by squash the latest change with only formatting edits though, I didn't know there was a way to remove edits from the version tracker once they were committed and pushed. Is there a way to do that? Or do you just mean marge the two commits?

Edit: I think I figured out how to squash them with git merge master --squash.

Kudos! Now you can follow those with the next PR submission :) Can you also create a ticket on our redmine project, to go with that iteration?

@oxagast
Copy link
Author

oxagast commented Jan 30, 2022

Probably correct to check if this directory is writeable on startup. I didn't happen to look, is everything else (that's working properly) also checked this way? I'm guessing that if the perms somhow got changed incorrectly while Suricata is running it would also fail that way, but the risk is much lower and the performance implications may not be worth doing it in the packet thread.
I have created a ticket on redmine with a backtrace.

@inashivb
Copy link
Member

Probably correct to check if this directory is writeable on startup. I didn't happen to look, is everything else (that's working properly) also checked this way?

Sounds about right to me. Directory should exist and be writable if we are willing to write something in there.

@victorjulien victorjulien removed the needs ticket Needs (link to) redmine ticket label Feb 2, 2022
@suricata-qa
Copy link

Warning: no commits in this PR have specified the following ticket(s):

Please update the commit(s) and submit a new PR.

@suricata-qa suricata-qa added the needs ticket Needs (link to) redmine ticket label Apr 26, 2022
@catenacyber catenacyber added the needs rebase Needs rebase to master label Jul 6, 2022
@catenacyber
Copy link
Contributor

@oxagast are you still working on this ?

@oxagast
Copy link
Author

oxagast commented Jul 6, 2022

Sorry, I completely forgot about this. I'll have to take another look into it. Thanks for reminding me.

@oxagast
Copy link
Author

oxagast commented Jul 6, 2022

So I just recompiled the latest version out of OSIF:master and it seems it is already fixed. Before Suricata would try to log the .lz4 compressed logs to a separate directory under the default logging dir. If that dir was not writable it would fault. However now it seem Suricata has changed where it is dropping the .lz4 logs, and is now putting them in the default (or user specified) logging directory, not in a sub-directory. So it seems to be fixed, either intentionally or unintentionally. I'll now close this issue.

Thanks!

@oxagast oxagast closed this Jul 6, 2022
victorjulien added a commit to victorjulien/suricata that referenced this pull request Mar 20, 2024
victorjulien added a commit to victorjulien/suricata that referenced this pull request Mar 22, 2024
jlucovsky pushed a commit to jlucovsky/suricata that referenced this pull request Aug 18, 2024
Bug: OISF#6875.
(cherry picked from commit 0be3ba8)
jlucovsky pushed a commit to jlucovsky/suricata that referenced this pull request Sep 3, 2024
Bug: OISF#6875.
(cherry picked from commit 0be3ba8)
jlucovsky pushed a commit to jlucovsky/suricata that referenced this pull request Sep 11, 2024
Bug: OISF#6875.
(cherry picked from commit 0be3ba8)
victorjulien added a commit to victorjulien/suricata that referenced this pull request Sep 14, 2024
Bug: OISF#6875.
(cherry picked from commit 0be3ba8)
victorjulien added a commit to victorjulien/suricata that referenced this pull request Sep 23, 2024
Bug: OISF#6875.
(cherry picked from commit 0be3ba8)
victorjulien added a commit to victorjulien/suricata that referenced this pull request Sep 24, 2024
Bug: OISF#6875.
(cherry picked from commit 0be3ba8)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs rebase Needs rebase to master needs ticket Needs (link to) redmine ticket
Development

Successfully merging this pull request may close these issues.

6 participants