*** Bug 18312 has been marked as a duplicate of this bug. ***

Thx, Nic

David Walser wrote a 16 page guide about "Where do security updates come from?" that I never mentioned when I tried to find volunteers to file security bugs, because I was afraid to scare potential volunteers away.

However, you're not the kind of person to get scared away by good documentation, so if you have time to read it: I uploaded it here:
http://waesvanm.home.xs4all.nl/Mageia/SecTeam/secupdates.pdf


Assigning to all packagers collectively, since there is no maintainer for this package.

@ David or any packager:
If this issue already got fixed before, or if it isn't valid for the i7z versions we have: please explain if you have, so that we can learn from it

CC: (none) => marja11

s/if you have/if you have time/

now really assigning :-/

Assignee: bugsquad => pkg-bugs
Source RPM: (none) => i7z

I did look at this report and I don't see what the security issue is.  I'm inclined to mark this as invalid.  I also put this package in task-obsolete in Cauldron, as it is dead both upstream and downstream.

Version: Cauldron => 5

(In reply to David Walser from comment #5)
> I did look at this report and I don't see what the security issue is.  I'm
> inclined to mark this as invalid.  I also put this package in task-obsolete
> in Cauldron, as it is dead both upstream and downstream.

Thanks, David

If the Mga5 i7z and i7z-qt (i7z-qt by starting "/usr/sbin/i7z_GUI") function the same as the cauldron ones here, then they can only be run as root and then they close within a second with an I/O error. 

There is a message:
 

       i7z DEBUG: You have write permissions to msr device files


What does a monitoring tool need those write permissions for? :-(

Forget comment 6

I mistakenly thought that laptop had an intel i3 processor, but it was a non-i3/5/7 intel. I now tried in Mga5 on a laptop with correct processor.
 https://wiki.mageia.org/en/User:Marja/QA/Hardware#Lenovo_ThinkPad_T410

/usr/sbin/i7z_GUI (and thus i7z, too) works fine here. No crash so far.


(In reply to David Walser from comment #5)
> I did look at this report and I don't see what the security issue is.  I'm
> inclined to mark this as invalid. 

The fedora advisory said:

"ensure we do not end up with invalid values for debug output"

I cannot imagine "invalid values" always equaling "vulnerability and possible exploits", but maybe I'm wrong?

> I also put this package in task-obsolete
> in Cauldron, as it is dead both upstream and downstream.

(In case someone steps up to maintain it: it is less dead in the new upstream Nic linked to https://github.com/bobwya/i7z - last commit 10 months ago.)

I should have looked better: they found a rating of _6_ on a scale of 1-9 for exploitable:

https://bugzilla.redhat.com/attachment.cgi?id=1138162
(that's an attachment to https://bugzilla.redhat.com/show_bug.cgi?id=1319432 )

And apparently they trust that rating.

Not every application crash is a security issue, and I'm failing to see how that one is.  They also had a newer snapshot of the code than we have to begin with, so I'm not 100% sure the crash affects us.

(In reply to David Walser from comment #9)
> Not every application crash is a security issue, and I'm failing to see how
> that one is.  They also had a newer snapshot of the code than we have to
> begin with, so I'm not 100% sure the crash affects us.

Changing this report from a security report to an unconfirmed rpm package report, in case a user is affected, after all, and searches for a bug report about his i7z crash.

Status: NEW => UNCONFIRMED
Component: Security => RPM Packages
Summary: i7z: denial of service => i7z: possible crashes
Ever confirmed: 1 => 0

Hi Nic,

I hope you're fine. You're always welcome back in BugSquad, if you like :-)

Closing this report as OLD, because Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/
It only continued to get important security updates since then, but non-security bugs have no chance of still getting fixed.

Kind regards,

Marja

Resolution: (none) => OLD
Status: UNCONFIRMED => RESOLVED