- 10 Oct, 2005 8 commits
-
-
Greg KH authored
-
David Howells authored
Plug request_key_auth memleak. This can be triggered by unprivileged users, so is local DoS. Signed-off-by:
Chris Wright <chrisw@osdl.org> Signed-Off-By:
David Howells <dhowells@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Dave Jones authored
Please consider for next 2.6.13, it is a minor security issue allowing users to turn on drm debugging when they shouldn't... This fell through the cracks. Until Josh pointed me at http://bugs.gentoo.org/show_bug.cgi?id=107893Signed-off-by:
-
Linus Torvalds authored
Avoid 'names_cache' memory leak with CONFIG_AUDITSYSCALL The nameidata "last.name" is always allocated with "__getname()", and should always be free'd with "__putname()". Using "putname()" without the underscores will leak memory, because the allocation will have been hidden from the AUDITSYSCALL code. Arguably the real bug is that the AUDITSYSCALL code is really broken, but in the meantime this fixes the problem people see. Reported by Robert Derr, patch by Rick Lindsley. Acked-by:
Al Viro <viro@ftp.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@osdl.org> Signed-off-by:
-
David S. Miller authored
We need to use stricter memory barriers around the block load and store instructions we use to save and restore the FPU register file. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Stephen Hemminger authored
Please consider this change for 2.6.13-stable Since BIC is the default congestion control algorithm, this fix is quite important. Missing parenthesis in causes BIC to be slow in increasing congestion window. Spotted by Injong Rhee. Signed-off-by:
Stephen Hemminger <shemminger@osdl.org> Signed-off-by:
-
Pavel Roskin authored
The orinoco driver can send uninitialized data exposing random pieces of the system memory. This happens because data is not padded with zeroes when its length needs to be increased. Reported by Meder Kydyraliev <meder@o0o.nu> Signed-off-by:
Pavel Roskin <proski@gnu.org> Signed-off-by:
-
Stefan Richter authored
Fixes for reference counting problems, deadlocks, and delays when SBP-2 devices are unplugged or unbound from sbp2, or when unloading of sbp2/ ohci1394/ pcilynx is attempted. Most often reported symptoms were hotplugs remaining undetected once a FireWire disk was unplugged since the knodemgrd kernel thread went to uninterruptible sleep, and "modprobe -r sbp2" being unable to complete because still being in use. Patch is equivalent to commit abd559b1 in 2.6.14-rc3 plus a fix which is necessary together with 2.6.13's scsi core API (linux1394.org commit r1308 by Ben Collins). Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: Ben Collins <bcollins@debian.org> Signed-off-by:
-
- 03 Oct, 2005 9 commits
-
-
Chris Wright authored
-
Alexey Kuznetsov authored
Handle better the case where the sender sends full sized frames initially, then moves to a mode where it trickles out small amounts of data at a time. This known problem is even mentioned in the comments above tcp_grow_window() in tcp_input.c, specifically: ... * The scheme does not work when sender sends good segments opening * window and then starts to feed us spagetti. But it should work * in common situations. Otherwise, we have to rely on queue collapsing. ... When the sender gives full sized frames, the "struct sk_buff" overhead from each packet is small. So we'll advertize a larger window. If the sender moves to a mode where small segments are sent, this ratio becomes tilted to the other extreme and we start overrunning the socket buffer space. tcp_clamp_window() tries to address this, but it's clamping of tp->window_clamp is a wee bit too aggressive for this particular case. Fix confirmed by Ion Badulescu. Signed-off-by:
-
Stephen Hemminger authored
Patch from Joel Sing to fix the default congestion control algorithm for incoming connections. If a new congestion control handler is added (via module), it should become the default for new connections. Instead, the incoming connections use reno. The cause is incorrect initialisation causes the tcp_init_congestion_control() function to return after the initial if test fails. Signed-off-by:
-
Stephen Hemminger authored
Here is the patch (fuzz removed) for 2.6.13.2 that fixes OOPs when using bonding with skge. Skge driver was bringing link up/down when changing mac address. This doesn't work in the bonding environment, and is more effort than needed. Fixes-bug: http://bugzilla.kernel.org/show_bug.cgi?id=5271Signed-off-by:
-
Paolo 'Blaisorblade' Giarrusso authored
We were leaking pmd pages when 3_LEVEL_PGTABLES was enabled. This fixes that, has been well tested and is included in mainline tree. Please include in -stable as well. Signed-off-by:
Jeff Dike <jdike@addtoit.com> Signed-off-by:
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by:
-
Julian Anastasov authored
ip_vs_ftp when loaded can create NAT connections with unknown client port for passive FTP. For such expectations we lookup with cport=0 on incoming packet but it matches the format of the persistence templates causing packets to other persistent virtual servers to be forwarded to real server without creating connection. Later the reply packets are treated as foreign and not SNAT-ed. If the IPVS box serves both FTP and other services (eg. HTTP) for the time we wait for first packet for the FTP data connections with unknown client port (there can be many), other HTTP connections that have nothing common to the FTP conn break, i.e. HTTP client sends SYN to the virtual IP but the SYN+ACK is not NAT-ed properly in IPVS box and the client box returns RST to real server IP. I.e. the result can be 10% broken HTTP traffic if 10% of the time there are passive FTP connections in connecting state. It hurts only IPVS connections. This patch changes the connection lookup for packets from clients: * introduce IP_VS_CONN_F_TEMPLATE connection flag to mark the connection as template * create new connection lookup function just for templates - ip_vs_ct_in_get * make sure ip_vs_conn_in_get hits only connections with IP_VS_CONN_F_NO_CPORT flag set when s_port is 0. By this way we avoid returning template when looking for cport=0 (ftp) Signed-off-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
-
David Stevens authored
per-socket multicast filters were not being applied to all sockets in the case of an exact-match bound address, due to an over-exuberant "return" in the look-up code. Fix below. IPv4 does not have this problem. Thanks to Hoerdt Mickael for reporting the bug. Signed-off-by:
David L Stevens <dlstevens@us.ibm.com> Signed-off-by:
-
Alexander Nyberg authored
It turns out that the BUG_ON() in fs/exec.c: de_thread() is unreliable and can trigger due to the test itself being racy. de_thread() does while (atomic_read(&sig->count) > count) { } ..... ..... BUG_ON(!thread_group_empty(current)); but release_task does write_lock_irq(&tasklist_lock) __exit_signal (this is where atomic_dec(&sig->count) is run) __exit_sighand __unhash_process takes write lock on tasklist_lock remove itself out of PIDTYPE_TGID list write_unlock_irq(&tasklist_lock) so there's a clear (although small) window between the atomic_dec(&sig->count) and the actual PIDTYPE_TGID unhashing of the thread. And actually there is no need for all threads to have exited at this point, so we simply kill the BUG_ON. Big thanks to Marc Lehmann who provided the test-case. Fixes Bug 5170 (http://bugme.osdl.org/show_bug.cgi?id=5170) Signed-off-by:Alexander Nyberg <alexn@telia.com> Cc: Roland McGrath <roland@redhat.com> Cc: Andrew Morton <akpm@osdl.org> Cc: Ingo Molnar <mingo@elte.hu> Acked-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Ivan Kokshaysky authored
In some cases, especially on modern laptops with a lot of PCI and cardbus bridges, we're unable to assign correct secondary/subordinate bus numbers to all cardbus bridges due to BIOS limitations unless we are using "pci=assign-busses" boot option. So some cardbus controllers may not have attached subordinate pci_bus structure, and yenta driver must cope with it - just ignore such cardbus bridges. For example, see https://bugzilla.novell.com/show_bug.cgi?id=113778Signed-off-by:
Ivan Kokshaysky <ink@jurassic.park.msu.ru> Signed-off-by:
-
- 17 Sep, 2005 12 commits
-
-
Chris Wright authored
-
Ian Abbott authored
ftdi_sio: I messed up the baud_base for custom baud rate support in 2.6.13. The attached one-liner patch fixes it. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Linus Torvalds authored
It's a dword thing, and the value we write is a dword. Doing a byte write to it is nonsensical, and writes only the low byte, which only contains the enable bit. So we enable a nonsensical address (usually zero), which causes the controller no end of problems. Trivial fix, but nasty to find. Signed-off-by:
-
Andi Kleen authored
There was a pretty bad bug in there that the code would always check the full VMA, not the range the user requested. When the VMA to be checked was merged with the previous VMA this could lead to spurious failures. Signed-off-by:
-
Dave Kleikamp authored
JFS: jfs_delete_inode should always call clear_inode. > From Chuck Ebbert: I'm submitting this patch for -stable: - it reportedly fixes an oops - it's already in 2.6.13-git Signed-off-by:
Dave Kleikamp <shaggy@austin.ibm.com> Signed-off-by:
-
Patrick McHardy authored
In 2.6.13-rcX the MASQUERADE target was changed not to exclude local packets for better source address consistency. This breaks DHCP clients using UDP sockets when the DHCP requests are caught by a MASQUERADE rule because the MASQUERADE target drops packets when no address is configured on the outgoing interface. This patch makes it ignore packets with a source address of 0. Thanks to Rusty for this suggestion. Signed-off-by:
Patrick McHardy <kaber@trash.net> Signed-off-by:
-
Willy Tarreau authored
This ports the Sun GEM ROM mapping/enable fixes it sunhme (which used the same PCI ROM mapping code). Without this, I get NULL MAC addresses for all 4 ports (it's a SUN QFE). With it, I get the correct addresses (the ones printed on the label on the card). Signed-off-by:
-
Linus Torvalds authored
This same patch was reported to fix the MAC address detection on sunhme (next patch). Most people seem to be running this on Sparcs or PPC machines, where we get the MAC address from their respective firmware rather than from the (previously broken) ROM mapping routines. Signed-off-by:
-
Linus Torvalds authored
This is one heck of a confused driver. It uses a byte write to a dword register to enable a ROM resource that it doesn't even seem to be using. "Lost and wandering in the desert of confusion" Signed-off-by:
-
Manfred Spraul authored
R�diger found a bug in nv_open that explains some of the reports with duplex mismatches: nv_open calls nv_update_link_speed for initializing the hardware link speed registers. If current link setting matches the values in np->linkspeed and np->duplex, then the function does nothing. Usually, doing nothing is the right thing, but not in nv_open: During nv_open, the registers must be initialized because the nic was reset. The attached patch fixes that by setting np->linkspeed to an invalid value before calling nv_update_link_speed from nv_open. Signed-Off-By:
Manfred Spraul <manfred@colorfullife.com> Signed-off-by:
Jeff Garzik <jgarzik@pobox.com> Signed-off-by:
-
Maxim Giryaev authored
This patch adds lost sockfd_put() in 32bit compat rounting_ioctl() on 64bit platforms, bug found by Vasiliy Averin <vvs@sw.ru>. I believe this is a security issues, since user can fget() file as many times as he wants to. So file refcounter can be overlapped and first fput() will free resources though there will be still structures pointing to the file, mnt, dentry etc. Also fput() sets f_dentry and f_vfsmnt to NULL, so other file users will OOPS. The oops can be done under files_lock and others, so this can be an exploitable DoS on SMP. Didn't checked it on practice actually. Signed-Off-By:
Kirill Korotaev <dev@sw.ru> Signed-Off-By:
Maxim Giryaev <gem@sw.ru> Signed-off-by:
-
Maxim Giryaev authored
This patch adds lost fput in 32bit tiocgdev ioctl on x86-64 I believe this is a security issues, since user can fget() file as many times as he wants to. So file refcounter can be overlapped and first fput() will free resources though there will be still structures pointing to the file, mnt, dentry etc. Also fput() sets f_dentry and f_vfsmnt to NULL, so other file users will OOPS. The oops can be done under files_lock and others, so this is really exploitable DoS on SMP. Didn't checked it on practice actually. (chrisw: Update to use fget_light/fput_light) Signed-Off-By:
-
- 10 Sep, 2005 11 commits
-
-
Chris Wright authored
-
Al Viro authored
Fix unchecked __get_user that could be tricked into generating a memory read on an arbitrary address. The result of the read is not returned directly but you may be able to divine some information about it, or use the read to cause a crash on some architectures by reading hardware state. CAN-2005-2492. Fix from Al Viro, ack from Dave Miller. Signed-off-by:
-
David Woodhouse authored
When we copy 32bit ->msg_control contents to kernel, we walk the same userland data twice without sanity checks on the second pass. Second version of this patch: the original broke with 64-bit arches running 32-bit-compat-mode executables doing sendmsg() syscalls with unaligned CMSG data areas Another thing is that we use kmalloc() to allocate and sock_kfree_s() to free afterwards; less serious, but also needs fixing. Patch by Al Viro, David Miller, David Woodhouse (sparc64 clean compile fix from David Miller) Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
Stephen Hemminger authored
[IPV4]: Reassembly trim not clearing CHECKSUM_HW This was found by inspection while looking for checksum problems with the skge driver that sets CHECKSUM_HW. It did not fix the problem, but it looks like it is needed. If IP reassembly is trimming an overlapping fragment, it should reset (or adjust) the hardware checksum flag on the skb. Signed-off-by:
-
David S. Miller authored
Based upon a report from Jason Wever. Signed-off-by:
-
Herbert Xu authored
[CRYPTO] Fix boundary check in standard multi-block cipher processors Fixes Bug 5194 (IPSec related Oops in 2.6.13). The boundary check in the standard multi-block cipher processors are broken when nbytes is not a multiple of bsize. In those cases it will always process an extra block. This patch corrects the check so that it processes at most nbytes of data. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Herbert Xu authored
[NET]: 2.6.13 breaks libpcap (and tcpdump) Patrick McHardy says: Never mind, I got it, we never fall through to the second switch statement anymore. I think we could simply break when load_pointer returns NULL. The switch statement will fall through to the default case and return 0 for all cases but 0 > k >= SKF_AD_OFF. Here's a patch to do just that. I left BPF_MSH alone because it's really a hack to calculate the IP header length, which makes no sense when applied to the special data. Signed-off-by:
-
Ivan Kokshaysky authored
I had some time to think about PCI assign issues in 2.6.13-rc series. The major problem here is that we call pci_assign_unassigned_resources() way too early - at subsys_initcall level. Therefore we give no chances to ACPI and PnP routines (called at fs_initcall level) to reserve their respective resources properly, as the comments in drivers/pnp/system.c and drivers/acpi/motherboard.c suggest: /** * Reserve motherboard resources after PCI claim BARs, * but before PCI assign resources for uninitialized PCI devices */ So I moved the pci_assign_unassigned_resources() call to pcibios_assign_resources() (fs_initcall), which should hopefully fix a lot of problems and make PCIBIOS_MIN_IO tweaks unnecessary. Other changes: - remove resource assignment code from pcibios_assign_resources(), since it duplicates pci_assign_unassigned_resources() functionality and actually does nothing in 2.6.13; - modify ROM assignment code as per Ben's suggestion: try to use firmware settings by default (if PCI_ASSIGN_ROMS is not set); - set CARDBUS_IO_SIZE back to 4K as it's a wonderful stress test for various setups. Confirmed by Tero Roponen <teanropo@cc.jyu.fi> (who had problems with the 4kB CardBus IO size previously). Signed-off-by:
-
Benjamin Herrenschmidt authored
This fixes a problem with pci_map_rom() which doesn't properly update the ROM BAR value with the address thas allocated for it by the PCI code. This problem, among other, breaks boot on Mac laptops. It'ss a new version based on Linus latest one with better error checking. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Mark Haverkamp authored
This was noticed by Doug Bazamic and the fix found by Mark Salyzyn at Adaptec. There was an error in the BUG_ON() statement that validated the calculated fib size which can cause the driver to panic. Signed-off-by:
Mark Haverkamp <markh@osdl.org> Acked-by:
James Bottomley <James.Bottomley@SteelEye.com> Signed-off-by:
-
Michael Krufky authored
I wish I had seen this before 2.6.13 was released... I guess this only goes to show that there haven't been any testers using saa7134-hybrid dvb/v4l boards that depend on the tda1004x module, during the 2.6.13-rc series :-( Please apply this to 2.6.14, and also to 2.6.13.1 -stable. Without this patch, users will have to EXPLICITLY select tda1004x in Kconfig. This SHOULD be done automatically when saa7134-dvb is selected. This patch corrects this problem. saa7134-dvb must select tda1004x Signed-off-by:
Michael Krufky <mkrufky@m1k.net> Signed-off-by:
-
