acinclude.m4 | 3 3 + 0 - 0 !
src/afs/LINUX/osi_vnodeops.c | 4 4 + 0 - 0 !
2 files changed, 7 insertions(+)

 linux 3.16: switch to iter_file_splice_write

Users of generic_file_splice_write need to switch to
using iter_file_splice_write.

Reviewed-on: http://gerrit.openafs.org/11302

acinclude.m4 | 1 1 + 0 - 0 !
src/afs/LINUX/osi_vnodeops.c | 38 33 + 5 - 0 !
2 files changed, 34 insertions(+), 5 deletions(-)

 linux 3.16: convert to new write_iter/read_iter ops

Change read/write operations to the new write_iter/read_iter
operations.

Reviewed-on: http://gerrit.openafs.org/11303

src/afs/afs_segments.c | 10 8 + 2 - 0 !
1 file changed, 8 insertions(+), 2 deletions(-)

 unix cm: avoid using stale dv in afs_storeallsegments

It was reported in RT 131976 that on Linux some file
corruption was observed when doing mmap writes to
a file substantially larger than the cache size.

osi_VM_StoreAllSegments drops locks and asks the OS to flush
any dirty pages in the file 's mapping.  This will trigger
calls into our writepage op, and if the number of dirty
cache chunks is too high (as will happen for a file larger
than the cache size), afs_DoPartialWrite will recursively
call afs_StoreAllSegments and some chunks will be written
back to the server.  After potentially doing this several
times, control will return to the original afs_StoreAllSegments.

At that point the data version that was stored before
osi_VM_StoreAllSegments is no longer correct, leading to
possible data corruption.

Triggering this bug requires writing a file larger than the
cache so that partial stores are done, and writing enough
data to exceed the system's maximum dirty ratio and cause
it to initiate writeback.

To fix, just wait until after osi_VM_StoreAllSegments to
look at and store the data version

FIXES 131976

Reviewed-on: http://gerrit.openafs.org/11644
Tested-by: BuildBot <buildbot@rampaginggeek.com>

acinclude.m4 | 1 1 + 0 - 0 !
src/afs/LINUX/osi_compat.h | 4 4 + 0 - 0 !
src/cf/linux-test4.m4 | 9 8 + 1 - 0 !
3 files changed, 13 insertions(+), 1 deletion(-)

 linux: d_alias becomes d_u.d_alias
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

The fields in struct dentry are re-arranged so that d_alias
shares space wth d_rcu inside the d_u union.  Some references
need to change from d_alias to d_u.d_alias.

The kernel change was introduced for 3.19 but was also backported
to the 3.18 stable series in 3.18.1, so this commit is required
for 3.19 and current 3.18 kernels.

Reviewed-on: http://gerrit.openafs.org/11642

src/afs/afs_osi_pag.c | 58 58 + 0 - 0 !
src/afs/afs_prototypes.h | 2 2 + 0 - 0 !
2 files changed, 60 insertions(+)

 libafs: api to create and free vrequests

Add a pair of functions to allocate and free struct vrequests, which
are to be used to avoid having struct vrequests on the stack.

Reviewed-on: http://gerrit.openafs.org/11074

src/afs/LINUX/osi_prototypes.h | 3 3 + 0 - 0 !
src/afs/LINUX/osi_vcache.c | 63 63 + 0 - 0 !
src/afs/LINUX24/osi_prototypes.h | 3 3 + 0 - 0 !
src/afs/LINUX24/osi_vcache.c | 36 36 + 0 - 0 !
src/afs/afs_daemons.c | 66 5 + 61 - 0 !
5 files changed, 110 insertions(+), 61 deletions(-)

 linux: move code to reset the root to afs/linux
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Move the Linux specific bit of code to reset the root to
afs/LINUX platform specific files.  Things that play with
the Linux vfs internals should not be exposed here.

No functional change, but this helps cleanup some ifdef
mess.

Reviewed-on: http://gerrit.openafs.org/11641
Tested-by: BuildBot <buildbot@rampaginggeek.com>

src/volser/vos.c | 2 2 + 0 - 0 !
src/volser/vsprocs.c | 8 8 + 0 - 0 !
2 files changed, 10 insertions(+)

 vos: clear nvldbentry before sending on the wire

Don't leak stack data onto the wire. Clear nvldbentry before use.

FIXES 131907 (CVE-2015-3282)

(cherry picked from commit 415a2aad4c1e9ab5d034b62989e4c16a37b5dcc7)

src/bozo/bos.c | 44 22 + 22 - 0 !
1 file changed, 22 insertions(+), 22 deletions(-)

 bos: use crypt for commands where spoofing could be a risk

bos defaults to not requiring crypt in a lot of cases, instead using clear.

As the simplest way to secure the channel is to enable crypt, do so.

FIXES 131782 (CVE-2015-3283)

(cherry picked from commit 62926630a82b8635d1cb1514b852f9f7a2609311)

src/afs/afs_pioctl.c | 5 5 + 0 - 0 !
1 file changed, 5 insertions(+)

 afs: clear pioctl data interchange buffer before use

Avoid leaking data in pioctl interchange buffers; clear the memory
when one is allocated.

FIXES 131892 (CVE-2015-3284)

(cherry picked from commit 592a99d6e693bc640e2bdfc2e7e5243fcedc8f93)

src/afs/afs_pioctl.c | 3 1 + 2 - 0 !
1 file changed, 1 insertion(+), 2 deletions(-)

 afs: use correct output buffer for fscmd pioctl

MRAFS added the FsCmd pioctl for passing messages to the fileserver;
a bug causes it to write into the wrong memory and potentially panic
clients.

FIXES 131896 (CVE-2015-3285)

(cherry picked from commit ef671f497e9161ec2759446d594789495d3346f1)

src/vlserver/vlprocs.c | 74 8 + 66 - 0 !
1 file changed, 8 insertions(+), 66 deletions(-)

 vlserver: disable regex volume name processing in listattributesn2

For the interim and until it is needed, this is most prudently
simply disabled.

FIXES 131890

(cherry picked from commit 22481ab3705522ac1988b7de038c4dbc1e5009a9)

src/rx/rx.c | 31 21 + 10 - 0 !
1 file changed, 21 insertions(+), 10 deletions(-)

 rx: cve-2015-7762 and cve-2015-7763

CVE-2015-7762:

The CMU/Transarc/IBM definition of rx_AckDataSize(nAcks) was mistakenly
computed from sizeof(struct rx_ackPacket) and inadvertently added three
octets to the computed ack data size.  When constructing ack packets
these three octets were not assigned a value but were written to the
network.

Beginning with AFS 3.3, IBM extended the ACK packet with the "maxMTU" ack
trailer value which was appended to the packet according to the
rx_AckDataSize() computation.  As a result the three unassigned octets
were unintentionally cemented into the ACK packet format.

In OpenAFS commit 4916d4b4221213bb6950e76dbe464a09d7a51cc3 Nickolai
Zeldovich <kolya@mit.edu> noticed that the size produced by the
rx_AckDataSize(nAcks) macro was dependent upon the compiler and processor
architecture.  The rx_AckDataSize() macro was altered to explicitly
expose the three octets that are included in the computation.
Unfortunately, the failure to initialize the three octets went unnoticed.

The Rx implementation maintains a pool of packet buffers that are reused
during the lifetime of the process.  When an ACK packet is constructed
three octets from a previously received or transmitted packets will be
leaked onto the network.  These octets can include data from a
received packet that was encrypted on the wire and then decrypted.

If the received encrypted packet is a duplicate or if it is outside the
valid window, the decrypted packet will be used immediately to construct
an ACK packet.

CVE-2015-7763

In OpenAFS commit c7f9307c35c0c89f7ec8ada315c81ebc47517f86 the ACK packet
was further extended in an attempt to detect the path MTU between two
peers.  When the ACK reason is RX_ACK_PING a variable number of octets is
appended to the ACK following the ACK trailers.

The implementation failed to initialize all of the padding region.
A variable amount of data from previous packets can be leaked onto the
network.  The padding region can include data from a received packet
that was encrypted on the wire and then decrypted.

OpenAFS 1.5.75 through 1.5.78 and all 1.6.x releases (including release
candidates) are vulnerable.

Credits:

  Thanks to John Stumpo for identifying both vulnerabilities.

  Thanks to Simon Wilkinson for patch development.

  Thanks to Ben Kaduk for managing the security release cycle.

src/afs/afs_pioctl.c | 11 7 + 4 - 0 !
1 file changed, 7 insertions(+), 4 deletions(-)

 [patch] afs: pioctl kernel memory overrun

CVE-2015-8312:
Any pioctl with an input buffer size (ViceIoctl->in_size)
exactly equal to AFS_LRALLOCSIZE (4096 bytes) will cause
a one-byte overwrite of its kernel memory working buffer.
This may crash the operating system or cause other
undefined behavior.

The attacking pioctl must be a valid AFS pioctl code.
However, it need not specify valid arguments (in the ViceIoctl),
since only rudimentary checking is done in afs_HandlePioctl.
Most argument validation occurs later in the individual
pioctl handlers.

Nor does the issuer need to be authenticated or authorized
in any way, since authorization checks also occur much later,
in the individual pioctl handlers.  An unauthorized user
may therefore trigger the overrun by either crafting his
own malicious pioctl, or by issuing a privileged
command, e.g. 'fs newalias', with appropriately sized but
otherwise arbitrary arguments.  In the latter case, the
attacker will see the expected error message:
 "fs: You do not have the required rights to do this operation"
but in either case the damage has been done.

Pioctls are not logged or audited in any way (except those
that cause loggable or auditable events as side effects).

root cause:
afs_HandlePioctli() calls afs_pd_alloc() to allocate two
two afs_pdata structs, one for input and one for output.
The memory for these buffers is based on the requested
size, plus at least one extra byte for the null terminator
to be set later:
  requested size	allocated
  =================	=================================
  > AFS_LRALLOCSIZ	osi_Alloc(size+1)
  <= AFS_LRALLOCSIZ	afs_AllocLargeSize(AFS_LRALLOCSIZ)

afs_HandlePioctl then adds a null terminator to each buffer,
one byte past the requested size.  This is safe in all cases
except one: if the requested in_size was _exactly_
AFS_LRALLOCSIZ (4096 bytes), this null is one byte beyond
the allocated storage, zeroing a byte of kernel memory.

Commit 6260cbecd0795c4795341bdcf98671de6b9a43fb introduced
the null terminators and they were correct at that time.
But the commit message warns:
 "note that this works because PIGGYSIZE is always less than
  AFS_LRALLOCSIZ"

Commit f8ed1111d76bbf36a466036ff74b44e1425be8bd introduced
the bug by increasing the maximum size of the buffers but
failing to account correctly for the null terminator in
the case of input buffer size == AFS_LRALLOCSIZ.

Commit 592a99d6e693bc640e2bdfc2e7e5243fcedc8f93 (master
version of one of the fixes in the recent 1.6.13 security
release) is the fix that drew my attention to this new
bug.  Ironically, 592a99 (combined with this commit), will
make it possible to eliminate the "offending" null termination
line altogether since it will now be performed automatically by
afs_pd_alloc().

[kaduk@mit.edu: adjust commit message for CVE number assignment,

src/ptserver/ptprocs.c | 20 13 + 7 - 0 !
1 file changed, 13 insertions(+), 7 deletions(-)

 [patch] openafs-sa-2016-001 group creation by foreign users

CVE-2016-2860:

The ptserver permits foreign-cell users to create groups as if they were
system:administrators.  In particular, groups in the user namespace
(with no colon) and the system: namespace can be created.  No group
quota is enforced for the creation of these groups, but they will be
owned by system:administrators and cannot be changed by the user that
created them.  When processing requests from foreign users, the
creator ID is overwritten with the ID of system:administrators, and
that field is later used for access control checks in
CorrectGroupName(), called from CreateEntry().

The access-control bypass is not possible for creating user entries,
since there is an early check in CreateOK() that only permits
administrators to create users, using a correct test for whether
the call is being made by an administrator.

FIXES 132822

[Based on a patch by Jeffrey Altman.]

src/rx/rx.c | 16 16 + 0 - 0 !
1 file changed, 16 insertions(+)

 openafs-sa-2017-001: rx: sanity-check received mtu and twind values

Rather than blindly trusting the values received in the
(unauthenticated) ack packet trailer, apply some minmial sanity checks
to received values.  natMTU and regular MTU values are subject to
Rx minmium/maximum packet sizes, and the transmit window cannot drop
below one without risk of deadlock.

The maxDgramPackets value that can also be present in the trailer
already has sufficient sanity checking.

Extremely low MTU values (less than 28 == RX_HEADER_SIZE) can cause us
to set a negative "maximum usable data" size that gets used as an
(unsigned) packet length for subsequent allocation and computation,
triggering an assertion when the connection is used to transmit data.

FIXES 134450

(cherry picked from commit 894555f93a2571146cb9ca07140eb98c7a424b01)
(cherry picked from commit eae2575dc738bd69bb6a0a84f87f02f5cf2b4eb9)

src/afs/VNOPS/afs_vnop_attrs.c | 3 3 + 0 - 0 !
src/afs/VNOPS/afs_vnop_create.c | 1 1 + 0 - 0 !
src/afs/VNOPS/afs_vnop_dirops.c | 2 2 + 0 - 0 !
src/afs/VNOPS/afs_vnop_symlink.c | 2 2 + 0 - 0 !
src/afs/afs_disconnected.c | 1 1 + 0 - 0 !
src/afs/afs_segments.c | 1 1 + 0 - 0 !
src/libafscp/afscp_file.c | 1 1 + 0 - 0 !
src/venus/afsio.c | 1 1 + 0 - 0 !
8 files changed, 12 insertions(+)

 openafs-sa-2016-002 afsstorestatus information leak

Marc Dionne reported that portions of the AFSStoreStatus structure
were not written to before being sent over the network for
operations such as create, symlink, etc., leaking the contents
of the kernel stack to observers.  Which fields in the request
are used are controlled by a flags field, and so if a field was
not going to be used by the server, it was sometimes left
uninitialized.

Fix the information leak by zeroing out the structure before use.

FIXES 132847

src/afs/afs_pioctl.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 openafs-sa-2016-002 afsstorevolumestatus information leak

The AFSStoreVolumeStatus structure is used as an input to the
RXAFS_SetVolumeStatus RPC; it contains a Mask field that controls
which of the other fields will actually be read by the server
during the RPC processing.  Unfortunately, the client only
wrote to the fields indicated by the mask, leaving the other
fields uninitialized for transmission on the wire, leaking
some contents of kernel memory.

Plug the information leak by zeroing the entire structure before use.

FIXES 132847

src/bucoord/commands.c | 1 1 + 0 - 0 !
src/libadmin/vos/vsprocs.c | 1 1 + 0 - 0 !
src/volser/vos.c | 4 2 + 2 - 0 !
src/volser/vsprocs.c | 1 1 + 0 - 0 !
4 files changed, 5 insertions(+), 2 deletions(-)

 openafs-sa-2016-002 vldblistbyattributes information leak

The VldbListByAttributes structure is used as an input to several
RPCs; it contains a Mask field that controls
which of the other fields will actually be read by the server
during the RPC processing.  Unfortunately, the client only
wrote to the fields indicated by the mask, leaving the other
fields uninitialized for transmission on the wire, leaking
some contents of client memory.

Plug the information leak by zeroing the entire structure before use.

FIXES 132847

src/libadmin/vos/afs_vosAdmin.c | 1 1 + 0 - 0 !
src/venus/cacheout.c | 1 1 + 0 - 0 !
src/vlserver/vlclient.c | 2 2 + 0 - 0 !
3 files changed, 4 insertions(+)

 openafs-sa-2016-002 listaddrbyattributes information leak

The ListAddrByAttributes structure is used as an input to the GetAddrsU
RPC; it contains a Mask field that controls which of the other fields
will actually be read by the server during the RPC processing.
Unfortunately, the client only wrote to the fields indicated by the
mask, leaving the other fields uninitialized for transmission on the
wire, leaking some contents of client memory.

Plug the information leak by zeroing the entire structure before use.

FIXES 132847

src/dir/buffer.c | 3 3 + 0 - 0 !
1 file changed, 3 insertions(+)

 dir: fileserver leaks names of file and directories

Summary:
Due to incomplete initialization or clearing of reused memory,
fileserver directory objects are likely to contain "dead" directory
entry information.  These extraneous entries are not active - that is,
they are logically invisible to the fileserver and client.  However,
they are physically visible on the fileserver vice partition, on the
wire in FetchData replies, and on the client cache partition.  This
constitutes a leak of directory information.

Characterization:

src/afs/afs_buffer.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 afs: do not leak stale data in buffers

Similar to the previous commit, zero out the buffer when fetching
a new slot, to avoid the possibility of leaving stale data in
a reused buffer.

We are not supposed to write such stale data back to a fileserver,
but this is an extra precaution in case of bugs elsewhere -- memset
is not as expensive as it was in the 1980s.

Reviewed-on: https://gerrit.openafs.org/12459

src/dir/dir.c | 4 3 + 1 - 0 !
1 file changed, 3 insertions(+), 1 deletion(-)

 dir: do not leak contents of deleted directory entries

Deleting an AFS directory entry (afs_dir_Delete) merely removes the
entry logically by updating the allocation map and hash table.  However,
the entry itself remains on disk - that is, both the cache manager's
cache partition and the fileserver's vice partitions.

This constitutes a leak of directory entry information, including the
object's name and MKfid (vnode and uniqueid).  This leaked information
is also visible on the wire during FetchData requests and volume
operations.

Modify afs_dir_Delete to clear the contents of deleted directory
entries.

Patchset notes:
This commit only prevents leaks for newly deleted entries.  Another
commit in this patchset prevents leaks of partial object names upon
reuse of pre-existing deleted entries.  A third commit in this
patchset prevents yet another kind of directory entry leak, when
internal buffers are reused to create or enlarge existing directories.
All three patches are required to prevent new leaks.  Two additional
salvager patches are also included to assist administrators in the
cleanup of pre-existing leaks.

[kaduk@mit.edu: style nit for sizeof() argument]

Reviewed-on: https://gerrit.openafs.org/12460

acinclude.m4 | 3 3 + 0 - 0 !
src/afs/LINUX/osi_file.c | 4 4 + 0 - 0 !
2 files changed, 7 insertions(+)

 linux 4.9: inode_change_ok() becomes setattr_prepare()

Linux commit 31051c85b5e2 "fs: Give dentry to inode_change_ok() instead
of inode" renames and modifies inode_change_ok(inode, attrs) to
setattr_prepare(dentry, attrs).

Modify OpenAFS to cope.

Reviewed-on: https://gerrit.openafs.org/12418
Tested-by: BuildBot <buildbot@rampaginggeek.com>

acinclude.m4 | 3 3 + 0 - 0 !
src/afs/LINUX/osi_compat.h | 4 4 + 0 - 0 !
2 files changed, 7 insertions(+)

 linux: debian/ubuntu build regression on kernel 3.16.39

Now that kernel 4.9 has hit jessie-backports, it becomes desirable to
also backport the associated openafs patches.

Unfortunately, Linux-4.9-inode_change_ok-becomes-setattr_prepare.patch
causes a build failure against jessie's current default kernel,
3.16.39-1, due to the fact that setattr_prepare() is available (it was
cherrypicked to address CVE-2015-1350) but file_dentry() is not (it was
introduced in kernel 4.6).