Closed Hugal31 closed 1 year ago
AFAICT this is caused by https://github.com/rust-lang/rust/pull/98112
This is legit, I can confirm that YARA generates misaligned pointers:
logs I added in yara:
created match 0x7f1e78356020
created match 0x7f1e7835605c
created match 0x7f1e78356096
created match 0x7f1e782c7020
created match 0x7f1e78238020
created match 0x7f1e7823805c
created match 0x7f1e781a9020
created match 0x7f1e7811a020
created match 0x7f1e7811a05c
debug logs in yara-rust:
[src/internals/string.rs:58] &matches[idx] = YR_MATCHES {
head: 0x00007f1e78356020,
tail: 0x00007f1e78356020,
count: 1,
}
[src/internals/string.rs:58] &matches[idx] = YR_MATCHES {
head: 0x00007f1e7811a020,
tail: 0x00007f1e7811a020,
count: 1,
}
[src/internals/string.rs:58] &matches[idx] = YR_MATCHES {
head: 0x0000000000000000,
tail: 0x0000000000000000,
count: 0,
}
[src/internals/string.rs:58] &matches[idx] = YR_MATCHES {
head: 0x00007f1e781a9020,
tail: 0x00007f1e781a9020,
count: 1,
}
[src/internals/string.rs:58] &matches[idx] = YR_MATCHES {
head: 0x00007f1e782c7020,
tail: 0x00007f1e782c7020,
count: 1,
}
[src/internals/string.rs:58] &matches[idx] = YR_MATCHES {
head: 0x00007f1e7835605c,
tail: 0x00007f1e7835605c,
count: 1,
}
panicked at 'misaligned pointer dereference: address must be a multiple of 0x8 but is 0x7f1e7835605c', src/internals/matches.rs
This needs to be reported to YARA
That's weird. I don't event know how you would create a mis-aligned pointer. I am not very familiar with the concept though.
In the meantime, should we add -Zmir-enable-passes=-CheckAlignment
to the pipeline? Ignore the error? I don't know how unsafe this issue is.
misaligned pointer access is undefined behavior, so it is very unsafe. The compiler is allowed to consider every access to be aligned, and generate corresponding instructions. On x86/x64, misalignment access is generally only a performance penalty, but some instructions notably SIMD ones do rely on aligned access, and misaligned access can lead to crashes.
Other architectures may be even less forgiving, I don't have much experience in those.
So for me this is quite a big issue. I'll report this to YARA. In the meantime you probably want to disable the check to make the CI pass I suppose yes :(
Looks like this was fixed for YARA 4.3: https://github.com/VirusTotal/yara/pull/1724 All allocations from the notebook (used for YR_MATCH) are now guaranteed to be 8-byte aligned. Using my MR to update to 4.3, I don't have this fail.
On the github pipeline, I get this error:
I could reproduce it on my own with the last nightly. What should we do? Wait the next nightly, ignore this error, or fix it? I don't find any information about a bug like this in the last nightlies.