There is now a kernel-2.6.38.8-5.mga in core/updates_testing to validate Suggested advisory: ------------------- This update addresses the folloving CVEs: * A heap overflow flaw in the EFI GUID Partition Table (GPT) implementation could allow a local attacker to cause a denial of service by mounting a disk containing specially-crafted partition tables. (CVE-2011-1776) * An unprivileged user can use flock syscall for NFS share to trigger unlimited resource leak and this could cause node DoS.(CVE-2011-2491) * The gfs2_fallocate function in fs/gfs2/file.c in the Linux kernel before 3.0-rc1 does not ensure that the size of a chunk allocation is a multiple of the block size, which allows local users to cause a denial of service (BUG and system crash) by arranging for all resource groups to have too little free space. (CVE-2011-2689) * Multiple off-by-one errors in the ext4 subsystem in the Linux kernel before 3.0-rc5 allow local users to cause a denial of service (BUG_ON and system crash) by accessing a sparse file in extent format with a write operation involving a block number corresponding to the largest possible 32-bit unsigned integer. (CVE-2011-2695) * IPv6 fragment identification generation is way beyond what we use for IPv4. It uses a single generator. Its not scalable and allows DOS attacks. (CVE-2011-2699) * A small buffer overflow in the radio driver si4713-i2c was fixed that could potentially used by local attackers to crash the kernel or potentially execute code. (CVE-2011-2700) * Fix Generic Receive Offload (GRO) Denial of Service Vulnerability. (CVE-2011-2723) * af_packet: prevent information leak to userspace (CVE-2011-2898) * A kernel information leak in the comedi driver from kernel to userspace was fixed. (CVE-2011-2909) * The befs_follow_link function in fs/befs/linuxvfs.c in the Linux kernel before 3.1-rc3 does not validate the length attribute of long symlinks, which allows local users to cause a denial of service (incorrect pointer dereference and OOPS) by accessing a long symlink on a malformed Be filesystem. (CVE-2011-2928) * Dan Kaminsky pointed out that using partial MD4 and using that to generate protocol sequence numbers and fragment IDS, of which only 24-bits are truly unguessable, seriously undermine the goals of random sequence number generation. Fix it by switching to MD5 usage. (CVE-2011-3188) * The name_len variable in CIFSFindNext is a signed int that gets set to the resume_name_len in the cifs_search_info. The resume_name_len however is unsigned and for some infolevels is populated directly from a 32 bit value sent by the server. If the server sends a very large value for this, then that value could look negative when converted to a signed int. That would make that value pass the PATH_MAX check later in CIFSFindNext. The name_len would then be used as a length value for a memcpy. It would then be treated as unsigned again, and the memcpy scribbles over a ton of memory. (CVE-2011-3191) Other fixes in this release: * mm: vmscan: Stop kswapd consuming 100% CPU when highest zone is small * move RLIMIT_NPROC check from set_user() to do_execve_common() (blocks privilege escalations related to buggy programs not checking setuid() return code) * ndiswrapper: add IoUnregisterPlugPlayNotification symbol (mga #2162) * xhci: (usb3) improvements and fixes * md: fixed looping on waiting for failed device, fix oops in hot_remove_disk, fixed two minor bugs in raid5 code. * firewire: ohci: do not bind to Pinnacle cards, avert panic * libata: fix unexpectedly frozen port after ata_eh_reset() * staging: rtl8192u: declare MODULE_FIRMWARE * nbd: limit module parameters to a sane value (prevents oops) * drm/radeon/r300/kms: do bounds checking for 3D_LOAD_VBPNTR and bump array limit * pmcraid: reject negative request size * option: add support for yuga series and huawei k3770, k3771, k3806, k4510, k4511, k4605 * add Sagemcom HiLo3G support
Are there some exploits that could be used to check that the security issues are fixed ?
CC: (none) => stormi
Hello, I would love to test it but I have a big problem with the kernel-desktop-2.6.38.8-5 on Mageia release 1 (Official) for x86_64 : The process "udevd" uses a lot of CPU ,and even too much.The PC becomes very slow and gets very hot. This problem appeared already in the version "kernel-desktop-2.6.38.8-4". But not with version "kernel-desktop-2.6.38.7-1" (I am forced to use it at the moment). Version of udev : $ rpm -qa | grep udev lib64gudev1.0_0-166-5.mga1 libudev0-166-5.mga1 lib64udev0-166-5.mga1 system-config-printer-udev-1.3.1-4.1.mga1 udev-166-5.mga1 libgudev1.0_0-166-5.mga1 Between the problem of kernel and also the problem of reader / writer optical ,slowly it becomes exhausting and frustrating to not having a Mageia 100% operational.
CC: (none) => geiger.david68210
So far I have no problem using this Kernel on both of my Dell laptop in i586 and x86_64 Mageia release.
CC: (none) => pham182b
No problems with it so far, laptop Pentium M i586. It would be more meaningful QA if there were some way to test some of the security fixes.
CC: (none) => eeeemail
No issues x86_64 Intel Q6600, nvidia graphics
I've opened Bug 2687 for a crash I had this morning, but I'm not sure it's actually a kernel problem, hardware, or mgaapplet. I'll run memtest overnight tonight, and see if it finds any problems.
CC: (none) => davidwhodgins
Blocks: (none) => 2162
I just installed it and rebooted. 1) The first time it froze on boot, with a message saying that an address was already assigned. I had mga1 dvd inserted, but that doesn't cause a problem with kernel 2.6.38.8-4. (It did start to boot to the hard disk.) It was also reading the dvd when it froze. The second time I booted, without the dvd inserted, it booted normally. 2) This kernel may have fixed a persistant problem. I have net_monitor-0.11-4.mga1 installed, which uses vnstat (1.10-2.mga1) to monitor network traffic -- which has almost never worked, despite being (almost) always running since installed in March. (It has functioned only part of 10 days. I use wine to run a similar app for comparison, which according to my Internet provider is reliable.) net_monitor has generally said incorrectly that eth0 -- my network connexion -- is down. net_monitor is now running correctly, and says that eth0 is up. It may be just a coincidence -- I'll watch it. 3) The corrections specified suggest that this kernel may solve occasional freezes with various apps since upgrading mdv2010.0 to mdv2010.2. I'll watch for that as well. (These freezes have occurred mostly in Seamonkey and/or Openoffice/Libreoffice, but I suspect the cause lies elsewhere, since it started after updating Linux, and not the applications in question, which were the upstream packages.) I'll report back.
CC: (none) => andre999.mga
Keywords: (none) => Security
Just tryed it on x86_64 on an intel core2 duo. It is working fine with my LVM over MD setup, the nvidia proprietary dkms module compiled properly and is working fine. My eSATA external HDD works too, as does my DVB-T card.
CC: (none) => r.h.michel+mageia
Not sure if this is a kernel setup problem or a libafs problem. As part of the kernel testing, I boot each of the kernels, and ensure dkms modules get recompiled, and everything generally works. While testing 2.6.38.8-xen-pvops-5.mga, the dkms compile appears to work, but upon openafs startup, it fails with ... Starting AFS client daemon: FATAL: Error inserting libafs (/lib/modules/2.6.38.8-xen-pvops-5.mga/dkms/3rdparty/libafs/libafs.ko.gz): Invalid module format I've reported this on the libafs bug 1034 report as well.
In 2.6.38.8-xen-pvops-5.mga, vboxdrv also fails to load with dmesg showing vboxdrv: no symbol version for module_layout In the 2.6.38.8-netbook-5.mga, 2.6.38.8-desktop-5.mga, 2.6.38.8-desktop586-5.mga, and 2.6.38.8-server-5.mga everything looks ok. The dkms compiled modules libafs and vboxdrv load, kde starts, sounds ok, and everything else looks good. What is the xen-pvops kernel supposed to be used for?
(In reply to comment #10) > In 2.6.38.8-xen-pvops-5.mga, vboxdrv also fails to load with dmesg showing > vboxdrv: no symbol version for module_layout > > In the 2.6.38.8-netbook-5.mga, 2.6.38.8-desktop-5.mga, > 2.6.38.8-desktop586-5.mga, > and 2.6.38.8-server-5.mga everything looks ok. The dkms compiled modules > libafs > and vboxdrv load, kde starts, sounds ok, and everything else looks good. Did you have the matching kernel-xen-pvops-devel installed ? > > What is the xen-pvops kernel supposed to be used for? It's for those wanteing to use xen as their virtualization platform
That makes the problem clear. :-) urpmi kernel-xen-pvops-devel-latest Package kernel-xen-pvops-devel-latest-2.6.38.8-4.mga1.i586 is already installed urpmi kernel-xen-pvops-devel gives me a choice between the 8-4 and 8-5 version. So the kernel-xen-pvops-devel-latest needs to be updated.
OK, with kernel-desktop-latest-2.6.38.8-5.mga1 (from updates_testing), the graphics card, the sound, the keyboard, the mouse, the Ethernet card, and the DVD drive all work properly. However, like the previous kernel ("-4.mga1"), my external 1 TB USB hard-drive is not detected by the OK. It *is* detected by the original Mageia 1 kernel, and by other computers. My lsusb output is: <<< [root@localhost src]# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 003: ID 046d:c316 Logitech, Inc. HID-Compliant Keyboard Bus 001 Device 004: ID 046d:c05a Logitech, Inc. Optical Mouse M90 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub >>> I should note that I've also ran into this bug in both kernels I tried, and was able to resolve it by installing the e1000e driver from sourceforge.net: https://bugzilla.redhat.com/show_bug.cgi?id=713315 Regards, â Shlomi Fish
CC: (none) => shlomif
Created attachment 790 [details] syslog output for kernel: BUG: unable to handle kernel paging request Not sure if this is a problem with libafs, the kernel, or another possible indication of bad ram (memtest86 ran for 14 hours the other day), but I got this error after shutting down openafs and openafs-server, and then running modprobe -vr libafs Required using alt+ctrl+sysrq magic keys to reboot. I'll test recreating the bug after I submit this report.
Bug reported in comment 14 is repeatable. Address in second crash was f4da5a07 instead of f812fbd7.
(In reply to comment #15) > Bug reported in comment 14 is repeatable. > > Address in second crash was f4da5a07 instead of f812fbd7. You are testing with kernel-linus... > Sep 14 20:19:08 hodgins kernel: Pid: 32372, comm: afs_rxevent Tainted: P 2.6.38.8-1.mga #1 PM800-8237/PM800-M2 An this oops seems to be libafs screwing up module refcounting, so this is not related to the update kernel. Can you add this libafs crash in a separate bug report.
I'm not sure now which kernel I was using in the first crash. In the second, I was using 2.6.38.8-server-5.mga. I've reported the libafs crash in bug 2751.
Is this ready to be validated? I've had no problems with it i586 or x86_64 in ~ 10 days of use. If you've resolved any issues Dave I think its safe to push now.
Comment 12 still has to be taken care of. The kernel-xen-pvops-devel-latest needs to be updated to 8-5, or anyone using it will have problems with dkms modules.
No regressions on kernel-desktop-2.6.38.8-5.mga-1-1.mga1.i586.rpm , on my i686 portable (since 110911). (see also comment 7) The boot problem the first time, with a mga1 dvd inserted, has not recurred. net_monitor now always starts on boot, and stays connected, which is a noticable improvement. The occasional freezes still occur. (Less than once a day.) Generally for about 30 seconds but sometimes several minutes. Usually affects only one application at a time, others being still active, and the mouse is generally still responsive. Often I can start (gnome) system monitor during these freezes. (Mostly affects Seamonkey and Libreoffice, but sometimes other applications.) Since installing this kernel, swap hasn't been used during these freezes. (Generally use less than half of ram and zero swap.) The occasional blank screen (which seems to be invoked by mouse movement) has happened twice, but this has happened before. It requires removing the battery then unplugging my portable, to allow rebooting. (Holding the power button down to power off does not work during these freezes.) After rebooting, everything works fine. The only possible regression noticed, very minor, is that now there is a disk access every few seconds. It could be that some process (daemon ?) which was blocked before, is now unblocked. Closing all ordinary applications (including net_monitor) does not stop this activity. There seems to be no reason for this disk access. It did not occur before upgrading to this kernel. All hardware (usb2, ethernet, dvd drive, synaptic touchpad, etc) on my portable functions without problems. For me this kernel is an improvement with no (significant) regressions, so I'm making this my default kernel. (again : kernel-desktop-2.6.38.8-5.mga-1-1.mga1.i586.rpm on a portable i686) I have a question : what would be the advantages/disadvantages (if any) to use the netbook kernel on my portable ? (I rarely run on battery, but disk shutdown when idle doesn't work.)
Reassigning back to packager until comment 19 is taken care of.
Assignee: qa-bugs => tmb
Seems upload bot had failed to upload some of the rpms on i586... kernel-xen-pvops-latest and kernel-xen-pvops-devel-latest are now available in updates_testing...
Assignee: tmb => qa-bugs
Everything looks good now, but with an update to mkinitrd showing up today, I think it's best to wait for that one to go first. Shouldn't take long to test the mkinitrd. Bug 2757. I've already checked mkinitrd with the i586 server kernel.
Depends on: (none) => 2757
(In reply to comment #13) > OK, with kernel-desktop-latest-2.6.38.8-5.mga1 (from updates_testing), the > graphics card, the sound, the keyboard, the mouse, the Ethernet card, and the > DVD drive all work properly. However, like the previous kernel ("-4.mga1"), my > external 1 TB USB hard-drive is not detected by the OK. It *is* detected by the > original Mageia 1 kernel, and by other computers. My lsusb output is: > > <<< > [root@localhost src]# lsusb > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub > Bus 001 Device 003: ID 046d:c316 Logitech, Inc. HID-Compliant Keyboard > Bus 001 Device 004: ID 046d:c05a Logitech, Inc. Optical Mouse M90 > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub > Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub > >>> Replying to myself, I'd like to note that it was a false alarm. Looking at dmesg, I noticed that the USB hard-disk was detected, but then got disconnected again. Apparently, it fell a little out of the port, and connecting it to a different port makes it better. Regards, -- Shlomi Fish
mkinitrd (bug 2757) has been validated this morning so the kernel can go with it. Advisory: --------------------------------- Suggested advisory: ------------------- This update addresses the folloving CVEs: * A heap overflow flaw in the EFI GUID Partition Table (GPT) implementation could allow a local attacker to cause a denial of service by mounting a disk containing specially-crafted partition tables. (CVE-2011-1776) * An unprivileged user can use flock syscall for NFS share to trigger unlimited resource leak and this could cause node DoS.(CVE-2011-2491) * The gfs2_fallocate function in fs/gfs2/file.c in the Linux kernel before 3.0-rc1 does not ensure that the size of a chunk allocation is a multiple of the block size, which allows local users to cause a denial of service (BUG and system crash) by arranging for all resource groups to have too little free space. (CVE-2011-2689) * Multiple off-by-one errors in the ext4 subsystem in the Linux kernel before 3.0-rc5 allow local users to cause a denial of service (BUG_ON and system crash) by accessing a sparse file in extent format with a write operation involving a block number corresponding to the largest possible 32-bit unsigned integer. (CVE-2011-2695) * IPv6 fragment identification generation is way beyond what we use for IPv4. It uses a single generator. Its not scalable and allows DOS attacks. (CVE-2011-2699) * A small buffer overflow in the radio driver si4713-i2c was fixed that could potentially used by local attackers to crash the kernel or potentially execute code. (CVE-2011-2700) * Fix Generic Receive Offload (GRO) Denial of Service Vulnerability. (CVE-2011-2723) * af_packet: prevent information leak to userspace (CVE-2011-2898) * A kernel information leak in the comedi driver from kernel to userspace was fixed. (CVE-2011-2909) * The befs_follow_link function in fs/befs/linuxvfs.c in the Linux kernel before 3.1-rc3 does not validate the length attribute of long symlinks, which allows local users to cause a denial of service (incorrect pointer dereference and OOPS) by accessing a long symlink on a malformed Be filesystem. (CVE-2011-2928) * Dan Kaminsky pointed out that using partial MD4 and using that to generate protocol sequence numbers and fragment IDS, of which only 24-bits are truly unguessable, seriously undermine the goals of random sequence number generation. Fix it by switching to MD5 usage. (CVE-2011-3188) * The name_len variable in CIFSFindNext is a signed int that gets set to the resume_name_len in the cifs_search_info. The resume_name_len however is unsigned and for some infolevels is populated directly from a 32 bit value sent by the server. If the server sends a very large value for this, then that value could look negative when converted to a signed int. That would make that value pass the PATH_MAX check later in CIFSFindNext. The name_len would then be used as a length value for a memcpy. It would then be treated as unsigned again, and the memcpy scribbles over a ton of memory. (CVE-2011-3191) Other fixes in this release: * mm: vmscan: Stop kswapd consuming 100% CPU when highest zone is small * move RLIMIT_NPROC check from set_user() to do_execve_common() (blocks privilege escalations related to buggy programs not checking setuid() return code) * ndiswrapper: add IoUnregisterPlugPlayNotification symbol (mga #2162) * xhci: (usb3) improvements and fixes * md: fixed looping on waiting for failed device, fix oops in hot_remove_disk, fixed two minor bugs in raid5 code. * firewire: ohci: do not bind to Pinnacle cards, avert panic * libata: fix unexpectedly frozen port after ata_eh_reset() * staging: rtl8192u: declare MODULE_FIRMWARE * nbd: limit module parameters to a sane value (prevents oops) * drm/radeon/r300/kms: do bounds checking for 3D_LOAD_VBPNTR and bump array limit * pmcraid: reject negative request size * option: add support for yuga series and huawei k3770, k3771, k3806, k4510, k4511, k4605 * add Sagemcom HiLo3G support ------------------------------------ SRPM: kernel-2.6.38.8-5.mga1.src.rpm Could sysadmin please push from core/updates_testing to core/updates along with the mkinitrd (bug 2757) mentioned above. Thankyou!
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Packages moved to updates.
Status: NEW => RESOLVEDCC: (none) => boklmResolution: (none) => FIXED
CC: andre999 => andre999mga
CC: boklm => (none)