- 15 Dec, 2005 4 commits
-
-
Greg Kroah-Hartman authored
-
Sven Hartge authored
irq.c is missing the inclusion of asm/io.h, which causes readb() and writeb() the be undefined. Signed-off-by:
Sven Hartge <hartge@ds9.argh.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Chris Wright <chrisw@osdl.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Al Viro authored
You could open the /proc/sys/net/ipv4/conf/<if>/<whatever> file, then wait for interface to go away, try to grab as much memory as possible in hope to hit the (kfreed) ctl_table. Then fill it with pointers to your function. Then do read from file you've opened and if you are lucky, you'll get it called as ->proc_handler() in kernel mode. So this is at least an Oops and possibly more. It does depend on an interface going away though, so less of a security risk than it would otherwise be. Signed-off-by: -
Stephen Hemminger authored
This fixes the RCU race on bridge delete interface. Basically, the network device has to be detached from the bridge in the first step (pre-RCU), rather than later. At that point, no more bridge traffic will come in, and the other code will not think that network device is part of a bridge. This should also fix the XEN test problems. If there is another 2.6.13-stable, add it as well. Signed-off-by:
Stephen Hemminger <shemminger@osdl.org> Signed-off-by:
-
- 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:
David Howells <dhowells@redhat.com> Signed-off-by:
-
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:
-
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:
-
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 7 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:
-
