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

Diskq: Fix crash when corrupt disk-queue is read (during move) #1924

Merged
merged 2 commits into from Mar 23, 2018

Conversation

gaborznagy
Copy link
Collaborator

@gaborznagy gaborznagy commented Mar 14, 2018

After fixing the restart functionality of disk-queue (see PR #1886) our test cases found another bug in non-reliable disk-queue.

After a successful message pop from disk-queue (either from qout or from overflow buffer or from the disk itself) we call a move_disk function to move the messages between the different queues.
Order of moving messages:
qout <-- qdisk <-- qoverflow.

In this move_disk function there is a lack of error handling when reading from the disk which results in a crash when log_msg_get_size is called with passing a NULL pointer to it.

Note that reliable disk-buffer is not affected.

Question:

  • When will the invalid read reported to the user of disk-queue? _move_disk() is a void function.

@gaborznagy gaborznagy changed the title Diskq: Fix crash when corrupt disk-queue is read when moved Diskq: Fix crash when corrupt disk-queue is read (during move) Mar 14, 2018
@kira-syslogng
Copy link
Contributor

success

@kira-syslogng
Copy link
Contributor

Build SUCCESS, the tests were executed on test branch: master and test suite: functions

@@ -1852,6 +1852,8 @@ log_msg_lookup_time_stamp_name(const gchar *name)

gssize log_msg_get_size(LogMessage *self)
{
if(!self) return 0;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I would prefer an assert here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I agree with your reason that a NULL is not a valid LogMessage, but I would not change it.
Using assert would lead an immediate crash which would be unnecessary if we can handle it gracefully.

  • There is no valid LogMessage that would be evaluated to 0, therefore a 0 is always an error.
  • If we would like to avoid syslog-ng crashes and assert would be preferred then each log_msg_get_size call should be guarded. Of course with returning 0 then the user of log_msg_get_size should make the error handling.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Thanks for explaining, fine for me

Gabor Nagy added 2 commits March 22, 2018 09:51
Signed-off-by: Gabor Nagy <gabor.nagy@balabit.com>
Signed-off-by: Gabor Nagy <gabor.nagy@balabit.com>
@kira-syslogng
Copy link
Contributor

Build SUCCESS, the tests were executed on test branch: master and test suite: functions

@kira-syslogng
Copy link
Contributor

success

@Kokan Kokan merged commit 2cf32b9 into syslog-ng:master Mar 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants