LinuxQuestions.org - -current and 12.2 Kernel security update

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - -current and 12.2 Kernel security update (https://www.linuxquestions.org/questions/slackware-14/current-and-12-2-kernel-security-update-748630/)

Interject

08-19-2009 02:33 AM

-current and 12.2 Kernel security update

http://slackware.com/security/viewer...ecurity.877234
Upgrade your kernels :)

allend

08-19-2009 03:03 AM

Quote:

In addition, these kernels change CONFIG_DEFAULT_MMAP_MIN_ADDR kernel
config option value to 4096, which should prevent the execution of
arbitrary code by future NULL dereference bugs that might be found in
the kernel.

I believe this change may break wine, DOSEMU and other emulation programs that need to allow zero page access for the emulated operating system.

samac

08-19-2009 03:29 AM

If you upgrade with slackpkg, remember to make sure that the kernels are not un-commented in /etc/slackpkg/blacklist or your upgrade will become tricky.

Wine works for me.

Do you need the kernel-mmap-min-addr-4096 package if you have upgrade the kernel to 2.6.27.31 ?

samac

GazL	08-19-2009 05:16 AM

Quote:

Originally Posted by samac (Post 3649074)

Do you need the kernel-mmap-min-addr-4096 package if you have upgrade the kernel to 2.6.27.31 ?

.31 should have 4096 as the default value, so I don't believe the extra package is necessary unless you're running an older kernel.

The changelog entry explains it pretty well...

Quote:

patches/packages/kernel-mmap_min_addr-4096-noarch-1.tgz:
This package adds an init script to edit /etc/sysctl.conf, adding
this config option:
vm.mmap_min_addr = 4096
This will configure the kernel to disallow mmap() to userspace of any
page lower than 4096, preventing privilege escalation by CVE-2009-2692.
This is a hot fix package and will take effect immediately upon
installation on any system running a kernel that supports configurable
/proc/sys/vm/mmap_min_addr (kernel 2.6.23 or newer).

allend

08-19-2009 07:26 AM

I have performed the kernel upgrade and the two applications that I run under WINE are still working without any apparent problems.

Chuck56

08-19-2009 07:29 AM

I normally run the generic kernel. After installing all the new .31 kernel packages, updating lilo.conf, running mkinitrd, running lilo, I got a new warning.

Code:

Warning: The initial RAM disk is too big to fit between the kernel and

  the 15M-16M memory hole.  It will be loaded in the highest memory as

  though the configuration file specified "large-memory" and it will

  be assumed that the BIOS supports memory moves above 16M.

This happened on a KVM VM and now a physical machine. Did I miss something or is this an expected warning from lilo?

gegechris99

08-19-2009 07:53 AM

Quote:

Originally Posted by Chuck56 (Post 3649334)

...I got a new warning.

Code:

Warning: The initial RAM disk is too big to fit between the kernel and

  the 15M-16M memory hole.  It will be loaded in the highest memory as

  though the configuration file specified "large-memory" and it will

  be assumed that the BIOS supports memory moves above 16M.

This happened on a KVM VM and now a physical machine. Did I miss something or is this an expected warning from lilo?

Maybe just check that you didn't accidentally install the huge kernel instead of the generic one.

From README_CRYPT.TXT in 12.2:

Quote:

We also need to change the kernel file to a generic kernel, because lilo
is unable to combine the 'huge' kernels in Slackware 12.2 with an initrd
image - it will complain about "The initial RAM disk is too big to fit
between the kernel and the 15M-16M memory hole" if you try with a 'huge'
kernel. We can live with that, since the 'huge' kernels are not meant
for day-to-day use anyway.

Chuck56

08-19-2009 08:10 AM

Quote:

Originally Posted by gegechris99 (Post 3649365)

Maybe just check that you didn't accidentally install the huge kernel instead of the generic one.

Thanks for the reply.

This is the section I updated in lilo.conf...

Code:

# Linux bootable partition config begins

image = /boot/vmlinuz-generic-smp-2.6.27.31-smp

  initrd = initrd.gz

  root = /dev/sda6

  label = Slack262731Gen

  read-only  # Partitions should be mounted read-only for checking

image = /boot/vmlinuz-huge-smp-2.6.27.31-smp

  root = /dev/sda6

  label = Slack262731Huge

  read-only  # Partitions should be mounted read-only for checking

# Linux bootable partition config ends

This is the mkinitrd command I issued...

Code:

mkinitrd -c -k 2.6.27.31-smp -m ext3 -f ext3 -r /dev/sda6

Here's what lilo had to say...

Code:

root@slacker:/boot# lilo

Warning: LBA32 addressing assumed

Warning: The initial RAM disk is too big to fit between the kernel and

  the 15M-16M memory hole.  It will be loaded in the highest memory as

  though the configuration file specified "large-memory" and it will

  be assumed that the BIOS supports memory moves above 16M.

Added Slack262731Gen ? *

Added Slack262731Huge

2 warnings were issued.

root@slacker:/boot#

I'm not sure what went wrong? And what does the "?" mean in the line "Added Slack262731Gen ? *" mean? I now have a "U" on the Slack262731Gen line on the boot screen. Never a dull moment whenever I upgrade a kernel!

gegechris99

08-19-2009 08:46 AM

Hello Chuck56,

As said in the README_CRYPT.TXT file I mentioned in my previous post:

Quote:

We can live with that, since the 'huge' kernels are not meant
for day-to-day use anyway.

So it seems to me that lilo is warning that you want to put the "huge" kernel (second entry in your lilo.conf file) into the MBR and that there is not enough space. The above-mentioned quote seems to indicate that it's not a problem.

If you can boot both generic and huge kernels, you should be fine as I assume you want to use the huge kernel only for emergency.

guanx

08-19-2009 08:53 AM

Quote:

Originally Posted by gegechris99 (Post 3649440)

Hello Chuck56,

As said in the README_CRYPT.TXT file I mentioned in my previous post:

So it seems to me that lilo is warning that you want to put the "huge" kernel (second entry in your lilo.conf file) into the MBR and that there is not enough space. The above-mentioned quote seems to indicate that it's not a problem.

If you can boot both generic and huge kernels, you should be fine as I assume you want to use the huge kernel only for emergency.

No joking, please. What does the memory hole do with MBR?
In short, just ignore this warning.

syvy	08-19-2009 09:08 AM

Same issue here. I noticed that kernel-generic-smp-2.6.27.31_smp-i686-1.tgz and kernel-huge-smp-2.6.27.31_smp-i686-1.tgz are both about 4,9 MB. In the config-generic-smp-2.6.27 e.g. the filesystems are built in. Maybe the huge kernel is shipped as generic?

Chuck56

08-19-2009 09:15 AM

Quote:

Originally Posted by guanx (Post 3649453)

No joking, please. What does the memory hole do with MBR?
In short, just ignore this warning.

Thanks folks! I'll ignore the warning as advised.

All appears to be working on my desktop machine. Both generic and huge boot as expected. I had to recompile/reinstall the NVIDIA driver to get X to start. I'm surprised that KVM didn't need a recompile but it seems to work without any intervention.

I'm still confused about the "U" that now appears on the lilo boot screen next to my default generic entry but that will be ignored for now as well.

Chuck56

08-19-2009 09:24 AM

Quote:

Originally Posted by syvy (Post 3649479)

That is an interesting observation on the kernel sizes. My 2.6.27.7 kernels are 2.3Mb for generic-smp and 4.7Mb for huge-smp. My 2.6.27.31 generic-smp and huge-smp have identical byte counts at 4.7Mb.

syvy	08-19-2009 09:55 AM

The "generic"-kernel IS a huge one. Look at this:

Quote:

diff config-generic-smp-2.6.27.31-smp config-huge-smp-2.6.27.31-smp
4c4
< # Mon Aug 17 16:10:10 2009
---
> # Mon Aug 17 17:18:50 2009

Chuck56

08-19-2009 10:00 AM

Quote:

Originally Posted by syvy (Post 3649538)

The "generic"-kernel IS a huge one. Look at this:

Based on the file sizes the duplication is with the generic-smp and huge-smp versions only not the non-smp versions. Good catch!

[EDIT]
I'll wait a while but I'm thinking I could recompile the non-smp generic kernel with the smp option. If this is a confirmed issue will there be a reissue of the official 12.2 kernel patches?
[/EDIT]

syvy	08-19-2009 11:15 AM

Quote:

Originally Posted by Chuck56 (Post 3649540)

If this is a confirmed issue will there be a reissue of the official 12.2 kernel patches?
[/EDIT]

I think so. I'll wait a while too before recompiling.

Lufbery

08-19-2009 11:53 AM

Quote:

Originally Posted by Chuck56 (Post 3649540)

Drop a note to Pat V, Robby Workman, or Alien Bob. My understanding is that the huge-smp and generic-smp kernels are not supposed to be the same thing!

Chuck56

08-19-2009 12:40 PM

Quote:

Originally Posted by Lufbery (Post 3649675)

Drop a note to Pat V, Robby Workman, or Alien Bob. My understanding is that the huge-smp and generic-smp kernels are not supposed to be the same thing!

I sent an email to security@slackware.com with a request to review the 2.6.27.31-smp kernels in the patch release and also a link to this thread just in case.

Lufbery

08-19-2009 12:48 PM

Bravo!

volkerdi

08-19-2009 01:32 PM

Thanks for the notice! I'll get a correct kernel up shortly... sorry about that.

The patches for net/socket.c are correct, for anyone compiling their own. This was just a .config mixup.

Chuck56

08-19-2009 01:48 PM

Quote:

Originally Posted by volkerdi (Post 3649832)

Thanks for the notice! I'll get a correct kernel up shortly... sorry about that.

The patches for net/socket.c are correct, for anyone compiling their own. This was just a .config mixup.

Thank you for all you do!

Chuck56

08-19-2009 10:48 PM

The updated generic-2.6.27.31-smp kernel packages are available. I used slackpkg to download and install. Ran mkinitrd and lilo without the unexpected lilo warnings from earlier. The /boot generic-2.6.27.31-smp and huge-2.6.27.31-smp file sizes seem in order.

Thanks to volkerdi and team for such a quick response!

All times are GMT -5. The time now is 05:40 AM.