Also thanks for taking the time to review my (many) PRs!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Actually it doesn’t work due to missing parentheses. I will file another PR.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Merged #1502 into master.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1502#event-4335373253___
Rpm-maint mailing list
Okay, this last one is actually a really nice solution to the issue. Thanks.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@DemiMarie pushed 1 commit.
447faa1df796d99c9b76c7b592176998ed7ffbd4 Negate the trailer offset after
division
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
> I know what undefined behavior is, and they do warrant some investigation.
> But just like compiler warnings, this stuff needs to be taken with a grain of
> salt. I've seen so much serious damage done from well-intended added "fixes"
> to compiler warnings and the like that I've grown quite
I know what undefined behavior is, and they do warrant some investigation. But
just like compiler warnings, this stuff needs to be taken with a grain of salt.
I've seen so much serious damage done from well-intended added "fixes" to
compiler warnings and the like that I've grown quite wary.
In
> It's undefined behavior, but what exactly you think will happen if that
> occurs? The result will still be an int32_t which is either in range or not,
> which can happen without invoking any undefined behavior and which we need to
> catch.
>
> So what exactly is this supposed to achieve?
It's undefined behavior, but what exactly you think will happen if that occurs?
The result will still be an int32_t which is either in range or not, which can
happen without invoking any undefined behavior and which we need to catch.
So what exactly is this supposed to achieve?
--
You are
@DemiMarie pushed 0 commits.
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1502/files/706e7c2e11eecaaab0953eb68618fe2f34aaed99..28e97bacfc011d2304d494f8762d69ed73cde68e
@DemiMarie pushed 1 commit.
706e7c2e11eecaaab0953eb68618fe2f34aaed99 Check that the blob is long enough
for a region
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
The following gzipped RPM package will demonstrate the bug on an RPM built with
UBSan.
[rpm-4.15.1-3.fc32.1.src.rpm.gz](https://github.com/rpm-software-management/rpm/files/5820367/rpm-4.15.1-3.fc32.1.src.rpm.gz)
--
You are receiving this because you are subscribed to this thread.
Reply to
Negating INT32_MIN is undefined behavior, so we must prevent it.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/1502
-- Commit Summary --
* Avoid negating an attacker-controlled signed integer
-- File Changes --
M
13 matches
Mail list logo
