77094 2005-01-07 17:52 0000 Kernel: grsecurity advisories (CAN-2005-{0179,0180,0504}) 2009-05-03 14:51:52 0000 1 1 1 Unclassified Gentoo Security Kernel unspecified All All RESOLVED FIXED [linux <2.6.12] P2 major --- 1 solar@gentoo.org security@gentoo.org jasmin-genbug@pacifica.ch kang@gentoo.org kerframil@gmail.com kern-sec@gentoo.org tklauser@nuerscht.ch solar@gentoo.org 2005-01-07 17:52:42 0000 From: Brad Spengler Subject: [grsec] grsecurity 2.1.0 release / 5 Linux kernel advisories Date: Fri, 7 Jan 2005 12:20:49 -0500 grsecurity 2.1.0 release / Linux Kernel advisories -------------------------------------------------------------------- Table Of Contents: 1) grsecurity 2.1.0 announcement and changelog 2) Linux Kernel advisory introduction 3) 2.4/2.6 random poolsize sysctl handler integer overflow 4) 2.6 scsi ioctl integer overflow and information leak 5) 2.2/2.4/2.6 moxa serial driver bss overflow 6) 2.4/2.6 RLIMIT_MEMLOCK bypass and (2.6) unprivileged user DoS 7) Attachments, including patches for all vulns, a POC for #3, and a working exploit for #6 1) grsecurity 2.1.0 announcement and changelog I'm happy to announce the release of grsecurity 2.1.0. It is being released initially for the 2.4.28 and 2.6.10 kernels and will be ported immediately to the next kernel versions when released. It can be downloaded at http://www.grsecurity.net. We are still actively seeking sponsorship, so if you benefit from using grsecurity and like the changes you see in 2.1.0, please consider sponsoring the future development and maintenance of the project. Changes in this release include: * New configuration file for full learning: /etc/grsec/learn_config * Learning heuristics have been optimized to better detect temporary file usage and reduce appropriately. * Learning heuristics have been modified to weight against reducing certain additional important directories. * User/group ID transitions have been added to the learning system. Any subject transitioning to less than 3 different users or 3 different groups that has CAP_SETUID or CAP_SETGID will have ID transitions added. This is useful to automatically secure applications that only transition to one or few users/groups like nobody/nogroup. * /proc/<pid>/* accesses are automatically rewritten as /proc by grlearn before being cached and written to disk * The inherit-based learning usable through the learning configuration file is usable through a regular policy as well simply by adding "i" instead of "l" to a subject for learning. * Inheritance is preserved whenever possible across uid/gid changes when the role resulting from the uid/gid change is no different from that before the change. * A complete ~95-99% efficient LFU-hash hybrid caching system has been added that greatly reduces the number of full object lookups by caching the result. The cache essentially mimics the filesystem around where applications are operating: nearly equivalent to having an object for every file and directory on the system, but without the wasted memory. The cache is invalidated on creates and deletes that cause a change in policy (through policy re-creation) and on renames of directories or symlinks. * Memory usage for non-full learning has been significantly reduced and all memory leaks have been plugged. * A new object mode has been added for hardlinks for more fine-grained permissions. See the sample policy file for information on what permissions are required to create a hardlink. Its corresponding audit flag has been added as well. * Destruction of unused shared memory feature added and included in the sysctl framework of grsecurity. This feature was ported from Openwall (http://www.openwall.com/linux). * A new option was added to the sysctl feature that enables at boot all features enabled in the kernel configuration, while allowing them to be changed via the sysctl interface until grsec_lock is set. * Policy statistics have been added to gradm that provide useful, security-relevant information on the policy you are loading into the kernel. You can view these statistics when enabling the system by running gradm -V -E. * Interactive performance of full-learning has improved by ~15% by reducing the number of context switches caused by grlearn doing small disk writes by using a write buffer (writing more once instead of less 1000 times) and keeping track of log entry lengths for quicker string matching. A signal handler was added to grlearn so that when learning is stopped, the write buffer is flushed to disk. * Kernel headers are no longer used for gradm * Updates from the PaX project (http://pax.grsecurity.net) * Bugfixes for things mentioned on the list, etc When patching your kernel for the 2.4.28 and 2.6.10 kernels, since they contain several vulnerabilities, make sure to also apply the secfix patches located on the website. 2) Linux Kernel advisory introduction Let me begin by giving you a timeline: December 15th: I send Linus a mail with a subject line of "RLIMIT_MEMLOCK bypass with locked stack" December 27th: The PaX team sends Linus a mail with a subject line of "2.6.9+ mlockall/expand_down DoS by unprivileged users" January 2nd: The PaX team resends the previous mail to Linux and Andrew Morton Between December 15th and today, Linus has committed many changes to the kernel. Between January 2nd and today, Andrew Morton has committed several changes to the kernel. 3 weeks is a sufficient amount of time to be able to expect even a reply about a given vulnerability. A patch for the vulnerability was attached to the mails, and in the PaX team's mails, a working exploit as well. Private notification of vulnerabilities is a privilege, and when that privilege is abused by not responding promptly, it deserves to be revoked. Using 'advanced static analysis': "cd drivers; grep copy_from_user -r ./* | grep -v sizeof", I discovered 4 exploitable vulnerabilities in a matter of 15 minutes. More vulnerabilities were found in 2.6 than in 2.4. It's a pretty sad state of affairs for Linux security when someone can find 4 exploitable vulnerabilities in a matter of minutes. Since there was no point in sending more vulnerability reports when the first hadn't even been responded to, I'm including all four of them in this mail, as well as a POC for the poolsize bug. The other bugs can have POCs written for just as trivially. The poolsize bug requires uid 0, but not any root capabilities. The scsi and serial bugs depend on the permissions of their respective devices, and thus can possibly be exploited as non-root. The scsi bug in particular has a couple different attack vectors that I haven't even bothered to investigate. Some of these bugs have gone unfixed for several years. The PaX team discovered the mlockall DoS. It has been fixed in PaX for 2 years. I have attached their mail and exploit code. I'd really like to know what's being done about this pitiful trend of Linux security, where it's 10x as easy to find a vulnerability in the kernel than it is in any app on the system, where isec releases at least one critical vulnerability for each kernel version. I don't see that the 2.6 development model is doing anything to help this (as the spectrum of these vulnerabilities demonstrate), by throwing experimental code into the kernel and claiming it to be "stable". Hopefully now these vulnerabilities will be fixed in a timely manner. 3) 2.4/2.6 random poolsize sysctl handler integer overflow In drivers/char/random.c: at poolsize_strategy(): > int len; ^ signed integer > > sysctl_poolsize = random_state->poolinfo.POOLBYTES; > > /* > > /* > * We only handle the write case, since the read case gets > * handled by the default handler (and we don't care if the > * write case happens twice; it's harmless). > */ > if (newval && newlen) { > len = newlen; ^ unsigned int converted to signed > if (len > table->maxlen) ^ comparison of two signed integers > len = table->maxlen; > if (copy_from_user(table->data, newval, len)) ^ copy_from_user with len possibly > table->maxlen 4) 2.6 scsi ioctl integer overflow and information leak In drivers/block/scsi_ioctl.c: at sg_scsi_ioctl(): > struct request *rq; > int err, in_len, out_len, bytes, opcode, cmdlen; ^ in_len, out_len are signed int > char *buffer = NULL, sense[SCSI_SENSE_BUFFERSIZE]; > > /* > * get in an out lengths, verify they don't exceed a page worth of data > */ > if (get_user(in_len, &sic->inlen)) ^ in_len is user-controlled > return -EFAULT; > if (get_user(out_len, &sic->outlen)) ^ out_len is user-controlled > return -EFAULT; > if (in_len > PAGE_SIZE || out_len > PAGE_SIZE) ^ signed int only has upper bound checked > return -EINVAL; > if (get_user(opcode, sic->data)) > return -EFAULT; > bytes = max(in_len, out_len); ... > rq->cmd_len = cmdlen; > if (copy_from_user(rq->cmd, sic->data, cmdlen)) > goto error; > > if (copy_from_user(buffer, sic->data + cmdlen, in_len)) ^ copy_from_user with size possibly > PAGE_SIZE > goto error; ... > if (copy_to_user(sic->data, buffer, out_len)) ^ copy_to_user with size possibly > PAGE_SIZE > err = -EFAULT; 5) 2.2/2.4/2.6 moxa serial driver bss overflow In drivers/char/moxa.c: >static unsigned char moxaBuff[10240]; In MoxaDriverIoctl(): > if(copy_from_user(&dltmp, argp, sizeof(struct dl_str))) > return -EFAULT; ^ dltmp.len is user-controlled > if(dltmp.cardno < 0 || dltmp.cardno >= MAX_BOARDS) > return -EINVAL; > > switch(cmd) > { > case MOXA_LOAD_BIOS: > i = moxaloadbios(dltmp.cardno, dltmp.buf, dltmp.len); ^ called with no length checking > return (i); > case MOXA_FIND_BOARD: > return moxafindcard(dltmp.cardno); > case MOXA_LOAD_C320B: > moxaload320b(dltmp.cardno, dltmp.buf, dltmp.len); ^ called with no length checking > default: /* to keep gcc happy */ > return (0); > case MOXA_LOAD_CODE: > i = moxaloadcode(dltmp.cardno, dltmp.buf, dltmp.len); ^ called with no length checking In moxaloadbios(): >static int moxaloadbios(int cardno, unsigned char __user *tmp, int len) >{ > void __iomem *baseAddr; > int i; > > if(copy_from_user(moxaBuff, tmp, len)) ^ copy_from_user with no length checking > return -EFAULT; In moxaloadcode(): > static int moxaloadcode(int cardno, unsigned char __user *tmp, int len) > { > void __iomem *baseAddr, *ofsAddr; > int retval, port, i; > > if(copy_from_user(moxaBuff, tmp, len)) ^ copy_from_user with no length checking > return -EFAULT; In moxaload320b(): >static int moxaload320b(int cardno, unsigned char __user *tmp, int len) >{ > void __iomem *baseAddr; > int i; > > if(len > sizeof(moxaBuff)) ^ signed int has only upper-bound checked > return -EINVAL; > if(copy_from_user(moxaBuff, tmp, len)) ^ copy_from_user with len possibly > sizeof(moxaBuff) > return -EFAULT; 6) 2.4/2.6 RLIMIT_MEMLOCK bypass and (2.6) unprivileged user DoS Taken from the mail from the PaX team to Linus and Andrew Morton: the 'culprit' patch is how the default RLIM_MEMLOCK and the privilege to call mlockall have changed in 2.6.9. namely, the former has been reduced to 32 pages while the latter has been relaxed to allow it for otherwise unprivileged users if their RLIM_MEMLOCK is bigger than the currently allocated vm. which is normally good enough, except as you now know there's a path that can increase the allocated vm without checking for RLIM_MEMLOCK. i'm attaching a small i386-specific demonstration, use the makefile to create the small self-contained executable, e.g., 'make alloc=0x100000' to have it allocate 1MB of stack and lock all of it. for demonstrating the full effect of locking down arbitrary amounts of memory, you'll have to set your stack rlimit to infinity (ulimit -s unlimited) and allocate as much memory as your memory overcommit policy allows (this may mean that you'll have to run multiple instances, if you have lots of memory). surprisingly, in my tests the kernel survived pretty well, it just crawled to a snail's speed as every mapped page access required disk i/o ;-). i didn't play with overcommit policies nor any special workloads, so there may very well be worse effects with that much locked memory. in any case, this may warrant 2.6.10.1 because as soon as the fix goes into -bk, anyone reading the logs can easily figure it out and reproduce the 'exploit'. the attached patch is the excerpt from PaX that survives the exploit, so i think it's good to go. solar@gentoo.org 2005-01-07 17:54:17 0000 http://grsecurity.net/linux-2.4.28-secfix-200501071141.patch solar@gentoo.org 2005-01-07 17:54:54 0000 http://grsecurity.net/linux-2.6.10-secfix-200501071130.patch solar@gentoo.org 2005-01-07 18:51:03 0000 06:40PM <spender> my patch won't work on processor's without an mmu 06:40PM <spender> for the isec bug 06:40PM <spender> err processors 06:40PM <spender> but it wasn't a problem for my case 06:40PM <spender> just for yours, you might want to add the missing function and export_symbol to mm/nommu.c 06:41PM <ms> no success with 2.6.8... 06:41PM <ms> however I notice 2.6.8 really sucks ;) <solar> so this and this are no good? http://bugs.gentoo.org/attachment.cgi?id=47891&action=view <solar> http://bugs.gentoo.org/attachment.cgi?id=47865&action=edit 06:42PM <spender> oh, no the 2.4 one is fine 06:42PM <spender> it's just the 2.6 06:43PM <spender> btw 06:43PM <spender> if grsec sources includes pax 06:43PM <spender> you need to use my patch for binfmt_elf.c 06:43PM <spender> because you need to hold the semaphore around both the do_brk and pax's do_mmap_pgoff 06:43PM <spender> can't just lock both separately 06:44PM <spender> but yea that patch you have there looks fine, just i think you have to export the do_brk_locked symbol 06:44PM <spender> well, if do_brk is exported in there already <solar> can I add this as a comment to that bug? 06:44PM <spender> yea 06:45PM <spender> but that 2.6 patch is better than the one i saw on lkml at least 06:45PM <spender> it has the sparc64 change solar@gentoo.org 2005-01-07 22:18:24 0000 grsec 2.4.28.2.0.1-200501051112 is in the tree, but will be -* masked for a little while pending testing and waiting/watching for upstream changes. Adds linux-2.4.28-CAN-2004-0814.patch & linux-2.4.28-random-poolsize.patch dsd@gentoo.org 2005-01-08 09:42:12 0000 06:44PM <spender> but yea that patch you have there looks fine, just i think you have to export the do_brk_locked symbol In mmap.c, do_brk is exported, and our patch adds do_brk_locked and exports it. In nommu.c, do_brk is not exported, and our patch adds do_brk_locked and does not export it. I think this is ok, see the next thing he said: 06:44PM <spender> well, if do_brk is exported in there already ...which its not. solar@gentoo.org 2005-01-09 07:17:50 0000 3) 2.4/2.6 random poolsize sysctl handler integer overflow #3 is fixed in grsec-sources and in the 2.6.x -ac branch. 4) 2.6 scsi ioctl integer overflow and information leak should be fixed in -ac branch. 5) 2.2/2.4/2.6 moxa serial driver bss overflow Brads Patch does not apply to 2.4.x (already in grsec I think) fixed in -ac 6) 2.4/2.6 RLIMIT_MEMLOCK bypass and (2.6) unprivileged user DoS This is fixed directly by the PaX patch. (fixed in -ac) Tim do you have any of this broken out and can attach here or other bugs? solar@gentoo.org 2005-01-09 08:02:35 0000 Yeah it was fixed in -ac7 2.6.10-ac7 + Fix failure at boot with some setups and ac6 (Alan Cox) | Dumb bug indeed o Fix random poolsize sysctl (Brad Spengler) o Fix scsi_ioctl leak (Brad Spengler) o Fix rlimit memlock (Brad Spengler) o Fix Moxa serial (Alan Cox) | While moxa won't actually even build on 2.6 the grsecurity fix | is wrong (for 2.2, 2.4 as well). Without it being CAP_SYS_RAWIO | a user can insert alternative bios firmware into the card. solar@gentoo.org 2005-01-09 08:04:18 0000 Created an attachment (id=48020) patch-2.6.10-ac-6-7.interdiff interdiff patch-2.6.10-ac6 patch-2.6.10-ac7 dsd@gentoo.org 2005-01-09 08:35:45 0000 Here are the broken out patches: http://dev.gentoo.org/~dsd/gentoo-dev-sources/release-10.04/dist/1115_sys-uselib-fix.patch http://dev.gentoo.org/~dsd/gentoo-dev-sources/release-10.04/dist/1120_moxa-overflow.patch http://dev.gentoo.org/~dsd/gentoo-dev-sources/release-10.04/dist/1125_random-poolsize-overflow.patch http://dev.gentoo.org/~dsd/gentoo-dev-sources/release-10.04/dist/1130_rlimit-memlock-dos.patch http://dev.gentoo.org/~dsd/gentoo-dev-sources/release-10.04/dist/1135_scsi-ioctl-overflox.patch gentoo-dev-sources is fixed, btw. solar@gentoo.org 2005-01-09 12:15:07 0000 dsd thanks. Can you please chmod 644 1130_rlimit-memlock-dos.patch I getting no permission to access atm. kerframil@gmail.com 2005-01-09 12:56:43 0000 @Solar, you can get the exact same patch from this tarball: http://seclists.org/lists/bugtraq/2005/Jan/att-0068/exploits_and_patches.tgz. or the genpatches tarball from a mirror, or from here (albeit as a patch to genpatches ;): http://genpatches.bkbits.net:8080/genpatches/cset@41e038bcWgRXUZFr9okc0cOZhtwNNg?nav=index.html|ChangeSet@-2d @dsd, I notice that you have asked for gentoo-dev-sources-2.6.10-r4 to be tested pending a move to stable. I'm about to reboot my production box with it so I'll post a works-for-me(tm) when I can. dsd@gentoo.org 2005-01-09 13:00:39 0000 Fixed permissions. 2.6.10-r4 is also stable already, hence me noting it as fixed :) kerframil@gmail.com 2005-01-09 13:05:12 0000 > 2.6.10-r4 is also stable already, hence me noting it as fixed :) Excellent. plasmaroo@gentoo.org 2005-01-09 13:07:05 0000 Created an attachment (id=48045) 2.6 Patch plasmaroo@gentoo.org 2005-01-09 13:10:12 0000 Created an attachment (id=48046) 2.4 Patch (*WARNING* Read comment below!) For 2.4 kernels you also need to apply the updated CAN-2004-0814 patches in addition to the 2.4 patch attached on this bug. For 2.4.28, link to and use http://dev.gentoo.org/~plasmaroo/patches/kernel/misc/security/linux-2.4.28-CAN-2004-0814.patch For 2.4.27, link to and use http://dev.gentoo.org/~plasmaroo/patches/kernel/misc/security/linux-2.4.27-CAN-2004-0814.2.patch For 2.4.26, link to and use http://dev.gentoo.org/~plasmaroo/patches/kernel/misc/security/linux-2.4.26-CAN-2004-0814.2.patch plasmaroo@gentoo.org 2005-01-09 13:22:43 0000 All done, following externally maintained sources still need fixing: hardened-(dev-)sources -- Adding hardened herd... hppa-sources -- Adding GMSoft... mips-sources -- Adding Kumba... openmosix-sources -- Adding cluster herd... pegasos-dev-sources -- Adding dholm... rsbac-(dev-)sources -- Adding kang... sparc-sources -- Adding Joker. gmsoft@gentoo.org 2005-01-10 09:46:05 0000 Done in hppa-sources-2.6.10_p10. voxus@gentoo.org 2005-01-10 09:53:03 0000 done for openMo6-sources. tklauser@nuerscht.ch 2005-01-11 02:30:20 0000 dsd: Applying the random poolsize overflow patch from: http://dev.gentoo.org/~dsd/gentoo-dev-sources/release-10.04/dist/1125_random-poolsize-overflow.patch generates Hunks because the line does not match with the 2.6.10 source. Albeit this is nothing serious I did a proper patch wich is attaches. You may want to apply it. tklauser@nuerscht.ch 2005-01-11 02:32:28 0000 Created an attachment (id=48178) Random poolsize overflow patch without hunk As described above tocharian@gentoo.org 2005-01-11 20:45:48 0000 ~x86 hardened-dev-sources-2.6.10 patched kang@gentoo.org 2005-01-13 15:56:53 0000 rsbac-sources (2.6) patched tocharian@gentoo.org 2005-01-13 19:14:09 0000 hardened-sources-2.4.28-r2 patched in ~x86 kumba@gentoo.org 2005-01-14 21:54:04 0000 We got 2.6.9 and 2.6.8.1 versions of this patch available? I've tweaked the current 2.6 patch for 2.6.9, but 2.6.8.1 is more interesting, in that net/ipv4/netfilter/ip_conntrack_proto_tcp.c is vastly different than what the patch expects. dholm@gentoo.org 2005-01-16 05:12:52 0000 pegasos-sources fixed joker@gentoo.org 2005-01-16 06:44:01 0000 fixed in sparc-sources-2.4.28-r6 dsd@gentoo.org 2005-01-17 07:28:02 0000 gentoo-dev-sources is done kumba@gentoo.org 2005-01-18 19:00:39 0000 mips-sources patched kang@gentoo.org 2005-01-21 05:37:23 0000 rsbac-sources 2.4 is also fixed in ~x86 koon@gentoo.org 2005-03-16 02:58:01 0000 CAN-2005-0504 is for : Buffer overflow in the MoxaDriverIoctl function for the moxa serial driver (moxa.c) in Linux 2.2.x, 2.4.x, and 2.6.x allows local users to execute arbitrary code via a certain modified length value. koon@gentoo.org 2005-03-16 03:10:44 0000 CAN-2005-0179 is for: Linux kernel 2.4.x and 2.6.x allows local users to cause a denial of service (CPU and memory consumption) and bypass RLIM_MEMLOCK limits via the mlockall call. CAN-2005-0180 is for: Multiple integer signedness errors in the sg_scsi_ioctl function in scsi_ioctl.c for Linux 2.6.x allow local users to read or modify kernel memory via negative integers in arguments to the scsi ioctl, which bypass a maximum length check before calling the copy_from_user and copy_to_user functions. The last one has no CVE apparently koon@gentoo.org 2005-03-16 03:16:48 0000 Mass-Ccing kern-sec@gentoo.org to make sure Kernel Security guys know about all of these... plasmaroo@gentoo.org 2005-03-29 05:48:51 0000 kang: Have you patched 2.6? I can't see any reference in the ChangeLog to this bug... kang@gentoo.org 2005-03-29 06:08:59 0000 I wrote i patched it: see comment #22 and #29 Since it was fixed before I saw this bug or had any CAN number I didn't wrote any of theses numbers in the ChangeLog. RSBAC is based on rsbacfixed which had latest -as and/or/additional/brad patches (first had brad patches, and since was integrated by rsbacfixed) (Now rsbacfixed has latest 2.6.11.z, I copy changelog from this kernel and bugs/CAN numbers whenever I have them after the patch) Anyway, 0180, 0179, 504 are ok. Ref: http://fixed.rsbac.org/ plasmaroo@gentoo.org 2005-03-29 07:05:57 0000 All fixed then, closing bug. rbu@gentoo.org 2009-05-03 14:14:57 0000 http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commit;h=26eecbf3543b7a57699ce5b0bed82b84d3b61705 48020 2005-01-09 08:04 0000 patch-2.6.10-ac-6-7.interdiff patch-2.6.10-ac-6-7.interdiff text/plain ZGlmZiAtdSBsaW51eC0yLjYuMTAvZHJpdmVycy9ibG9jay9zY3NpX2lvY3RsLmMgbGludXgtMi42 LjEwL2RyaXZlcnMvYmxvY2svc2NzaV9pb2N0bC5jCi0tLSBsaW51eC0yLjYuMTAvZHJpdmVycy9i bG9jay9zY3NpX2lvY3RsLmMJMjAwNC0xMi0yNiAxNzoyNzo1MC4wMDAwMDAwMDAgKzAwMDAKKysr IGxpbnV4LTIuNi4xMC9kcml2ZXJzL2Jsb2NrL3Njc2lfaW9jdGwuYwkyMDA1LTAxLTA3IDIzOjEy OjAyLjI2NzAxNDk3NiArMDAwMApAQCAtMzM5LDcgKzMzOSw4IEBACiAJCQkgc3RydWN0IGdlbmRp c2sgKmJkX2Rpc2ssIFNjc2lfSW9jdGxfQ29tbWFuZCBfX3VzZXIgKnNpYykKIHsKIAlzdHJ1Y3Qg cmVxdWVzdCAqcnE7Ci0JaW50IGVyciwgaW5fbGVuLCBvdXRfbGVuLCBieXRlcywgb3Bjb2RlLCBj bWRsZW47CisJdW5zaWduZWQgaW50IGJ5dGVzLCBvcGNvZGUsIGNtZGxlbiwgaW5fbGVuLCBvdXRf bGVuOworCWludCBlcnI7CiAJY2hhciAqYnVmZmVyID0gTlVMTCwgc2Vuc2VbU0NTSV9TRU5TRV9C VUZGRVJTSVpFXTsKIAogCS8qCmRpZmYgLXUgbGludXgtMi42LjEwL2RyaXZlcnMvY2hhci9tb3hh LmMgbGludXgtMi42LjEwL2RyaXZlcnMvY2hhci9tb3hhLmMKLS0tIGxpbnV4LTIuNi4xMC9kcml2 ZXJzL2NoYXIvbW94YS5jCTIwMDQtMTItMjggMTY6NTI6MDYuMDAwMDAwMDAwICswMDAwCisrKyBs aW51eC0yLjYuMTAvZHJpdmVycy9jaGFyL21veGEuYwkyMDA1LTAxLTA3IDIzOjA4OjEyLjYwMDky OTUyOCArMDAwMApAQCAtODA3LDYgKzgwNyw4IEBACiAJY2FzZSBUSU9DU1NFUklBTDoKIAkJcmV0 dXJuIG1veGFfc2V0X3NlcmlhbF9pbmZvKGNoLCBhcmdwKTsKIAlkZWZhdWx0OgorCQlpZighY2Fw YWJsZShDQVBfU1lTX1JBV0lPKSkKKwkJCXJldHVybiAtRVBFUk07CiAJCXJldHZhbCA9IE1veGFE cml2ZXJJb2N0bChjbWQsIGFyZywgcG9ydCk7CiAJfQogCXJldHVybiAocmV0dmFsKTsKZGlmZiAt dSBsaW51eC0yLjYuMTAvbW0vbW1hcC5jIGxpbnV4LTIuNi4xMC9tbS9tbWFwLmMKLS0tIGxpbnV4 LTIuNi4xMC9tbS9tbWFwLmMJMjAwNS0wMS0wNyAxNTozMTo0My4wMDAwMDAwMDAgKzAwMDAKKysr IGxpbnV4LTIuNi4xMC9tbS9tbWFwLmMJMjAwNS0wMS0wNyAyMzoxMDo1Mi40MTk2MzMzOTIgKzAw MDAKQEAgLTEzNjAsNiArMTM2MCwxMyBAQAogCQl2bV91bmFjY3RfbWVtb3J5KGdyb3cpOwogCQly ZXR1cm4gLUVOT01FTTsKIAl9CisJaWYgKCh2bWEtPnZtX2ZsYWdzICYgVk1fTE9DS0VEKSAmJiAh Y2FwYWJsZShDQVBfSVBDX0xPQ0spICYmCisJCQkoKHZtYS0+dm1fbW0tPmxvY2tlZF92bSArIGdy b3cpIDw8IFBBR0VfU0hJRlQpID4KKwkJCWN1cnJlbnQtPnNpZ25hbC0+cmxpbVtSTElNSVRfTUVN TE9DS10ucmxpbV9jdXIpIHsKKwkJYW5vbl92bWFfdW5sb2NrKHZtYSk7CisJCXZtX3VuYWNjdF9t ZW1vcnkoZ3Jvdyk7CisJCXJldHVybiAtRU5PTUVNOworCX0KIAl2bWEtPnZtX2VuZCA9IGFkZHJl c3M7CiAJdm1hLT52bV9tbS0+dG90YWxfdm0gKz0gZ3JvdzsKIAlpZiAodm1hLT52bV9mbGFncyAm IFZNX0xPQ0tFRCkKQEAgLTE0MjIsNiArMTQyOSwxMyBAQAogCQl2bV91bmFjY3RfbWVtb3J5KGdy b3cpOwogCQlyZXR1cm4gLUVOT01FTTsKIAl9CisJaWYgKCh2bWEtPnZtX2ZsYWdzICYgVk1fTE9D S0VEKSAmJiAhY2FwYWJsZShDQVBfSVBDX0xPQ0spICYmCisJCQkoKHZtYS0+dm1fbW0tPmxvY2tl ZF92bSArIGdyb3cpIDw8IFBBR0VfU0hJRlQpID4KKwkJCWN1cnJlbnQtPnNpZ25hbC0+cmxpbVtS TElNSVRfTUVNTE9DS10ucmxpbV9jdXIpIHsKKwkJYW5vbl92bWFfdW5sb2NrKHZtYSk7CisJCXZt X3VuYWNjdF9tZW1vcnkoZ3Jvdyk7CisJCXJldHVybiAtRU5PTUVNOworCX0KIAl2bWEtPnZtX3N0 YXJ0ID0gYWRkcmVzczsKIAl2bWEtPnZtX3Bnb2ZmIC09IGdyb3c7CiAJdm1hLT52bV9tbS0+dG90 YWxfdm0gKz0gZ3JvdzsKQEAgLTE4MzMsNiArMTg0Nyw3IEBACiAJZG93bl93cml0ZSgmY3VycmVu dC0+bW0tPm1tYXBfc2VtKTsKIAlyZXQgPSBfX2RvX2JyayhhZGRyLCBsZW4pOwogCXVwX3dyaXRl KCZjdXJyZW50LT5tbS0+bW1hcF9zZW0pOworCXJldHVybiByZXQ7CiB9CiAKIEVYUE9SVF9TWU1C T0woZG9fYnJrKTsKb25seSBpbiBwYXRjaDI6CnVuY2hhbmdlZDoKLS0tIGxpbnV4LnZhbmlsbGEt Mi42LjEwL2RyaXZlcnMvY2hhci9yYW5kb20uYwkyMDA0LTEyLTI1IDIxOjE1OjM0LjAwMDAwMDAw MCArMDAwMAorKysgbGludXgtMi42LjEwL2RyaXZlcnMvY2hhci9yYW5kb20uYwkyMDA1LTAxLTA3 IDIzOjA0OjU1LjQ1NDkwMDI4MCArMDAwMApAQCAtMTkwNiw3ICsxOTA2LDcgQEAKIAkJCSAgICAg dm9pZCBfX3VzZXIgKm9sZHZhbCwgc2l6ZV90IF9fdXNlciAqb2xkbGVucCwKIAkJCSAgICAgdm9p ZCBfX3VzZXIgKm5ld3ZhbCwgc2l6ZV90IG5ld2xlbiwgdm9pZCAqKmNvbnRleHQpCiB7Ci0JaW50 CWxlbjsKKwl1bnNpZ25lZCBpbnQJbGVuOwogCQogCXN5c2N0bF9wb29sc2l6ZSA9IHJhbmRvbV9z dGF0ZS0+cG9vbGluZm8uUE9PTEJZVEVTOwogCg== 48045 2005-01-09 13:07 0000 2.6 Compound Patch linux-2.6.10-77094.patch text/plain ZGlmZiAtdXJOcCBsaW51eC0yLjYuMTAvZHJpdmVycy9jaGFyL21veGEuYyBsaW51eC0yLjYuMTAt bmV3L2RyaXZlcnMvY2hhci9tb3hhLmMKLS0tIGxpbnV4LTIuNi4xMC9kcml2ZXJzL2NoYXIvbW94 YS5jCTIwMDUtMDEtMDcgMTA6NTE6MjMgLTA1MDAKKysrIGxpbnV4LTIuNi4xMC1uZXcvZHJpdmVy cy9jaGFyL21veGEuYwkyMDA1LTAxLTA3IDEwOjUxOjMzIC0wNTAwCkBAIC0xNjY4LDYgKzE2Njgs OCBAQCBpbnQgTW94YURyaXZlcklvY3RsKHVuc2lnbmVkIGludCBjbWQsIHVuCiAJCXJldHVybiAt RUZBVUxUOwogCWlmKGRsdG1wLmNhcmRubyA8IDAgfHwgZGx0bXAuY2FyZG5vID49IE1BWF9CT0FS RFMpCiAJCXJldHVybiAtRUlOVkFMOworCWlmKGRsdG1wLmxlbiA8IDAgfHwgZGx0bXAubGVuID4g c2l6ZW9mKG1veGFCdWZmKSkKKwkJcmV0dXJuIC1FSU5WQUw7CiAKIAlzd2l0Y2goY21kKQogCXsK QEAgLTI4MjIsOCArMjgyNCw2IEBAIHN0YXRpYyBpbnQgbW94YWxvYWQzMjBiKGludCBjYXJkbm8s IHVuc2kKIAl2b2lkIF9faW9tZW0gKmJhc2VBZGRyOwogCWludCBpOwogCi0JaWYobGVuID4gc2l6 ZW9mKG1veGFCdWZmKSkKLQkJcmV0dXJuIC1FSU5WQUw7CiAJaWYoY29weV9mcm9tX3VzZXIobW94 YUJ1ZmYsIHRtcCwgbGVuKSkKIAkJcmV0dXJuIC1FRkFVTFQ7CiAJYmFzZUFkZHIgPSBtb3hhQmFz ZUFkZHJbY2FyZG5vXTsKZGlmZiAtdXJOcCBsaW51eC0yLjYuMTAvZHJpdmVycy9ibG9jay9zY3Np X2lvY3RsLmMgbGludXgtMi42LjEwLW5ldy9kcml2ZXJzL2Jsb2NrL3Njc2lfaW9jdGwuYwotLS0g bGludXgtMi42LjEwL2RyaXZlcnMvYmxvY2svc2NzaV9pb2N0bC5jCTIwMDUtMDEtMDcgMTA6NTE6 MjQgLTA1MDAKKysrIGxpbnV4LTIuNi4xMC1uZXcvZHJpdmVycy9ibG9jay9zY3NpX2lvY3RsLmMJ MjAwNS0wMS0wNyAxMDo1MTozMyAtMDUwMApAQCAtMzM5LDcgKzMzOSw4IEBAIHN0YXRpYyBpbnQg c2dfc2NzaV9pb2N0bChzdHJ1Y3QgZmlsZSAqZmkKIAkJCSBzdHJ1Y3QgZ2VuZGlzayAqYmRfZGlz aywgU2NzaV9Jb2N0bF9Db21tYW5kIF9fdXNlciAqc2ljKQogewogCXN0cnVjdCByZXF1ZXN0ICpy cTsKLQlpbnQgZXJyLCBpbl9sZW4sIG91dF9sZW4sIGJ5dGVzLCBvcGNvZGUsIGNtZGxlbjsKKwl1 bnNpZ25lZCBpbnQgaW5fbGVuLCBvdXRfbGVuLCBieXRlcywgb3Bjb2RlLCBjbWRsZW47CisJaW50 IGVycjsKIAljaGFyICpidWZmZXIgPSBOVUxMLCBzZW5zZVtTQ1NJX1NFTlNFX0JVRkZFUlNJWkVd OwogCiAJLyoKZGlmZiAtdXJOcCBsaW51eC0yLjYuMTAvaW5jbHVkZS9saW51eC93cml0ZWJhY2su aCBsaW51eC0yLjYuMTAtbmV3L2luY2x1ZGUvbGludXgvd3JpdGViYWNrLmgKLS0tIGxpbnV4LTIu Ni4xMC9pbmNsdWRlL2xpbnV4L3dyaXRlYmFjay5oCTIwMDUtMDEtMDcgMTA6NTE6MjIgLTA1MDAK KysrIGxpbnV4LTIuNi4xMC1uZXcvaW5jbHVkZS9saW51eC93cml0ZWJhY2suaAkyMDA1LTAxLTA3 IDEwOjUxOjMzIC0wNTAwCkBAIC04Niw2ICs4Niw3IEBAIHN0YXRpYyBpbmxpbmUgdm9pZCB3YWl0 X29uX2lub2RlKHN0cnVjdCAKIGludCB3YWtldXBfYmRmbHVzaChsb25nIG5yX3BhZ2VzKTsKIHZv aWQgbGFwdG9wX2lvX2NvbXBsZXRpb24odm9pZCk7CiB2b2lkIGxhcHRvcF9zeW5jX2NvbXBsZXRp b24odm9pZCk7Cit2b2lkIHRocm90dGxlX3ZtX3dyaXRlb3V0KHZvaWQpOwogCiAvKiBUaGVzZSBh cmUgZXhwb3J0ZWQgdG8gc3lzY3RsLiAqLwogZXh0ZXJuIGludCBkaXJ0eV9iYWNrZ3JvdW5kX3Jh dGlvOwpkaWZmIC11ck5wIGxpbnV4LTIuNi4xMC9kcml2ZXJzL2NoYXIvcmFuZG9tLmMgbGludXgt Mi42LjEwLW5ldy9kcml2ZXJzL2NoYXIvcmFuZG9tLmMKLS0tIGxpbnV4LTIuNi4xMC9kcml2ZXJz L2NoYXIvcmFuZG9tLmMJMjAwNS0wMS0wNyAxMDo1MToyMyAtMDUwMAorKysgbGludXgtMi42LjEw LW5ldy9kcml2ZXJzL2NoYXIvcmFuZG9tLmMJMjAwNS0wMS0wNyAxMDo1MTozMyAtMDUwMApAQCAt MTkxMiw3ICsxOTEyLDcgQEAgc3RhdGljIGludCBwb29sc2l6ZV9zdHJhdGVneShjdGxfdGFibGUg KgogCQkJICAgICB2b2lkIF9fdXNlciAqb2xkdmFsLCBzaXplX3QgX191c2VyICpvbGRsZW5wLAog CQkJICAgICB2b2lkIF9fdXNlciAqbmV3dmFsLCBzaXplX3QgbmV3bGVuLCB2b2lkICoqY29udGV4 dCkKIHsKLQlpbnQJbGVuOworCXNpemVfdAlsZW47CiAJCiAJc3lzY3RsX3Bvb2xzaXplID0gcmFu ZG9tX3N0YXRlLT5wb29saW5mby5QT09MQllURVM7CiAKZGlmZiAtdXJOcCBsaW51eC0yLjYuMTAv bW0vbW1hcC5jIGxpbnV4LTIuNi4xMC1uZXcvbW0vbW1hcC5jCi0tLSBsaW51eC0yLjYuMTAvbW0v bW1hcC5jCTIwMDQtMTItMjQgMjI6MzU6MDAuMDAwMDAwMDAwICswMTAwCisrKyBsaW51eC0yLjYu MTAtbmV3L21tL21tYXAuYwkyMDA0LTEyLTI3IDE2OjM3OjQ3LjAwMDAwMDAwMCArMDEwMApAQCAt MTM2MCw2ICsxMzYwLDEzIEBAIGludCBleHBhbmRfc3RhY2soc3RydWN0IHZtX2FyZWFfc3RydWN0 ICoKIAkJdm1fdW5hY2N0X21lbW9yeShncm93KTsKIAkJcmV0dXJuIC1FTk9NRU07CiAJfQorCWlm ICgodm1hLT52bV9mbGFncyAmIFZNX0xPQ0tFRCkgJiYgIWNhcGFibGUoQ0FQX0lQQ19MT0NLKSAm JgorCQkJKCh2bWEtPnZtX21tLT5sb2NrZWRfdm0gKyBncm93KSA8PCBQQUdFX1NISUZUKSA+CisJ CQljdXJyZW50LT5zaWduYWwtPnJsaW1bUkxJTUlUX01FTUxPQ0tdLnJsaW1fY3VyKSB7CisJCWFu b25fdm1hX3VubG9jayh2bWEpOworCQl2bV91bmFjY3RfbWVtb3J5KGdyb3cpOworCQlyZXR1cm4g LUVOT01FTTsKKwl9CiAJdm1hLT52bV9lbmQgPSBhZGRyZXNzOwogCXZtYS0+dm1fbW0tPnRvdGFs X3ZtICs9IGdyb3c7CiAJaWYgKHZtYS0+dm1fZmxhZ3MgJiBWTV9MT0NLRUQpCkBAIC0xNDIyLDYg KzE0MjksMTMgQEAgaW50IGV4cGFuZF9zdGFjayhzdHJ1Y3Qgdm1fYXJlYV9zdHJ1Y3QgKgogCQl2 bV91bmFjY3RfbWVtb3J5KGdyb3cpOwogCQlyZXR1cm4gLUVOT01FTTsKIAl9CisJaWYgKCh2bWEt PnZtX2ZsYWdzICYgVk1fTE9DS0VEKSAmJiAhY2FwYWJsZShDQVBfSVBDX0xPQ0spICYmCisJCQko KHZtYS0+dm1fbW0tPmxvY2tlZF92bSArIGdyb3cpIDw8IFBBR0VfU0hJRlQpID4KKwkJCWN1cnJl bnQtPnNpZ25hbC0+cmxpbVtSTElNSVRfTUVNTE9DS10ucmxpbV9jdXIpIHsKKwkJYW5vbl92bWFf dW5sb2NrKHZtYSk7CisJCXZtX3VuYWNjdF9tZW1vcnkoZ3Jvdyk7CisJCXJldHVybiAtRU5PTUVN OworCX0KIAl2bWEtPnZtX3N0YXJ0ID0gYWRkcmVzczsKIAl2bWEtPnZtX3Bnb2ZmIC09IGdyb3c7 CiAJdm1hLT52bV9tbS0+dG90YWxfdm0gKz0gZ3JvdzsKZGlmZiAtdXJOcCBsaW51eC0yLjYuMTAv bW0vcGFnZS13cml0ZWJhY2suYyBsaW51eC0yLjYuMTAtbmV3L21tL3BhZ2Utd3JpdGViYWNrLmMK LS0tIGxpbnV4LTIuNi4xMC9tbS9wYWdlLXdyaXRlYmFjay5jCTIwMDUtMDEtMDcgMTA6NTE6MjQg LTA1MDAKKysrIGxpbnV4LTIuNi4xMC1uZXcvbW0vcGFnZS13cml0ZWJhY2suYwkyMDA1LTAxLTA3 IDEwOjUxOjMzIC0wNTAwCkBAIC0yNzYsNiArMjc2LDI4IEBAIHZvaWQgYmFsYW5jZV9kaXJ0eV9w YWdlc19yYXRlbGltaXRlZChzdHIKIH0KIEVYUE9SVF9TWU1CT0woYmFsYW5jZV9kaXJ0eV9wYWdl c19yYXRlbGltaXRlZCk7CiAKK3ZvaWQgdGhyb3R0bGVfdm1fd3JpdGVvdXQodm9pZCkKK3sKKwlz dHJ1Y3Qgd3JpdGViYWNrX3N0YXRlIHdiczsKKwlsb25nIGJhY2tncm91bmRfdGhyZXNoOworCWxv bmcgZGlydHlfdGhyZXNoOworCisgICAgICAgIGZvciAoIDsgOyApIHsKKwkJZ2V0X2RpcnR5X2xp bWl0cygmd2JzLCAmYmFja2dyb3VuZF90aHJlc2gsICZkaXJ0eV90aHJlc2gpOworCisgICAgICAg ICAgICAgICAgLyoKKyAgICAgICAgICAgICAgICAgKiBCb29zdCB0aGUgYWxsb3dhYmxlIGRpcnR5 IHRocmVzaG9sZCBhIGJpdCBmb3IgcGFnZQorICAgICAgICAgICAgICAgICAqIGFsbG9jYXRvcnMg c28gdGhleSBkb24ndCBnZXQgRG9TJ2VkIGJ5IGhlYXZ5IHdyaXRlcnMKKyAgICAgICAgICAgICAg ICAgKi8KKyAgICAgICAgICAgICAgICBkaXJ0eV90aHJlc2ggKz0gZGlydHlfdGhyZXNoIC8gMTA7 ICAgICAgLyogd2hlZWVlLi4uICovCisKKyAgICAgICAgICAgICAgICBpZiAod2JzLm5yX3Vuc3Rh YmxlICsgd2JzLm5yX3dyaXRlYmFjayA8PSBkaXJ0eV90aHJlc2gpCisgICAgICAgICAgICAgICAg ICAgICAgICBicmVhazsKKyAgICAgICAgICAgICAgICBibGtfY29uZ2VzdGlvbl93YWl0KFdSSVRF LCBIWi8xMCk7CisgICAgICAgIH0KK30KKworCiAvKgogICogd3JpdGViYWNrIGF0IGxlYXN0IF9t aW5fcGFnZXMsIGFuZCBrZWVwIHdyaXRpbmcgdW50aWwgdGhlIGFtb3VudCBvZiBkaXJ0eQogICog bWVtb3J5IGlzIGxlc3MgdGhhbiB0aGUgYmFja2dyb3VuZCB0aHJlc2hvbGQsIG9yIHVudGlsIHdl J3JlIGFsbCBjbGVhbi4KZGlmZiAtdXJOcCBsaW51eC0yLjYuMTAvbW0vdm1zY2FuLmMgbGludXgt Mi42LjEwLW5ldy9tbS92bXNjYW4uYwotLS0gbGludXgtMi42LjEwL21tL3Ztc2Nhbi5jCTIwMDUt MDEtMDcgMTA6NTE6MjQgLTA1MDAKKysrIGxpbnV4LTIuNi4xMC1uZXcvbW0vdm1zY2FuLmMJMjAw NS0wMS0wNyAxMDo1MTozMyAtMDUwMApAQCAtMzY5LDE0ICszNjksMTQgQEAgc3RhdGljIGludCBz aHJpbmtfbGlzdChzdHJ1Y3QgbGlzdF9oZWFkIAogCiAJCUJVR19PTihQYWdlQWN0aXZlKHBhZ2Up KTsKIAotCQlpZiAoUGFnZVdyaXRlYmFjayhwYWdlKSkKLQkJCWdvdG8ga2VlcF9sb2NrZWQ7Ci0K IAkJc2MtPm5yX3NjYW5uZWQrKzsKIAkJLyogRG91YmxlIHRoZSBzbGFiIHByZXNzdXJlIGZvciBt YXBwZWQgYW5kIHN3YXBjYWNoZSBwYWdlcyAqLwogCQlpZiAocGFnZV9tYXBwZWQocGFnZSkgfHwg UGFnZVN3YXBDYWNoZShwYWdlKSkKIAkJCXNjLT5ucl9zY2FubmVkKys7CiAKKwkJaWYgKFBhZ2VX cml0ZWJhY2socGFnZSkpCisJCQlnb3RvIGtlZXBfbG9ja2VkOworCiAJCXJlZmVyZW5jZWQgPSBw YWdlX3JlZmVyZW5jZWQocGFnZSwgMSwgc2MtPnByaW9yaXR5IDw9IDApOwogCQkvKiBJbiBhY3Rp dmUgdXNlIG9yIHJlYWxseSB1bmZyZWVhYmxlPyAgQWN0aXZhdGUgaXQuICovCiAJCWlmIChyZWZl cmVuY2VkICYmIHBhZ2VfbWFwcGluZ19pbnVzZShwYWdlKSkKQEAgLTgyNSw2ICs4MjUsOCBAQCBz aHJpbmtfem9uZShzdHJ1Y3Qgem9uZSAqem9uZSwgc3RydWN0IHNjCiAJCQkJYnJlYWs7CiAJCX0K IAl9CisKKwl0aHJvdHRsZV92bV93cml0ZW91dCgpOwogfQogCiAvKgpkaWZmIC11ck5wIGxpbnV4 LTIuNi4xMC9uZXQvaXB2NC9uZXRmaWx0ZXIvaXBfY29ubnRyYWNrX3Byb3RvX3RjcC5jIGxpbnV4 LTIuNi4xMC1uZXcvbmV0L2lwdjQvbmV0ZmlsdGVyL2lwX2Nvbm50cmFja19wcm90b190Y3AuYwot LS0gbGludXgtMi42LjEwL25ldC9pcHY0L25ldGZpbHRlci9pcF9jb25udHJhY2tfcHJvdG9fdGNw LmMJMjAwNS0wMS0wNyAxMDo1MToyNCAtMDUwMAorKysgbGludXgtMi42LjEwLW5ldy9uZXQvaXB2 NC9uZXRmaWx0ZXIvaXBfY29ubnRyYWNrX3Byb3RvX3RjcC5jCTIwMDUtMDEtMDcgMTA6NTE6MzMg LTA1MDAKQEAgLTkwNiw3ICs5MDYsOCBAQCBzdGF0aWMgaW50IHRjcF9wYWNrZXQoc3RydWN0IGlw X2Nvbm50cmFjCiAJCWlmIChpbmRleCA9PSBUQ1BfUlNUX1NFVAogCQkgICAgJiYgKCh0ZXN0X2Jp dChJUFNfU0VFTl9SRVBMWV9CSVQsICZjb25udHJhY2stPnN0YXR1cykKIAkJICAgICAgICAgJiYg Y29ubnRyYWNrLT5wcm90by50Y3AubGFzdF9pbmRleCA8PSBUQ1BfU1lOQUNLX1NFVCkKLQkJICAg ICAgICB8fCBjb25udHJhY2stPnByb3RvLnRjcC5sYXN0X2luZGV4ID09IFRDUF9BQ0tfU0VUKQor CQkgICAgICAgIHx8ICghdGVzdF9iaXQoSVBTX0FTU1VSRURfQklULCAmY29ubnRyYWNrLT5zdGF0 dXMpCisJCQkgJiYgY29ubnRyYWNrLT5wcm90by50Y3AubGFzdF9pbmRleCA9PSBUQ1BfQUNLX1NF VCkpCiAJCSAgICAmJiBhZnRlcihudG9obCh0aC0+YWNrX3NlcSksCiAJCSAgICAJICAgICBjb25u dHJhY2stPnByb3RvLnRjcC5sYXN0X3NlcSkpIHsKIAkJCS8qIElnbm9yZSBSU1QgY2xvc2luZyBk b3duIGludmFsaWQgU1lOIG9yIEFDSwo= 48046 2005-01-09 13:10 0000 2.4 Patch (*WARNING* Read comment below!) linux-2.4.28-77094.patch text/plain ZGlmZiAtdXIgbGludXgtMi40LjI4L2RyaXZlcnMvY2hhci9tb3hhLmMgbGludXgtMi40LjI4LnBs YXNtYXJvby9kcml2ZXJzL2NoYXIvbW94YS5jCi0tLSBsaW51eC0yLjQuMjgvZHJpdmVycy9jaGFy L21veGEuYwkyMDAxLTEwLTI1IDIxOjUzOjQ3LjAwMDAwMDAwMCArMDEwMAorKysgbGludXgtMi40 LjI4LnBsYXNtYXJvby9kcml2ZXJzL2NoYXIvbW94YS5jCTIwMDUtMDEtMDggMDI6NTQ6NDkuMTk1 NjM2MTkyICswMDAwCkBAIC0xNzcxLDYgKzE3NzEsOCBAQAogCQlyZXR1cm4gLUVGQVVMVDsKIAlp ZihkbHRtcC5jYXJkbm8gPCAwIHx8IGRsdG1wLmNhcmRubyA+PSBNQVhfQk9BUkRTKQogCQlyZXR1 cm4gLUVJTlZBTDsKKwlpZihkbHRtcC5sZW4gPCAwIHx8IGRsdG1wLmxlbiA+IHNpemVvZihtb3hh QnVmZikpCisJCXJldHVybiAtRUlOVkFMOwogCiAJc3dpdGNoKGNtZCkKIAl7CkBAIC0yOTI3LDgg KzI5MjksNiBAQAogCXVuc2lnbmVkIGxvbmcgYmFzZUFkZHI7CiAJaW50IGk7CiAKLQlpZihsZW4g PiBzaXplb2YobW94YUJ1ZmYpKQotCQlyZXR1cm4gLUVJTlZBTDsKIAlpZihjb3B5X2Zyb21fdXNl cihtb3hhQnVmZiwgdG1wLCBsZW4pKQogCQlyZXR1cm4gLUVGQVVMVDsKIAliYXNlQWRkciA9IG1v eGFCYXNlQWRkcltjYXJkbm9dOwpkaWZmIC11ciBsaW51eC0yLjQuMjgvZHJpdmVycy9jaGFyL3Jh bmRvbS5jIGxpbnV4LTIuNC4yOC5wbGFzbWFyb28vZHJpdmVycy9jaGFyL3JhbmRvbS5jCi0tLSBs aW51eC0yLjQuMjgvZHJpdmVycy9jaGFyL3JhbmRvbS5jCTIwMDQtMTEtMTcgMTE6NTQ6MjEuMDAw MDAwMDAwICswMDAwCisrKyBsaW51eC0yLjQuMjgucGxhc21hcm9vL2RyaXZlcnMvY2hhci9yYW5k b20uYwkyMDA1LTAxLTA4IDAyOjU0OjQ5LjE5ODYzNTczNiArMDAwMApAQCAtMTc4Nyw3ICsxNzg3 LDcgQEAKIAkJCSAgICAgdm9pZCAqb2xkdmFsLCBzaXplX3QgKm9sZGxlbnAsCiAJCQkgICAgIHZv aWQgKm5ld3ZhbCwgc2l6ZV90IG5ld2xlbiwgdm9pZCAqKmNvbnRleHQpCiB7Ci0JaW50CWxlbjsK KwlzaXplX3QJbGVuOwogCQogCXN5c2N0bF9wb29sc2l6ZSA9IHJhbmRvbV9zdGF0ZS0+cG9vbGlu Zm8uUE9PTEJZVEVTOwogCg== 48178 2005-01-11 02:32 0000 Random poolsize overflow patch without hunk random-poolsize-int-overflow.patch text/plain LS0tIGxpbnV4LTIuNi4xMC9kcml2ZXJzL2NoYXIvcmFuZG9tLmMJMjAwNC0xMi0yNCAyMjozMzo1 MS4wMDAwMDAwMDAgKzAxMDAKKysrIGxpbnV4LTIuNi4xMC10azEvZHJpdmVycy9jaGFyL3JhbmRv bS5jCTIwMDUtMDEtMTEgMTE6MjM6NDAuMzUxNDA5NTY4ICswMTAwCkBAIC0xOTA2LDcgKzE5MDYs NyBAQAogCQkJICAgICB2b2lkIF9fdXNlciAqb2xkdmFsLCBzaXplX3QgX191c2VyICpvbGRsZW5w LAogCQkJICAgICB2b2lkIF9fdXNlciAqbmV3dmFsLCBzaXplX3QgbmV3bGVuLCB2b2lkICoqY29u dGV4dCkKIHsKLQlpbnQJbGVuOworCXNpemVfdAlsZW47CiAJCiAJc3lzY3RsX3Bvb2xzaXplID0g cmFuZG9tX3N0YXRlLT5wb29saW5mby5QT09MQllURVM7CiAK