/proc/PID/io may be used for gathering private information. E.g. for
openssh and vsftpd daemons wchars/rchars may be used to learn the
precise password length. Restrict it to processes being able to ptrace
the target process.
ptrace_may_access() is needed to prevent keeping open file descriptor of
"io" file, executing setuid binary and gathering io information of the
setuid'ed process.
exit_mm() sets ->mm == NULL then it does mmput()->exit_mmap() which
frees the memory.
However select_bad_process() checks ->mm != NULL before TIF_MEMDIE,
so it continues to kill other tasks even if we have the oom-killed
task freeing its memory.
Change select_bad_process() to check ->mm after TIF_MEMDIE, but skip
the tasks which have already passed exit_notify() to ensure a zombie
with TIF_MEMDIE set can't block oom-killer. Alternatively we could
probably clear TIF_MEMDIE after exit_mmap().
The compiler, at least for ix86 and m68k, validly warns that the
comparison:
next <= (loff_t)-1
is always true (and it's always true also for x86-64 and probably all
other arches - as long as pgoff_t isn't wider than loff_t). The
intention appears to be to avoid wrapping of "next", so rather than
eliminating the pointless comparison, fix the loop to indeed get exited
when "next" would otherwise wrap.
On m68k the following warning is observed:
fs/fscache/page.c: In function '__fscache_uncache_all_inode_pages':
fs/fscache/page.c:979: warning: comparison is always false due to limited range of data type
Currently skb_gro_header_slow unconditionally resets frag0 and
frag0_len. However, when we can't pull on the skb this leaves
the GRO fields in an inconsistent state.
This patch fixes this by only resetting those fields after the
pskb_may_pull test.
Signed-off-by: Herbert Xu <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
2cfb25e...
by
stephen hemminger <email address hidden>
What is supposed to happen:
* bridge with the lowest ID is elected root (for example: B)
* C detects that A->C is higher cost path and puts in blocking state
What happens. Bridge with lowest id (B) is elected correctly as
root and things start out fine initially. But then config BPDU
doesn't get transmitted from A -> C. Because of that
the link from A-C is transistioned to the forwarding state.
The root cause of this is that the configuration messages
is generated with bogus message age, and dropped before
sending.
In the standardmessage_age is supposed to be:
the time since the generation of the Configuration BPDU by
the Root that instigated the generation of this Configuration BPDU.
Reimplement this by recording the timestamp (age + jiffies) when
recording config information. The old code incorrectly used the time
elapsed on the ageing timer which was incorrect.
Signed-off-by: Stephen Hemminger <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
cifs: lower default and max wsize to what 2.6.39 can handle
This patch is intended for 2.6.39-stable kernels only and is needed to
fix a regression introduced in 2.6.39. Prior to 2.6.39, when signing was
enabled on a socket the client only sent single-page writes. This
changed with commit ca83ce3, which made signed and unsigned connections
use the same codepaths for write calls.
This caused a regression when working with windows servers. Windows
machines will reject writes larger than the MaxBufferSize when signing
is active, but do not clear the CAP_LARGE_WRITE_X flag in the protocol
negotiation. The upshot is that when signing is active, windows servers
often reject large writes from the client in 2.6.39.
Because 3.0 adds support for larger wsize values, simply cherry picking
the upstream patches that fix the wsize negotiation isn't sufficient to
fix this issue. We also need to alter the maximum and default values to
something suitable for 2.6.39.
This patch also accounts for the change in field name from sec_mode to
secMode that went into 3.0.
CAP_LARGE_WRITEX is ignored when signing is active. Also, the maximum
size for a write without CAP_LARGE_WRITEX should be the maxBuf that
the server sent in the NEGOTIATE request.
Fix the wsize negotiation to take this into account. While we're at it,
alter the other wsize definitions to use sizeof(WRITE_REQ) to allow for
slightly larger amounts of data to potentially be written per request.
Signed-off-by: Jeff Layton <email address hidden>
Signed-off-by: Steve French <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
6013096...
by
Linus Torvalds <email address hidden>
vfs: fix race in rcu lookup of pruned dentry
Backport of commit 59430262401bec02d415179c43dbe5b8819c09ce
done by Hugh Dickins <email address hidden>
Don't update *inode in __follow_mount_rcu() until we'd verified that
there is mountpoint there. Kudos to Hugh Dickins for catching that
one in the first place and eventually figuring out the solution (and
catching a braino in the earlier version of patch).
