Hi everyone,

I just added hardened-sources 2.6.32-r88 and 3.2.2 to the tree. They
address CVE-2012-0056. I've tested and they do indeed resist the
exploit. I will be stabilizing them within 24 hours. However, I feel
very uncomfortable doing so because I don't want to trade one set of
problems with another. If anyone has time to test, let me know if you
encounter any issues.


--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

I've just had this one while booting hardened-3.2.1:
Jan 27 16:40:29 atoth kernel: vmalloc: allocation failure: 0 bytes
Jan 27 16:40:29 atoth kernel: modprobe: page allocation failure: order:0,
mode:0x80d2
Jan 27 16:40:29 atoth kernel: Pid: 7460, comm: modprobe Not tainted
3.2.1-hardened #1
Jan 27 16:40:29 atoth kernel: Call Trace:
Jan 27 16:40:29 atoth kernel: [<000080d2>] ? match_id.clone.1+0x62/0x90
Jan 27 16:40:29 atoth kernel: [<000a0e1f>] ? warn_alloc_failed+0xbf/0x100
Jan 27 16:40:29 atoth kernel: [<000080d2>] ? match_id.clone.1+0x62/0x90
Jan 27 16:40:29 atoth kernel: [<000c3cc3>] ? __vmalloc_node_range+0x1a3/0x240
Jan 27 16:40:29 atoth kernel: [<000080d2>] ? match_id.clone.1+0x62/0x90
Jan 27 16:40:29 atoth kernel: [<00637cb5>] ?
__mutex_lock_slowpath+0x1a5/0x240
Jan 27 16:40:29 atoth kernel: [<00020b8e>] ? module_alloc+0x7e/0x90
Jan 27 16:40:29 atoth kernel: [<000080d2>] ? match_id.clone.1+0x62/0x90
Jan 27 16:40:29 atoth kernel: [<000728a3>] ?
module_alloc_update_bounds_rw+0x13/0x60
Jan 27 16:40:29 atoth kernel: [<000728a3>] ?
module_alloc_update_bounds_rw+0x13/0x60
Jan 27 16:40:29 atoth kernel: [<00073196>] ? load_module+0x886/0x1b70
Jan 27 16:40:29 atoth kernel: [<00002c59>] ? __switch_to+0xb9/0x210
Jan 27 16:40:29 atoth kernel: [<000744ca>] ? sys_init_module+0x4a/0x1d0
Jan 27 16:40:29 atoth kernel: [<00010246>] ? switch_to_new_gdt+0x26/0x30
Jan 27 16:40:29 atoth kernel: [<00638d71>] ? syscall_call+0x7/0xb
Jan 27 16:40:29 atoth kernel: [<00002c59>] ? __switch_to+0xb9/0x210
Jan 27 16:40:29 atoth kernel: [<00010246>] ? switch_to_new_gdt+0x26/0x30

It's there for every module loading. Even though modules seems to work.
Strange. The kernel also didn't logged the first page of dmesg in
kernel.log.

I don't experience this using hardened-3.1.8.
I don't know if it's a known problem. I'll try hardened-3.2.2 later.

Thanks:
Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2012.Január 27.(P) 14:37 idÅ‘pontban Anthony G. Basile ezt Ã*rta:
> Hi everyone,
>
> I just added hardened-sources 2.6.32-r88 and 3.2.2 to the tree. They
> address CVE-2012-0056. I've tested and they do indeed resist the
> exploit. I will be stabilizing them within 24 hours. However, I feel
> very uncomfortable doing so because I don't want to trade one set of
> problems with another. If anyone has time to test, let me know if you
> encounter any issues.
>
> --
> Anthony G. Basile, Ph. D.
> Chair of Information Technology
> D'Youville College
> Buffalo, NY 14201
> (716) 829-8197
>

And this one is from my laptop:
vmalloc: allocation failure: 0 bytes
modprobe: page allocation failure: order:0, mode:0x80d2
Pid: 3157, comm: modprobe Tainted: G O 3.2.1-hardened #1
Call Trace:
[<000080d2>] ? old_ich_force_enable_hpet+0x52/0x140
[<0008922b>] ? warn_alloc_failed+0xbb/0x100
[<000080d2>] ? old_ich_force_enable_hpet+0x52/0x140
[<000a8a11>] ? __vmalloc_node_range+0x1c1/0x260
[<000080d2>] ? old_ich_force_enable_hpet+0x52/0x140
[<0001ac3e>] ? module_alloc+0x7e/0x90
[<000080d2>] ? old_ich_force_enable_hpet+0x52/0x140
[<00060053>] ? module_alloc_update_bounds_rw+0x13/0x60
[<00060053>] ? module_alloc_update_bounds_rw+0x13/0x60
[<00060ac1>] ? sys_init_module+0xa01/0x1af0
[<000051f4>] ? smp_x86_platform_ipi+0x44/0x60
[<0000297c>] ? prepare_to_copy+0xc/0xb0
[<0000299c>] ? prepare_to_copy+0x2c/0xb0
[<0061396c>] ? syscall_call+0x7/0xb
[<000051f4>] ? smp_x86_platform_ipi+0x44/0x60
[<0001f7e0>] ? vmalloc_sync_all+0xf0/0xf0
[<0061398c>] ? restore_all_pax+0xc/0xc
[<0061007b>] ? snd_intel8x0m_probe+0x36e/0x635
[<00010202>] ? x86_schedule_events+0x122/0x2c0
[<00010202>] ? x86_schedule_events+0x122/0x2c0
Mem-Info:
DMA per-cpu:
CPU 0: hi: 0, btch: 1 usd: 0
Normal per-cpu:
CPU 0: hi: 186, btch: 31 usd: 126
HighMem per-cpu:
CPU 0: hi: 186, btch: 31 usd: 31
active_anon:523 inactive_anon:72 isolated_anon:0
active_file:2369 inactive_file:2790 isolated_file:0
unevictable:0 dirty:11 writeback:0 unstable:0
free:502375 slab_reclaimable:625 slab_unreclaimable:1183
mapped:570 shmem:89 pagetables:59 bounce:0
DMA free:15928kB min:64kB low:80kB high:96kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
isolated(anon):0kB isolated(file):0kB present:15804kB mlocked:0kB
dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB
slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB
bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 865 2015 2015
Normal free:826824kB min:3728kB low:4660kB high:5592kB active_anon:0kB
inactive_anon:0kB active_file:1716kB inactive_file:1444kB unevictable:0kB
isolated(anon):0kB isolated(file):0kB present:885944kB mlocked:0kB
dirty:44kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:2500kB
slab_unreclaimable:4732kB kernel_stack:488kB pagetables:236kB unstable:0kB
bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 9202 9202
HighMem free:1166748kB min:512kB low:1748kB high:2988kB active_anon:2092kB
inactive_anon:288kB active_file:7760kB inactive_file:9716kB
unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1177932kB
mlocked:0kB dirty:0kB writeback:0kB mapped:2276kB shmem:356kB
slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB
pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
lowmem_reserve[]: 0 0 0 0
DMA: 0*4kB 1*8kB 1*16kB 1*32kB 2*64kB 1*128kB 1*256kB 0*512kB 1*1024kB
1*2048kB 3*4096kB = 15928kB
Normal: 116*4kB 67*8kB 46*16kB 10*32kB 5*64kB 3*128kB 3*256kB 0*512kB
2*1024kB 3*2048kB 199*4096kB = 826824kB
HighMem: 1*4kB 69*8kB 85*16kB 33*32kB 16*64kB 2*128kB 3*256kB 3*512kB
1*1024kB 2*2048kB 282*4096kB = 1166748kB
5258 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap = 0kB
Total swap = 0kB
524112 pages RAM
296802 pages HighMem
12058 pages reserved
3473 pages shared
7713 pages non-shared

But modules are still get loaded somehow and working.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2012.Január 27.(P) 17:02 idÅ‘pontban "Tóth Attila" ezt Ã*rta:
> I've just had this one while booting hardened-3.2.1:
> Jan 27 16:40:29 atoth kernel: vmalloc: allocation failure: 0 bytes
> Jan 27 16:40:29 atoth kernel: modprobe: page allocation failure: order:0,
> mode:0x80d2
> Jan 27 16:40:29 atoth kernel: Pid: 7460, comm: modprobe Not tainted
> 3.2.1-hardened #1
> Jan 27 16:40:29 atoth kernel: Call Trace:
> Jan 27 16:40:29 atoth kernel: [<000080d2>] ? match_id.clone.1+0x62/0x90
> Jan 27 16:40:29 atoth kernel: [<000a0e1f>] ? warn_alloc_failed+0xbf/0x100
> Jan 27 16:40:29 atoth kernel: [<000080d2>] ? match_id.clone.1+0x62/0x90
> Jan 27 16:40:29 atoth kernel: [<000c3cc3>] ?
> __vmalloc_node_range+0x1a3/0x240
> Jan 27 16:40:29 atoth kernel: [<000080d2>] ? match_id.clone.1+0x62/0x90
> Jan 27 16:40:29 atoth kernel: [<00637cb5>] ?
> __mutex_lock_slowpath+0x1a5/0x240
> Jan 27 16:40:29 atoth kernel: [<00020b8e>] ? module_alloc+0x7e/0x90
> Jan 27 16:40:29 atoth kernel: [<000080d2>] ? match_id.clone.1+0x62/0x90
> Jan 27 16:40:29 atoth kernel: [<000728a3>] ?
> module_alloc_update_bounds_rw+0x13/0x60
> Jan 27 16:40:29 atoth kernel: [<000728a3>] ?
> module_alloc_update_bounds_rw+0x13/0x60
> Jan 27 16:40:29 atoth kernel: [<00073196>] ? load_module+0x886/0x1b70
> Jan 27 16:40:29 atoth kernel: [<00002c59>] ? __switch_to+0xb9/0x210
> Jan 27 16:40:29 atoth kernel: [<000744ca>] ? sys_init_module+0x4a/0x1d0
> Jan 27 16:40:29 atoth kernel: [<00010246>] ? switch_to_new_gdt+0x26/0x30
> Jan 27 16:40:29 atoth kernel: [<00638d71>] ? syscall_call+0x7/0xb
> Jan 27 16:40:29 atoth kernel: [<00002c59>] ? __switch_to+0xb9/0x210
> Jan 27 16:40:29 atoth kernel: [<00010246>] ? switch_to_new_gdt+0x26/0x30
>
> It's there for every module loading. Even though modules seems to work.
> Strange. The kernel also didn't logged the first page of dmesg in
> kernel.log.
>
> I don't experience this using hardened-3.1.8.
> I don't know if it's a known problem. I'll try hardened-3.2.2 later.
>
> Thanks:
> Dw.
> --
> dr Tóth Attila, Radiológus, 06-20-825-8057
> Attila Toth MD, Radiologist, +36-20-825-8057
>
> 2012.Január 27.(P) 14:37 idÅ‘pontban Anthony G. Basile ezt Ã*rta:
>> Hi everyone,
>>
>> I just added hardened-sources 2.6.32-r88 and 3.2.2 to the tree. They
>> address CVE-2012-0056. I've tested and they do indeed resist the
>> exploit. I will be stabilizing them within 24 hours. However, I feel
>> very uncomfortable doing so because I don't want to trade one set of
>> problems with another. If anyone has time to test, let me know if you
>> encounter any issues.
>>
>> --
>> Anthony G. Basile, Ph. D.
>> Chair of Information Technology
>> D'Youville College
>> Buffalo, NY 14201
>> (716) 829-8197
>>
>
>
>
>

On 01/27/12 08:37, Anthony G. Basile wrote:
> Hi everyone,
>
> I just added hardened-sources 2.6.32-r88 and 3.2.2 to the tree. They
> address CVE-2012-0056. I've tested and they do indeed resist the
> exploit. I will be stabilizing them within 24 hours. However, I feel
> very uncomfortable doing so because I don't want to trade one set of
> problems with another. If anyone has time to test, let me know if
> you encounter any issues.
>

With 3.2.1 and 3.2.2 I am unable to enter my Loop-AES passphrase after
the bios. 3.1.5 (and all earlier - for years) works fine.

On 27/01/12 14:37, Anthony G. Basile wrote:
> Hi everyone,
>
> I just added hardened-sources 2.6.32-r88 and 3.2.2 to the tree. They
> address CVE-2012-0056. I've tested and they do indeed resist the
> exploit. I will be stabilizing them within 24 hours. However, I feel
> very uncomfortable doing so because I don't want to trade one set of
> problems with another. If anyone has time to test, let me know if you
> encounter any issues.
>

I am still using 2.6.* sources here on one machine pending resolution of
bug https://bugs.gentoo.org/show_bug.cgi?id=386721 (if it will ever
happen :/ ).

However, I adopted the last working kernel (2.6.39-r8). After reading
the above, am I right to assume that there's no long-term support for
the .39 tree?

--
Tom

El 02/02/12 21:42, Tom Hendrikx escribió:
> However, I adopted the last working kernel (2.6.39-r8). After reading
> the above, am I right to assume that there's no long-term support for
> the .39 tree?
yup.

Tom Hendrikx <tom@whyscream.net> 2012-02-02 21:42:

On 27/01/12 14:37, Anthony G. Basile wrote:

Hi everyone,

I just added hardened-sources 2.6.32-r88 and 3.2.2 to the tree. They
address CVE-2012-0056. I've tested and they do indeed resist the
exploit. I will be stabilizing them within 24 hours. However, I feel
very uncomfortable doing so because I don't want to trade one set of
problems with another. If anyone has time to test, let me know if you
encounter any issues.



I am still using 2.6.* sources here on one machine pending resolution of
bug https://bugs.gentoo.org/show_bug.cgi?id=386721 (if it will ever
happen :/ ).


Are those open-vm kernel modules still necessary? It was my
understanding that most/all of the guest modules for more efficient
virtual hardware support were included in the mainline kernel now:

<http://kernelnewbies.org/Linux_2_6_33#head-b1a0ddbc804d228802ce8aebd37d9fd6513ccb01>

Thanks,
Brian

On 03/02/12 03:50, Brian Kroth wrote:

Tom Hendrikx <tom@whyscream.net> 2012-02-02 21:42:

On 27/01/12 14:37, Anthony G. Basile wrote:

Hi everyone,

I just added hardened-sources 2.6.32-r88 and 3.2.2 to the tree. They
address CVE-2012-0056. I've tested and they do indeed resist the
exploit. I will be stabilizing them within 24 hours. However, I feel
very uncomfortable doing so because I don't want to trade one set of
problems with another. If anyone has time to test, let me know if you
encounter any issues.



I am still using 2.6.* sources here on one machine pending resolution of
bug https://bugs.gentoo.org/show_bug.cgi?id=386721 (if it will ever
happen :/ ).


Are those open-vm kernel modules still necessary? It was my
understanding that most/all of the guest modules for more efficient
virtual hardware support were included in the mainline kernel now:
<http://kernelnewbies.org/Linux_2_6_33#head-b1a0ddbc804d228802ce8aebd37d9fd6513ccb01>


I did some more investigation. None of the three in-tree
open-vm-tools-kmod ebuilds compile against 2.6.32-r89, building a
3.2.2-r1 kernel now to test against that.


I thought that I needed the -kmod package to run open-vm-tools in the
guest, but after some more research this might only apply when you want
drag-and-drop support (useless for (headless) server). The open-vm-tools
ebuilds list the -kmod package as a hard RDEPEND though. I'll do some
tests later today/during the weekend.


Tom

On 03/02/12 13:37, Tom Hendrikx wrote:

On 03/02/12 03:50, Brian Kroth wrote:

Tom Hendrikx <tom@whyscream.net> 2012-02-02 21:42:

On 27/01/12 14:37, Anthony G. Basile wrote:

Hi everyone,

I just added hardened-sources 2.6.32-r88 and 3.2.2 to the tree. They
address CVE-2012-0056. I've tested and they do indeed resist the
exploit. I will be stabilizing them within 24 hours. However, I feel
very uncomfortable doing so because I don't want to trade one set of
problems with another. If anyone has time to test, let me know if you
encounter any issues.



I am still using 2.6.* sources here on one machine pending resolution of
bug https://bugs.gentoo.org/show_bug.cgi?id=386721 (if it will ever
happen :/ ).


Are those open-vm kernel modules still necessary? It was my
understanding that most/all of the guest modules for more efficient
virtual hardware support were included in the mainline kernel now:
<http://kernelnewbies.org/Linux_2_6_33#head-b1a0ddbc804d228802ce8aebd37d9fd6513ccb01>



I did some more investigation. None of the three in-tree
open-vm-tools-kmod ebuilds compile against 2.6.32-r89, building a
3.2.2-r1 kernel now to test against that.


The same goes for 3.2.2-r1: none of the -kmod packages build against it.
this means that the state of the -kmod package is a security issue,
since it cannot be used with a non-vulnerable -hardened kernel. I'll add
this to the bug report.




I thought that I needed the -kmod package to run open-vm-tools in the
guest, but after some more research this might only apply when you want
drag-and-drop support (useless for (headless) server). The open-vm-tools
ebuilds list the -kmod package as a hard RDEPEND though. I'll do some
tests later today/during the weekend.



Just booted a 3.2.2-r1-hardened kernel, and vmware-tools stuff seems to
run fine with the in-kernel vmware support. Not sure about performance
etc, but it boots, generates no errors and VSphere in the host reports
no issues either.


We might just need an updated open-vm-tools package that only depends on
the in-kernel stuff, and no longer on the -kmod package. I'll try to
followup with the vmware people, as this is getting OT here


--
Tom