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

nvtable: deserialized handle access crash #1967

Merged
merged 1 commit into from
Apr 7, 2018

Conversation

Kokan
Copy link
Collaborator

@Kokan Kokan commented Apr 5, 2018

This crash happens, when a message is deserialized. (An example for this is the disk queue file.)

The deserialization process has two steps. One that actually make the deserialization, and an additional fixup step.

The additional fixup step tries to validate and updated the index table with the new handles (if they are new).

The issue comes from this fixup, because first it creates a temporary index table, if a handle has a new handle it saves the updated entry to the temporary table.
After going through all of the entries, if there was even one updated entry it just swaps the two table (temporary, and active).

The issue here, that when there were some handle which has been updated, and there were some that have not, the temporary table has gaps with uninitialized entities.

This probably Fixes #1919.

The deserialization process for nvtable has two stages.
The first one is to read the byte stream and assign it to a structure,
The second phase called `fixup`, which tries to fix the index tables (both static and dynamic).

The fixup process checks if the handles are valid, and current. If they are not, it replaces them with a new valid handle.
The current issue is that the fixup function created a temporary table for all of the index, and saved all of the updated handles in this new table.
If there was even one new handle, it swaped the two table.

But in fact if there was a handle that did not required update, it was not saved to the new table, thus that space left uninitialized.
Thus it could crash based on the memory trash.

Signed-off-by: kokan <peter.kokai@balabit.com>
@kira-syslogng
Copy link
Contributor

success

@bazsi
Copy link
Collaborator

bazsi commented Apr 7, 2018

This looks good to me. Very nice catch. To get the crash we need to have some of the handles match and some that don't.

@MrAnno MrAnno merged commit 3bb679f into syslog-ng:master Apr 7, 2018
@MrAnno MrAnno mentioned this pull request Apr 23, 2018
Kokan added a commit to Kokan/syslog-ng that referenced this pull request Jun 6, 2018
The syslog-ng#1967 was not a complete fix, because that fixed the case with nvtable.
But that did not fix the one with sdata.

Signed-off-by: Kokan <kokaipeter@gmail.com>
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.

Segfault in nv_registry_get_handle_flags
7 participants