About this list Date view Thread view Subject view Author view Attachment view

From: Andrew Mendelsohn (amendelsohn_at_molsci.org)
Date: Sun 23 Jan 2005 - 22:41:44 GMT


Hi,
  I used splitdiff to split the new patch-2.6.11-rc2-vs1.9.4-rc3.diff,
removed the mm/mmap.c patch and then used it to replace the mm/mmap.c
patch in patch-2.6.10-vs1.9.4-rc3.diff. I then recombined the 2.6.10
patches using cat. The resulting patch cleanly patches the 2.6.10
kernel with the two security fixes listed below with fuzz 2. If anyone
wants the resulting patch file I'll be happy to send it. I'm testing it
now.

Andy

Andrew Mendelsohn wrote:

> Hi,
>
> Here are links to the two security patches.
> http://www.acm.cs.rpi.edu/~dilinger/patches/2.6.10/as2/linux-2.6.10-as2/033-rlimit_memlock_check.patch
>
> http://www.acm.cs.rpi.edu/~dilinger/patches/2.6.10/as2/linux-2.6.10-as2/034-stack_resize_exploit.patch
>
>
> Thanks for the suggestion. I'll check out the 2.6.11 patches to see if
> they already deal with these exploits.
>
> Thanks for your help!
> Andy
>
> Herbert Poetzl wrote:
>
>> On Sun, Jan 23, 2005 at 12:59:51AM -0800, Andrew Mendelsohn wrote:
>>
>>
>>> After patching a 2.6.10 kernel with the patch-2.6.10-vs1.9.4-rc2
>>> patch, I can't cleanly apply fixes for CAN-2005-0001 and
>>> RLIMIT_MEMLOCK exploits because of critical changes to mmap.c I was
>>> using fixes from the new as-patch series from Andres Salomon which
>>> is supposed to be a minimum set of security fixes that will be used
>>> by Debian as well as possibly other distros. (
>>> http://www.acm.cs.rpi.edu/~dilinger/patches/2.6.10/as2/ ).
>>>
>>> After studying the changes I came to the conclusion that it requires
>>> someone who understands the linux memory subsystem better than I do
>>> :) So, does anyone know how to reconcile these patches?
>>>
>>
>>
>> please be so kind an link me to the patches in question
>> (in unified diff format if possible) and I'll see what
>> I can do for you .. aside from that, 2.6.11-rc1 or rc2
>> should be an option too, no?
>>
>> best,
>> Herbert
>>
>>
>>
>>> Here is the mm/mmap.c.rej which shows how significantly the security
>>> patches change the code:
>>>
>>> ***************
>>> *** 1351,1378 ****
>>> */
>>> address += 4 + PAGE_SIZE - 1;
>>> address &= PAGE_MASK;
>>> - grow = (address - vma->vm_end) >> PAGE_SHIFT;
>>>
>>> - /* Overcommit.. */
>>> - if (security_vm_enough_memory(grow)) {
>>> - anon_vma_unlock(vma);
>>> - return -ENOMEM;
>>> }
>>> -
>>> - if (address - vma->vm_start >
>>> current->signal->rlim[RLIMIT_STACK].rlim_$
>>> - ((vma->vm_mm->total_vm + grow) << PAGE_SHIFT) >
>>> - current->signal->rlim[RLIMIT_AS].rlim_cur) {
>>> - anon_vma_unlock(vma);
>>> - vm_unacct_memory(grow);
>>> - return -ENOMEM;
>>> - }
>>> - vma->vm_end = address;
>>> - vma->vm_mm->total_vm += grow;
>>> - if (vma->vm_flags & VM_LOCKED)
>>> - vma->vm_mm->locked_vm += grow;
>>> - __vm_stat_account(vma->vm_mm, vma->vm_flags, vma->vm_file,
>>> grow);
>>> anon_vma_unlock(vma);
>>> - return 0;
>>> }
>>>
>>> struct vm_area_struct *
>>> --- 1395,1415 ----
>>> */
>>> address += 4 + PAGE_SIZE - 1;
>>> address &= PAGE_MASK;
>>> + error = 0;
>>>
>>> + /* Somebody else might have raced and expanded it already */
>>> + if (address > vma->vm_end) {
>>> + unsigned long size, grow;
>>> +
>>> + size = address - vma->vm_start;
>>> + grow = (address - vma->vm_end) >> PAGE_SHIFT;
>>> +
>>> + error = acct_stack_growth(vma, size, grow);
>>> + if (!error)
>>> + vma->vm_end = address;
>>> }
>>> anon_vma_unlock(vma);
>>> + return error;
>>> }
>>>
>>> struct vm_area_struct *
>>> ***************
>>>
>>> and
>>>
>>>
>>>
>>> ***************
>>> *** 1416,1444 ****
>>> * anon_vma lock to serialize against concurrent expand_stacks.
>>> */
>>> address &= PAGE_MASK;
>>> - grow = (vma->vm_start - address) >> PAGE_SHIFT;
>>>
>>> - /* Overcommit.. */
>>> - if (security_vm_enough_memory(grow)) {
>>> - anon_vma_unlock(vma);
>>> - return -ENOMEM;
>>> - }
>>> -
>>> - if (vma->vm_end - address >
>>> current->signal->rlim[RLIMIT_STACK].rlim_cu$
>>> - ((vma->vm_mm->total_vm + grow) << PAGE_SHIFT) >
>>> - current->signal->rlim[RLIMIT_AS].rlim_cur) {
>>> - anon_vma_unlock(vma);
>>> - vm_unacct_memory(grow);
>>> - return -ENOMEM;
>>> }
>>> - vma->vm_start = address;
>>> - vma->vm_pgoff -= grow;
>>> - vma->vm_mm->total_vm += grow;
>>> - if (vma->vm_flags & VM_LOCKED)
>>> - vma->vm_mm->locked_vm += grow;
>>> - __vm_stat_account(vma->vm_mm, vma->vm_flags, vma->vm_file,
>>> grow);
>>> anon_vma_unlock(vma);
>>> - return 0;
>>> }
>>>
>>> struct vm_area_struct *
>>> --- 1453,1475 ----
>>> * anon_vma lock to serialize against concurrent expand_stacks.
>>> */
>>> address &= PAGE_MASK;
>>> + error = 0;
>>>
>>> + /* Somebody else might have raced and expanded it already */
>>> + if (address < vma->vm_start) {
>>> + unsigned long size, grow;
>>> +
>>> + size = vma->vm_end - address;
>>> + grow = (vma->vm_start - address) >> PAGE_SHIFT;
>>> +
>>> + error = acct_stack_growth(vma, size, grow);
>>> + if (!error) {
>>> + vma->vm_start = address;
>>> + vma->vm_pgoff -= grow;
>>> + }
>>> }
>>> anon_vma_unlock(vma);
>>> + return error;
>>> }
>>>
>>> struct vm_area_struct *
>>>
>>>
>>> _______________________________________________
>>> Vserver mailing list
>>> Vserver_at_list.linux-vserver.org
>>> http://list.linux-vserver.org/mailman/listinfo/vserver
>>>
>>
>>
>>
>>
>>
>
> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver
>
>
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Sun 23 Jan 2005 - 22:42:27 GMT by hypermail 2.1.3