SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
and there are actually updated microcodes for every intel cpu I have...
Meanwhile I updated my post #809 - added a P.S. about the spectre-meltdown-checker, which looks to be capable of identifying these new vulnerabilities. Worth testing it before and after the microcode update.
I can't do it myself right now, my systems are busy, the one I'm typing on is building Hadoop and the other two that are around are doing some data processing. As soon as I get one system available I'll test this on my own and report.
A new set of vulnerabilities have officially surfaced affecting Intel Core-i and Xeon CPUs.
It's dubbed ZombieLoad (Attack) Intel refers to it by using "Microarchitectural Data Sampling (MDS)".
Still waiting for Intel to fix SPECTRE/MELTDOWN here for my multiple Penryn systems. Not holding my breath.
Actually waiting for Intel to fix that and either Intel, the kernel devs or Xorg to fix their crap for the GM965 chipset so it doesn't take 10 minutes for my PC's to get to the desktop. Again, not holding my breath.
Still waiting for Intel to fix SPECTRE/MELTDOWN here for my multiple Penryn systems. Not holding my breath.
Actually waiting for Intel to fix that and either Intel, the kernel devs or Xorg to fix their crap for the GM965 chipset so it doesn't take 10 minutes for my PC's to get to the desktop. Again, not holding my breath.
You shouldn't wait after Intel for a SPECTRE/MELTDOWN fix, they don't care about older CPUs: https://www.theregister.co.uk/2018/0...ocode_updates/
"Intel admits a load of its CPUs have Spectre v2 flaw that can't be fixed
And won’t fix Meltdown nor Spectre for 10 product families covering 230-plus CPUs"
& https://www.intel.com/content/dam/ww...e_05132019.pdf
The Penryn microarchitecture is listed in Section 2:
"Section 2 – No planned microcode updates"
I'd suggest to get some newer HW, so that you can also enjoy these fresh vulnerabilities
I'm regretting getting rid of my old Pentium systems. They'd be proof against rowhammer, AMT, spectre, meltdown and zombieload.
An i586 running Slackware would serve nicely as a secure network router or text processor desktop.
Actually I still own an old fanless Pentium MMX 300MHz sub-notebook (a very slim and slick Toshiba portege) that I used as a router with 2 PCMCIA Ethernet cards until some years ago when I switched to OpenWRT / Raspberry - Slackware ARM. That ancient sub-notebook is still working now, still loaded with Slackware 13.x and I remember I had some issues upgrading to Slackware 13.x & a new kernel because I had some BIOS issues and only 24 MB RAM (32 - but 8 were allocated for the GPU)
It was some years ago (many) that I also got in direct contact with AlienBoB on his blog, actually he moderated my post, because I contradicted him, "invalidated his theory" at that time - he was convinced, and sustained that it cannot be done. I was not able to boot the boot disks (floppies) due to some BIOS/RAM/kernel limitations (can't remember exactly - getting older) and found a way to load a pseudo "BIOS" / boot loader with a special floppy image and then boot the actual Slackware boot floppies.
For the router part - I'd suggest www.openwrt.org with some beefy (multi-core - to handle some load & Gbit traffic) router that is supported.
For the secure processor desktop, well, I'm also looking for a solution...maybe: https://en.wikipedia.org/wiki/Risc-v
but they don't have a GPU yet and the few boards available are really expensive and sort of developer-boards.
libcurl contains two integer overflows in the `curl_url_set()` function that
if triggered, can lead to a too small buffer allocation and a subsequent heap
buffer overflow.
The flaws only exist on 32 bit architectures and require excessive string
input lengths.
We are not aware of any exploit of this flaw.
INFO
----
There are two entry points to this issue, on 32 bit architectures.
By asking libcurl to parse a string, passing in a string longer than 2GB to
this API: `curl_url_set(uh, CURLUPART_URL, "string", 0);` triggers the bug.
Asking libcurl to update a URL with a new string, and URL encoded it in the
process, by passing in a string longer than 1.33GB to this API:
`curl_url_set(uh, CURLUPART_*, "string", CURLU_URLENCODE);` triggers the bug.
We suggest you take one of the following actions immediately, in order of
preference:
A - Upgrade curl to version 7.65.0
B - Apply the patch to your version and rebuild
TIMELINE
--------
The issue was reported to the curl project on April 24, 2019. The patch was
communicated to the reporter on April 25, 2019. We contacted distros@openwall
on May 15.
curl 7.65.0 was released on May 22 2019, coordinated with the publication of
this advisory.
libcurl contains a heap buffer overflow in the function
(`tftp_receive_packet()`) that recevives data from a TFTP server. It calls
`recvfrom()` with the default size for the buffer rather than with the size
that was used to allocate it. Thus, the content that might overwrite the heap
memory is entirely controlled by the server.
The flaw exists if the user selects to use a "blksize" of 504 or smaller
(default is 512). The smaller size that is used, the larger the possible
overflow becomes.
Users chosing a smaller size than default should be rare as the primary use
case for changing the size is to make it larger.
It is rare for users to use TFTP across the Internet. It is most commonly used
within local networks.
We suggest you take one of the following actions immediately, in order of
preference:
A - Upgrade curl to version 7.65.0
B - Apply the patch to your version and rebuild
C - do not use TFTP with curl
TIMELINE
--------
The issue was reported to the curl project on April 29, 2019. The patch was
communicated to the reporter on April 29, 2019. We contacted distros@openwall
on May 15.
curl 7.65.0 was released on May 22 2019, coordinated with the publication of
this advisory.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
