Andrew Deason 11cc0a3c4e afs: Cleanup state on rxfs_*Init errors
Currently, rxfs_storeInit and rxfs_fetchInit return early if they
encounter an error while starting the relevant fetch/store RPC (e.g.
StartRXAFS_FetchData64). In this scenario, they osi_FreeSmallSpace
their rock before returning, but they never go through their
destructor to free the contents of the rock
(rxfs_storeDestroy/rxfs_fetchDestroy), leaking any resources inside
that have already been initialized.

The only thing that could have been initialized by this point is
v->call, so hitting this condition means we leak an Rx call, and means
we can report the wrong error code (since we never go through
rx_EndCall, we never look at the call's abort code). For
rxfs_fetchInit, most code paths call rx_EndCall explicitly, except for
the code path where StartRXAFS_FetchData64 itself fails.

For both fetches and stores, it's difficult to hit this condition,
because this requires that the StartRXAFS_* call fails, before we have
sent or received any data from the wire. However, this can be hit if
the call is already aborted before we use it, which can happen if the
underlying connection has already been aborted by a connection abort.

Before commit 0835d7c2 ("afs: make sure to call afs_Analyze after
afs_Conn"), this was most easily hit by trying to fetch data with a
bad security object (for example, with expired credentials). After the
first fetch failed due to a connection abort (e.g. RXKADEXPIRED),
afs_GetDCache would retry the fetch with the same connection, and
StartRXAFS_FetchData64 would fail because the connection and call were
already aborted. In this case, we'd leak the Rx call, and we would
throw an RXGEN_CC_MARSHAL error (-450), instead of the correct
RXKADEXPIRED error. This causes libafs to report that the target
server as unreachable, due to the negative error code.

With commit 0835d7c2, this doesn't happen because we call afs_Analyze
before retrying the fetch, which detects the invalid credentials and
forces creating a new connetion object. However, this situation should
still be possible if a different call on the same connection triggered
a connection-level abort before we called StartRXAFS_FetchData64.

To fix this and ensure that we don't leak Rx calls, explicitly call
rxfs_storeDestroy/rxfs_fetchDestroy in this error case, before
returning from rxfs_storeInit/rxfs_fetchInit.

Thanks to yadayada@in.ibm.com for reporting a related issue and
providing analysis.

Change-Id: I15e02f8c9e620c5861e3dcb03c42510528ce9a60
Reviewed-on: https://gerrit.openafs.org/13510
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
2019-03-08 18:52:54 -05:00
2018-09-23 20:57:31 -04:00
2018-10-05 09:27:36 -04:00
2018-02-04 15:34:55 -05:00
2016-09-25 21:05:23 -04:00
2018-09-22 17:05:26 -04:00
2017-08-05 18:47:04 -04:00
2015-12-28 19:32:17 -05:00

AFS is a distributed file system that enables users to share and
access all of the files stored in a network of computers as easily as
they access the files stored on their local machines. The file system is
called distributed for this exact reason: files can reside on many
different machines, but are available to users on every machine.

OpenAFS 1.0 was originally released by IBM under the terms of the
IBM Public License 1.0 (IPL10).  For details on IPL10 see the LICENSE
file in this directory.  The current OpenAFS distribution is licensed
under a combination of the IPL10 and many other licenses as granted by
the relevant copyright holders.  The LICENSE file in this directory
contains more details, thought it is not a comprehensive statement.

See INSTALL for information about building and installing OpenAFS
on various platforms.

See CODING for developer information and guidelines.

See NEWS for recent changes to OpenAFS.

Description
No description provided
Readme Multiple Licenses 164 MiB
Languages
C 72.2%
C++ 20.1%
Makefile 1.4%
Perl 1.2%
Rich Text Format 1%
Other 3.7%