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.
Interesting to note that the kernel has been upgraded in Slackware 14.2 to 4.4.19. Take care to read the changelog before upgrading.
Code:
Tue Aug 23 19:45:33 UTC 2016
patches/packages/gnupg-1.4.21-x86_64-1_slack14.2.txz: Upgraded.
Fix critical security bug in the RNG [CVE-2016-6313]. An attacker who
obtains 580 bytes from the standard RNG can trivially predict the next
20 bytes of output. (This is according to the NEWS file included in the
source. According to the annoucement linked below, an attacker who obtains
4640 bits from the RNG can trivially predict the next 160 bits of output.)
Problem detected by Felix Doerre and Vladimir Klebanov, KIT.
For more information, see:
https://lists.gnupg.org/pipermail/gnupg-announce/2016q3/000395.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6313
(* Security fix *)
patches/packages/glib2-2.46.2-x86_64-3_slack14.2.txz: Rebuilt.
Applied upstream patch to fix a use-before-allocate bug in libgio. Without
this fix, Thunar will crash if $HOME is on an NFS volume.
Thanks to Jonathan Woithe.
patches/packages/libgcrypt-1.7.3-x86_64-1_slack14.2.txz: Upgraded.
Fix critical security bug in the RNG [CVE-2016-6313]. An attacker who
obtains 580 bytes from the standard RNG can trivially predict the next
20 bytes of output. (This is according to the NEWS file included in the
source. According to the annoucement linked below, an attacker who obtains
4640 bits from the RNG can trivially predict the next 160 bits of output.)
Problem detected by Felix Doerre and Vladimir Klebanov, KIT.
For more information, see:
https://lists.gnupg.org/pipermail/gnupg-announce/2016q3/000395.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6313
(* Security fix *)
patches/packages/linux-4.4.19/*: Upgraded.
A flaw was found in the implementation of the Linux kernels handling of
networking challenge ack where an attacker is able to determine the shared
counter. This may allow an attacker located on different subnet to inject
or take over a TCP connection between a server and client without having to
be a traditional Man In the Middle (MITM) style attack.
Be sure to upgrade your initrd after upgrading the kernel packages.
If you use lilo to boot your machine, be sure lilo.conf points to the correct
kernel and initrd and run lilo as root to update the bootloader.
If you use elilo to boot your machine, you should run eliloconfig to copy the
kernel and initrd to the EFI System Partition.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5389
(* Security fix *)
patches/packages/screen-4.4.0-x86_64-2_slack14.2.txz: Rebuilt.
Reverted a change to /etc/screenrc.new that prevented the console from being
cleared when a screen session was detached. Thanks to Stuart Winter.
patches/packages/stunnel-5.35-x86_64-2_slack14.2.txz: Rebuilt.
Fixed incorrect config file name in generate-stunnel-key.sh.
Thanks to Ebben Aries.
Last edited by hitest; 08-23-2016 at 07:56 PM.
Reason: shorten post
Has that ever happened before? I mean, I tried to find an instance when Slackware released a newer kernel than the one glibc was built with, and I could not . Many people, a kernel dev too, assured me it is safe in practice, while may lead to abi-related hiccups in principle.
Has that ever happened before? I mean, I tried to find an instance when Slackware released a newer kernel than the one glibc was built with, and I could not .
The most recent was for slackware-14.0 :
Code:
+--------------------------+
Mon Jun 3 22:10:16 UTC 2013
patches/packages/linux-3.2.45/*: Rebuilt.
One more reverted commit. This one was leading to hangs on systems with
Intel graphics. The previous revert was also reverted in 3.2.46, but it
seems safer to just get this one manually than to take the newer kernel and
still have to do another patch to it anyway. Hopefully the third time is
the charm. :)
+--------------------------+
Wed May 22 14:11:13 UTC 2013
patches/packages/linux-3.2.45/*: Rebuilt.
It appears a bad commit slipped into 3.2.45 and it's causing problems on
systems that use Intel graphics. The commit has been reverted in the kernel
source packages and the kernels and modules have been rebuilt. If you ran
into the black screen problem before, this should fix it up.
+--------------------------+
Mon May 20 21:01:33 UTC 2013
patches/packages/linux-3.2.45/*: Upgraded.
Upgraded to new kernels that fix CVE-2013-2094, a bug that can allow local
users to gain a root shell. Be sure to upgrade your initrd and reinstall
LILO after upgrading the kernel packages.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2094
(* Security fix *)
+--------------------------+
Quote:
Originally Posted by qweasd
Many people, a kernel dev too, assured me it is safe in practice, while may lead to abi-related hiccups in principle.
I doubt there might be ABI issues with any version from the same kernel branch as the one originally shipped with Slackware-stable.
Well, it's done in -current all the time, and considering how well -current works, it shouldn't be a problem. Also, if you think about it, all the stable slackware releases are simply -current ones that just get a little fewer updates than the real -current one.
Has that ever happened before? I mean, I tried to find an instance when Slackware released a newer kernel than the one glibc was built with, and I could not .
Prior to the 14.0 instance, there is a 13.0 instance.
Quote:
Tue Dec 8 20:44:44 UTC 2009
patches/packages/linux-2.6.29.6-3/:
Added new kernels and kernel packages with a patch for CVE-2009-1298,
a kernel bug where oversized IP packets cause a NULL pointer dereference
and immediate hang.
For more information, see: http://cve.mitre.org/cgi-bin/cvename...=CVE-2009-1298 http://lkml.org/lkml/2009/11/25/104
Be sure to reinstall LILO after upgrading the kernel packages.
(* Security fix *)
+--------------------------+
Mon May 20 21:01:33 UTC 2013
patches/packages/linux-2.6.37.6-3/*: Rebuilt.
Added new kernel packages with a patch for CVE-2013-2094, a bug that can
allow local users to gain a root shell. Be sure to reinstall LILO after
upgrading the kernel packages.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2094
(* Security fix *)
+--------------------------+
Thu May 16 21:42:08 UTC 2013
patches/packages/ruby-1.9.3_p429-x86_64-1_slack13.37.txz: Upgraded.
This update fixes a security issue in DL and Fiddle included in Ruby where
I only remember it because I was a little concerned about breaking my working Slackware64 13.37 + Multilib Laptop
Oh wow I missed all of that somehow... Thanks everyone!
@suppy, I know it is perfectly safe, I myself tend to run the testing kernel in stable, but I was curious how pervasive that practice was, as opposed to patching the same exact kernel, as it was done in 14.1.
+--------------------------+
Mon May 20 21:01:33 UTC 2013
patches/packages/linux-2.6.37.6-3/*: Rebuilt.
Added new kernel packages with a patch for CVE-2013-2094, a bug that can
allow local users to gain a root shell. Be sure to reinstall LILO after
upgrading the kernel packages.
For more information, see:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2094
(* Security fix *)
+--------------------------+
Thu May 16 21:42:08 UTC 2013
patches/packages/ruby-1.9.3_p429-x86_64-1_slack13.37.txz: Upgraded.
This update fixes a security issue in DL and Fiddle included in Ruby where
I only remember it because I was a little concerned about breaking my working Slackware64 13.37 + Multilib Laptop
-- kjh
From what I can tell, these are just patches to the same kernel version, not a new version like we're seeing here.
13.0 came with 2.6.29.6 and the patch was 2.6.29.6-3
13.37 came with 2.6.37.6 and the patch was 2.6.37.6-3
Here's a list of Slackware versions (back to 7.0... I didn't check further) that saw patched releases of the same kernel version:
14.1 (64bit only): 3.10.17 -> 3.10.17-2
13.37: 2.6.37.6 -> 2.6.37.6-3
13.1: 2.6.33.4 -> 2.6.33.4-2
13.0: 2.6.26.9 -> 2.6.26.6-3
12.0: 2.6.21.5 -> 2.6.21.5 (build #2)
These are the versions of Slackware that saw a completely new kernel version in their patches (thanks for having me look at this... I've updated the wikipedia version table to show the patched version as well as the release version):
Distribution: slackware x86_64 , arm , slackware , AlmaLinux
Posts: 83
Rep:
where is the problem with changing the current kernel - if pat thinks one should change it because of this security patch - you just should do it !
i change mine when ever i want to do it ...
and - yes - slackware is a binary distribution witch is a one man show of pat ...
so - you should not think that you are being able to build your own distribution just by recompiling all the sources with these buildscripts ... there are some magic's more to do ... lol
no that's not sarcastic - i think i do understand because i have try it by myself ...
W.Slacker
but i hope that someday we could help him a little bit more to rip out the smal bugs
where is the problem with changing the current kernel - if pat thinks one should change it because of this security patch - you just should do it !
It's just that on a stable release, Pat does not commonly update the kernel. In 19 releases, only 10 of them saw kernel upgrades, and of those 10, only 5 were completely new versions. For those of us who've been with Slackware for a long time, we know it's not common to receive a completely new kernel version. For those who are not very familiar with Linux and/or Slackware, upgrading the kernel might be a bit daunting since bootloaders have to be updated as well (since if you screw up updating your bootloader, your computer likely won't boot without some work).
Updating to 4.4.19 give me notorious "flooding by EDID errors", with blinking screen every 10 seconds. Curiously, blinking was present even with " drm_kms_helper.edid_firmware " appended , so I reverted to 4.4.14. Is there a way to fix that by correcting the monitor, not bypassing errors ?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
