2022-05-04 10:41:02 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
/*
|
|
|
|
* Copyright (C) 2022 Oracle. All Rights Reserved.
|
|
|
|
* Author: Allison Henderson <allison.henderson@oracle.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "xfs.h"
|
|
|
|
#include "xfs_fs.h"
|
|
|
|
#include "xfs_format.h"
|
|
|
|
#include "xfs_trans_resv.h"
|
|
|
|
#include "xfs_shared.h"
|
|
|
|
#include "xfs_mount.h"
|
|
|
|
#include "xfs_defer.h"
|
|
|
|
#include "xfs_log_format.h"
|
|
|
|
#include "xfs_trans.h"
|
2022-05-09 17:09:07 +08:00
|
|
|
#include "xfs_bmap_btree.h"
|
2022-05-04 10:41:02 +08:00
|
|
|
#include "xfs_trans_priv.h"
|
|
|
|
#include "xfs_log.h"
|
|
|
|
#include "xfs_inode.h"
|
|
|
|
#include "xfs_da_format.h"
|
|
|
|
#include "xfs_da_btree.h"
|
|
|
|
#include "xfs_attr.h"
|
|
|
|
#include "xfs_attr_item.h"
|
|
|
|
#include "xfs_trace.h"
|
|
|
|
#include "xfs_trans_space.h"
|
2022-05-11 15:01:22 +08:00
|
|
|
#include "xfs_errortag.h"
|
2022-05-04 10:41:02 +08:00
|
|
|
#include "xfs_error.h"
|
|
|
|
#include "xfs_log_priv.h"
|
|
|
|
#include "xfs_log_recover.h"
|
|
|
|
|
2022-05-22 13:59:48 +08:00
|
|
|
struct kmem_cache *xfs_attri_cache;
|
|
|
|
struct kmem_cache *xfs_attrd_cache;
|
|
|
|
|
2022-05-04 10:41:02 +08:00
|
|
|
static const struct xfs_item_ops xfs_attri_item_ops;
|
|
|
|
static const struct xfs_item_ops xfs_attrd_item_ops;
|
2022-05-09 17:09:07 +08:00
|
|
|
static struct xfs_attrd_log_item *xfs_trans_get_attrd(struct xfs_trans *tp,
|
|
|
|
struct xfs_attri_log_item *attrip);
|
2022-05-04 10:41:02 +08:00
|
|
|
|
|
|
|
static inline struct xfs_attri_log_item *ATTRI_ITEM(struct xfs_log_item *lip)
|
|
|
|
{
|
|
|
|
return container_of(lip, struct xfs_attri_log_item, attri_item);
|
|
|
|
}
|
|
|
|
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
/*
|
|
|
|
* Shared xattr name/value buffers for logged extended attribute operations
|
|
|
|
*
|
|
|
|
* When logging updates to extended attributes, we can create quite a few
|
|
|
|
* attribute log intent items for a single xattr update. To avoid cycling the
|
|
|
|
* memory allocator and memcpy overhead, the name (and value, for setxattr)
|
|
|
|
* are kept in a refcounted object that is shared across all related log items
|
|
|
|
* and the upper-level deferred work state structure. The shared buffer has
|
|
|
|
* a control structure, followed by the name, and then the value.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static inline struct xfs_attri_log_nameval *
|
|
|
|
xfs_attri_log_nameval_get(
|
|
|
|
struct xfs_attri_log_nameval *nv)
|
|
|
|
{
|
|
|
|
if (!refcount_inc_not_zero(&nv->refcount))
|
|
|
|
return NULL;
|
|
|
|
return nv;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
xfs_attri_log_nameval_put(
|
|
|
|
struct xfs_attri_log_nameval *nv)
|
|
|
|
{
|
|
|
|
if (!nv)
|
|
|
|
return;
|
|
|
|
if (refcount_dec_and_test(&nv->refcount))
|
|
|
|
kvfree(nv);
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct xfs_attri_log_nameval *
|
|
|
|
xfs_attri_log_nameval_alloc(
|
|
|
|
const void *name,
|
|
|
|
unsigned int name_len,
|
|
|
|
const void *value,
|
|
|
|
unsigned int value_len)
|
|
|
|
{
|
|
|
|
struct xfs_attri_log_nameval *nv;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This could be over 64kB in length, so we have to use kvmalloc() for
|
|
|
|
* this. But kvmalloc() utterly sucks, so we use our own version.
|
|
|
|
*/
|
|
|
|
nv = xlog_kvmalloc(sizeof(struct xfs_attri_log_nameval) +
|
|
|
|
name_len + value_len);
|
|
|
|
|
|
|
|
nv->name.i_addr = nv + 1;
|
|
|
|
nv->name.i_len = name_len;
|
|
|
|
nv->name.i_type = XLOG_REG_TYPE_ATTR_NAME;
|
|
|
|
memcpy(nv->name.i_addr, name, name_len);
|
|
|
|
|
|
|
|
if (value_len) {
|
|
|
|
nv->value.i_addr = nv->name.i_addr + name_len;
|
|
|
|
nv->value.i_len = value_len;
|
|
|
|
memcpy(nv->value.i_addr, value, value_len);
|
|
|
|
} else {
|
|
|
|
nv->value.i_addr = NULL;
|
|
|
|
nv->value.i_len = 0;
|
|
|
|
}
|
|
|
|
nv->value.i_type = XLOG_REG_TYPE_ATTR_VALUE;
|
|
|
|
|
|
|
|
refcount_set(&nv->refcount, 1);
|
|
|
|
return nv;
|
|
|
|
}
|
|
|
|
|
2022-05-04 10:41:02 +08:00
|
|
|
STATIC void
|
|
|
|
xfs_attri_item_free(
|
|
|
|
struct xfs_attri_log_item *attrip)
|
|
|
|
{
|
|
|
|
kmem_free(attrip->attri_item.li_lv_shadow);
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
xfs_attri_log_nameval_put(attrip->attri_nameval);
|
|
|
|
kmem_cache_free(xfs_attri_cache, attrip);
|
2022-05-04 10:41:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Freeing the attrip requires that we remove it from the AIL if it has already
|
|
|
|
* been placed there. However, the ATTRI may not yet have been placed in the
|
|
|
|
* AIL when called by xfs_attri_release() from ATTRD processing due to the
|
|
|
|
* ordering of committed vs unpin operations in bulk insert operations. Hence
|
|
|
|
* the reference count to ensure only the last caller frees the ATTRI.
|
|
|
|
*/
|
|
|
|
STATIC void
|
|
|
|
xfs_attri_release(
|
|
|
|
struct xfs_attri_log_item *attrip)
|
|
|
|
{
|
|
|
|
ASSERT(atomic_read(&attrip->attri_refcount) > 0);
|
|
|
|
if (!atomic_dec_and_test(&attrip->attri_refcount))
|
|
|
|
return;
|
|
|
|
|
|
|
|
xfs_trans_ail_delete(&attrip->attri_item, 0);
|
|
|
|
xfs_attri_item_free(attrip);
|
|
|
|
}
|
|
|
|
|
|
|
|
STATIC void
|
|
|
|
xfs_attri_item_size(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
int *nvecs,
|
|
|
|
int *nbytes)
|
|
|
|
{
|
|
|
|
struct xfs_attri_log_item *attrip = ATTRI_ITEM(lip);
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
struct xfs_attri_log_nameval *nv = attrip->attri_nameval;
|
2022-05-04 10:41:02 +08:00
|
|
|
|
|
|
|
*nvecs += 2;
|
|
|
|
*nbytes += sizeof(struct xfs_attri_log_format) +
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
xlog_calc_iovec_len(nv->name.i_len);
|
2022-05-04 10:41:02 +08:00
|
|
|
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
if (!nv->value.i_len)
|
2022-05-04 10:41:02 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
*nvecs += 1;
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
*nbytes += xlog_calc_iovec_len(nv->value.i_len);
|
2022-05-04 10:41:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is called to fill in the log iovecs for the given attri log
|
|
|
|
* item. We use 1 iovec for the attri_format_item, 1 for the name, and
|
|
|
|
* another for the value if it is present
|
|
|
|
*/
|
|
|
|
STATIC void
|
|
|
|
xfs_attri_item_format(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
struct xfs_log_vec *lv)
|
|
|
|
{
|
|
|
|
struct xfs_attri_log_item *attrip = ATTRI_ITEM(lip);
|
|
|
|
struct xfs_log_iovec *vecp = NULL;
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
struct xfs_attri_log_nameval *nv = attrip->attri_nameval;
|
2022-05-04 10:41:02 +08:00
|
|
|
|
|
|
|
attrip->attri_format.alfi_type = XFS_LI_ATTRI;
|
|
|
|
attrip->attri_format.alfi_size = 1;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This size accounting must be done before copying the attrip into the
|
|
|
|
* iovec. If we do it after, the wrong size will be recorded to the log
|
|
|
|
* and we trip across assertion checks for bad region sizes later during
|
|
|
|
* the log recovery.
|
|
|
|
*/
|
|
|
|
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
ASSERT(nv->name.i_len > 0);
|
2022-05-04 10:41:02 +08:00
|
|
|
attrip->attri_format.alfi_size++;
|
|
|
|
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
if (nv->value.i_len > 0)
|
2022-05-04 10:41:02 +08:00
|
|
|
attrip->attri_format.alfi_size++;
|
|
|
|
|
|
|
|
xlog_copy_iovec(lv, &vecp, XLOG_REG_TYPE_ATTRI_FORMAT,
|
|
|
|
&attrip->attri_format,
|
|
|
|
sizeof(struct xfs_attri_log_format));
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
xlog_copy_from_iovec(lv, &vecp, &nv->name);
|
|
|
|
if (nv->value.i_len > 0)
|
|
|
|
xlog_copy_from_iovec(lv, &vecp, &nv->value);
|
2022-05-04 10:41:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The unpin operation is the last place an ATTRI is manipulated in the log. It
|
|
|
|
* is either inserted in the AIL or aborted in the event of a log I/O error. In
|
|
|
|
* either case, the ATTRI transaction has been successfully committed to make
|
|
|
|
* it this far. Therefore, we expect whoever committed the ATTRI to either
|
|
|
|
* construct and commit the ATTRD or drop the ATTRD's reference in the event of
|
|
|
|
* error. Simply drop the log's ATTRI reference now that the log is done with
|
|
|
|
* it.
|
|
|
|
*/
|
|
|
|
STATIC void
|
|
|
|
xfs_attri_item_unpin(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
int remove)
|
|
|
|
{
|
|
|
|
xfs_attri_release(ATTRI_ITEM(lip));
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
STATIC void
|
|
|
|
xfs_attri_item_release(
|
|
|
|
struct xfs_log_item *lip)
|
|
|
|
{
|
|
|
|
xfs_attri_release(ATTRI_ITEM(lip));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Allocate and initialize an attri item. Caller may allocate an additional
|
|
|
|
* trailing buffer for name and value
|
|
|
|
*/
|
|
|
|
STATIC struct xfs_attri_log_item *
|
|
|
|
xfs_attri_init(
|
|
|
|
struct xfs_mount *mp,
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
struct xfs_attri_log_nameval *nv)
|
2022-05-04 10:41:02 +08:00
|
|
|
{
|
|
|
|
struct xfs_attri_log_item *attrip;
|
|
|
|
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
attrip = kmem_cache_zalloc(xfs_attri_cache, GFP_NOFS | __GFP_NOFAIL);
|
2022-05-04 10:41:02 +08:00
|
|
|
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
/*
|
|
|
|
* Grab an extra reference to the name/value buffer for this log item.
|
|
|
|
* The caller retains its own reference!
|
|
|
|
*/
|
|
|
|
attrip->attri_nameval = xfs_attri_log_nameval_get(nv);
|
|
|
|
ASSERT(attrip->attri_nameval);
|
2022-05-04 10:41:02 +08:00
|
|
|
|
|
|
|
xfs_log_item_init(mp, &attrip->attri_item, XFS_LI_ATTRI,
|
|
|
|
&xfs_attri_item_ops);
|
|
|
|
attrip->attri_format.alfi_id = (uintptr_t)(void *)attrip;
|
|
|
|
atomic_set(&attrip->attri_refcount, 2);
|
|
|
|
|
|
|
|
return attrip;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline struct xfs_attrd_log_item *ATTRD_ITEM(struct xfs_log_item *lip)
|
|
|
|
{
|
|
|
|
return container_of(lip, struct xfs_attrd_log_item, attrd_item);
|
|
|
|
}
|
|
|
|
|
|
|
|
STATIC void
|
|
|
|
xfs_attrd_item_free(struct xfs_attrd_log_item *attrdp)
|
|
|
|
{
|
|
|
|
kmem_free(attrdp->attrd_item.li_lv_shadow);
|
2022-05-20 12:42:49 +08:00
|
|
|
kmem_cache_free(xfs_attrd_cache, attrdp);
|
2022-05-04 10:41:02 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
STATIC void
|
|
|
|
xfs_attrd_item_size(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
int *nvecs,
|
|
|
|
int *nbytes)
|
|
|
|
{
|
|
|
|
*nvecs += 1;
|
|
|
|
*nbytes += sizeof(struct xfs_attrd_log_format);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is called to fill in the log iovecs for the given attrd log item. We use
|
|
|
|
* only 1 iovec for the attrd_format, and we point that at the attr_log_format
|
|
|
|
* structure embedded in the attrd item.
|
|
|
|
*/
|
|
|
|
STATIC void
|
|
|
|
xfs_attrd_item_format(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
struct xfs_log_vec *lv)
|
|
|
|
{
|
|
|
|
struct xfs_attrd_log_item *attrdp = ATTRD_ITEM(lip);
|
|
|
|
struct xfs_log_iovec *vecp = NULL;
|
|
|
|
|
|
|
|
attrdp->attrd_format.alfd_type = XFS_LI_ATTRD;
|
|
|
|
attrdp->attrd_format.alfd_size = 1;
|
|
|
|
|
|
|
|
xlog_copy_iovec(lv, &vecp, XLOG_REG_TYPE_ATTRD_FORMAT,
|
|
|
|
&attrdp->attrd_format,
|
|
|
|
sizeof(struct xfs_attrd_log_format));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The ATTRD is either committed or aborted if the transaction is canceled. If
|
|
|
|
* the transaction is canceled, drop our reference to the ATTRI and free the
|
|
|
|
* ATTRD.
|
|
|
|
*/
|
|
|
|
STATIC void
|
|
|
|
xfs_attrd_item_release(
|
|
|
|
struct xfs_log_item *lip)
|
|
|
|
{
|
|
|
|
struct xfs_attrd_log_item *attrdp = ATTRD_ITEM(lip);
|
|
|
|
|
|
|
|
xfs_attri_release(attrdp->attrd_attrip);
|
|
|
|
xfs_attrd_item_free(attrdp);
|
|
|
|
}
|
|
|
|
|
2022-05-09 17:09:07 +08:00
|
|
|
static struct xfs_log_item *
|
|
|
|
xfs_attrd_item_intent(
|
|
|
|
struct xfs_log_item *lip)
|
|
|
|
{
|
|
|
|
return &ATTRD_ITEM(lip)->attrd_attrip->attri_item;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Performs one step of an attribute update intent and marks the attrd item
|
|
|
|
* dirty.. An attr operation may be a set or a remove. Note that the
|
|
|
|
* transaction is marked dirty regardless of whether the operation succeeds or
|
|
|
|
* fails to support the ATTRI/ATTRD lifecycle rules.
|
|
|
|
*/
|
|
|
|
STATIC int
|
|
|
|
xfs_xattri_finish_update(
|
2022-05-22 14:00:26 +08:00
|
|
|
struct xfs_attr_intent *attr,
|
2022-05-12 13:12:56 +08:00
|
|
|
struct xfs_attrd_log_item *attrdp)
|
2022-05-09 17:09:07 +08:00
|
|
|
{
|
2022-05-11 15:01:22 +08:00
|
|
|
struct xfs_da_args *args = attr->xattri_da_args;
|
2022-05-09 17:09:07 +08:00
|
|
|
int error;
|
|
|
|
|
2022-05-11 15:01:22 +08:00
|
|
|
if (XFS_TEST_ERROR(false, args->dp->i_mount, XFS_ERRTAG_LARP)) {
|
|
|
|
error = -EIO;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2022-05-12 13:12:56 +08:00
|
|
|
error = xfs_attr_set_iter(attr);
|
|
|
|
if (!error && attr->xattri_dela_state != XFS_DAS_DONE)
|
|
|
|
error = -EAGAIN;
|
2022-05-11 15:01:22 +08:00
|
|
|
out:
|
2022-05-09 17:09:07 +08:00
|
|
|
/*
|
|
|
|
* Mark the transaction dirty, even on error. This ensures the
|
|
|
|
* transaction is aborted, which:
|
|
|
|
*
|
|
|
|
* 1.) releases the ATTRI and frees the ATTRD
|
|
|
|
* 2.) shuts down the filesystem
|
|
|
|
*/
|
|
|
|
args->trans->t_flags |= XFS_TRANS_DIRTY | XFS_TRANS_HAS_INTENT_DONE;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* attr intent/done items are null when logged attributes are disabled
|
|
|
|
*/
|
|
|
|
if (attrdp)
|
|
|
|
set_bit(XFS_LI_DIRTY, &attrdp->attrd_item.li_flags);
|
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Log an attr to the intent item. */
|
|
|
|
STATIC void
|
|
|
|
xfs_attr_log_item(
|
|
|
|
struct xfs_trans *tp,
|
|
|
|
struct xfs_attri_log_item *attrip,
|
2022-05-22 14:00:26 +08:00
|
|
|
const struct xfs_attr_intent *attr)
|
2022-05-09 17:09:07 +08:00
|
|
|
{
|
|
|
|
struct xfs_attri_log_format *attrp;
|
|
|
|
|
|
|
|
tp->t_flags |= XFS_TRANS_DIRTY;
|
|
|
|
set_bit(XFS_LI_DIRTY, &attrip->attri_item.li_flags);
|
|
|
|
|
|
|
|
/*
|
2022-05-22 14:00:26 +08:00
|
|
|
* At this point the xfs_attr_intent has been constructed, and we've
|
2022-05-09 17:09:07 +08:00
|
|
|
* created the log intent. Fill in the attri log item and log format
|
2022-05-22 14:00:26 +08:00
|
|
|
* structure with fields from this xfs_attr_intent
|
2022-05-09 17:09:07 +08:00
|
|
|
*/
|
|
|
|
attrp = &attrip->attri_format;
|
2022-05-11 15:01:22 +08:00
|
|
|
attrp->alfi_ino = attr->xattri_da_args->dp->i_ino;
|
2022-05-22 13:59:48 +08:00
|
|
|
ASSERT(!(attr->xattri_op_flags & ~XFS_ATTRI_OP_FLAGS_TYPE_MASK));
|
2022-05-09 17:09:07 +08:00
|
|
|
attrp->alfi_op_flags = attr->xattri_op_flags;
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
attrp->alfi_value_len = attr->xattri_nameval->value.i_len;
|
|
|
|
attrp->alfi_name_len = attr->xattri_nameval->name.i_len;
|
2022-05-20 12:42:15 +08:00
|
|
|
ASSERT(!(attr->xattri_da_args->attr_filter & ~XFS_ATTRI_FILTER_MASK));
|
|
|
|
attrp->alfi_attr_filter = attr->xattri_da_args->attr_filter;
|
2022-05-09 17:09:07 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Get an ATTRI. */
|
|
|
|
static struct xfs_log_item *
|
|
|
|
xfs_attr_create_intent(
|
|
|
|
struct xfs_trans *tp,
|
|
|
|
struct list_head *items,
|
|
|
|
unsigned int count,
|
|
|
|
bool sort)
|
|
|
|
{
|
|
|
|
struct xfs_mount *mp = tp->t_mountp;
|
|
|
|
struct xfs_attri_log_item *attrip;
|
2022-05-22 14:00:26 +08:00
|
|
|
struct xfs_attr_intent *attr;
|
xfs: fix TOCTOU race involving the new logged xattrs control knob
I found a race involving the larp control knob, aka the debugging knob
that lets developers enable logging of extended attribute updates:
Thread 1 Thread 2
echo 0 > /sys/fs/xfs/debug/larp
setxattr(REPLACE)
xfs_has_larp (returns false)
xfs_attr_set
echo 1 > /sys/fs/xfs/debug/larp
xfs_attr_defer_replace
xfs_attr_init_replace_state
xfs_has_larp (returns true)
xfs_attr_init_remove_state
<oops, wrong DAS state!>
This isn't a particularly severe problem right now because xattr logging
is only enabled when CONFIG_XFS_DEBUG=y, and developers *should* know
what they're doing.
However, the eventual intent is that callers should be able to ask for
the assistance of the log in persisting xattr updates. This capability
might not be required for /all/ callers, which means that dynamic
control must work correctly. Once an xattr update has decided whether
or not to use logged xattrs, it needs to stay in that mode until the end
of the operation regardless of what subsequent parallel operations might
do.
Therefore, it is an error to continue sampling xfs_globals.larp once
xfs_attr_change has made a decision about larp, and it was not correct
for me to have told Allison that ->create_intent functions can sample
the global log incompat feature bitfield to decide to elide a log item.
Instead, create a new op flag for the xfs_da_args structure, and convert
all other callers of xfs_has_larp and xfs_sb_version_haslogxattrs within
the attr update state machine to look for the operations flag.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
2022-06-06 09:51:22 +08:00
|
|
|
struct xfs_da_args *args;
|
2022-05-09 17:09:07 +08:00
|
|
|
|
|
|
|
ASSERT(count == 1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Each attr item only performs one attribute operation at a time, so
|
|
|
|
* this is a list of one
|
|
|
|
*/
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
attr = list_first_entry_or_null(items, struct xfs_attr_intent,
|
|
|
|
xattri_list);
|
xfs: fix TOCTOU race involving the new logged xattrs control knob
I found a race involving the larp control knob, aka the debugging knob
that lets developers enable logging of extended attribute updates:
Thread 1 Thread 2
echo 0 > /sys/fs/xfs/debug/larp
setxattr(REPLACE)
xfs_has_larp (returns false)
xfs_attr_set
echo 1 > /sys/fs/xfs/debug/larp
xfs_attr_defer_replace
xfs_attr_init_replace_state
xfs_has_larp (returns true)
xfs_attr_init_remove_state
<oops, wrong DAS state!>
This isn't a particularly severe problem right now because xattr logging
is only enabled when CONFIG_XFS_DEBUG=y, and developers *should* know
what they're doing.
However, the eventual intent is that callers should be able to ask for
the assistance of the log in persisting xattr updates. This capability
might not be required for /all/ callers, which means that dynamic
control must work correctly. Once an xattr update has decided whether
or not to use logged xattrs, it needs to stay in that mode until the end
of the operation regardless of what subsequent parallel operations might
do.
Therefore, it is an error to continue sampling xfs_globals.larp once
xfs_attr_change has made a decision about larp, and it was not correct
for me to have told Allison that ->create_intent functions can sample
the global log incompat feature bitfield to decide to elide a log item.
Instead, create a new op flag for the xfs_da_args structure, and convert
all other callers of xfs_has_larp and xfs_sb_version_haslogxattrs within
the attr update state machine to look for the operations flag.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
2022-06-06 09:51:22 +08:00
|
|
|
args = attr->xattri_da_args;
|
|
|
|
|
|
|
|
if (!(args->op_flags & XFS_DA_OP_LOGGED))
|
|
|
|
return NULL;
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Create a buffer to store the attribute name and value. This buffer
|
|
|
|
* will be shared between the higher level deferred xattr work state
|
|
|
|
* and the lower level xattr log items.
|
|
|
|
*/
|
|
|
|
if (!attr->xattri_nameval) {
|
|
|
|
/*
|
|
|
|
* Transfer our reference to the name/value buffer to the
|
|
|
|
* deferred work state structure.
|
|
|
|
*/
|
|
|
|
attr->xattri_nameval = xfs_attri_log_nameval_alloc(args->name,
|
|
|
|
args->namelen, args->value, args->valuelen);
|
2022-05-09 17:09:07 +08:00
|
|
|
}
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
|
|
|
|
attrip = xfs_attri_init(mp, attr->xattri_nameval);
|
|
|
|
xfs_trans_add_item(tp, &attrip->attri_item);
|
|
|
|
xfs_attr_log_item(tp, attrip, attr);
|
2022-05-09 17:09:07 +08:00
|
|
|
|
|
|
|
return &attrip->attri_item;
|
|
|
|
}
|
|
|
|
|
2022-05-20 12:41:34 +08:00
|
|
|
static inline void
|
|
|
|
xfs_attr_free_item(
|
2022-05-22 14:00:26 +08:00
|
|
|
struct xfs_attr_intent *attr)
|
2022-05-20 12:41:34 +08:00
|
|
|
{
|
|
|
|
if (attr->xattri_da_state)
|
|
|
|
xfs_da_state_free(attr->xattri_da_state);
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
xfs_attri_log_nameval_put(attr->xattri_nameval);
|
2022-05-22 13:59:48 +08:00
|
|
|
if (attr->xattri_da_args->op_flags & XFS_DA_OP_RECOVERY)
|
|
|
|
kmem_free(attr);
|
|
|
|
else
|
|
|
|
kmem_cache_free(xfs_attr_intent_cache, attr);
|
2022-05-20 12:41:34 +08:00
|
|
|
}
|
|
|
|
|
2022-05-09 17:09:07 +08:00
|
|
|
/* Process an attr. */
|
|
|
|
STATIC int
|
|
|
|
xfs_attr_finish_item(
|
|
|
|
struct xfs_trans *tp,
|
|
|
|
struct xfs_log_item *done,
|
|
|
|
struct list_head *item,
|
|
|
|
struct xfs_btree_cur **state)
|
|
|
|
{
|
2022-05-22 14:00:26 +08:00
|
|
|
struct xfs_attr_intent *attr;
|
2022-05-09 17:09:07 +08:00
|
|
|
struct xfs_attrd_log_item *done_item = NULL;
|
|
|
|
int error;
|
|
|
|
|
2022-05-22 14:00:26 +08:00
|
|
|
attr = container_of(item, struct xfs_attr_intent, xattri_list);
|
2022-05-09 17:09:07 +08:00
|
|
|
if (done)
|
|
|
|
done_item = ATTRD_ITEM(done);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Always reset trans after EAGAIN cycle
|
|
|
|
* since the transaction is new
|
|
|
|
*/
|
2022-05-11 15:01:22 +08:00
|
|
|
attr->xattri_da_args->trans = tp;
|
2022-05-09 17:09:07 +08:00
|
|
|
|
2022-05-12 13:12:56 +08:00
|
|
|
error = xfs_xattri_finish_update(attr, done_item);
|
2022-05-09 17:09:07 +08:00
|
|
|
if (error != -EAGAIN)
|
2022-05-20 12:41:34 +08:00
|
|
|
xfs_attr_free_item(attr);
|
2022-05-09 17:09:07 +08:00
|
|
|
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Abort all pending ATTRs. */
|
|
|
|
STATIC void
|
|
|
|
xfs_attr_abort_intent(
|
|
|
|
struct xfs_log_item *intent)
|
|
|
|
{
|
|
|
|
xfs_attri_release(ATTRI_ITEM(intent));
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Cancel an attr */
|
|
|
|
STATIC void
|
|
|
|
xfs_attr_cancel_item(
|
|
|
|
struct list_head *item)
|
|
|
|
{
|
2022-05-22 14:00:26 +08:00
|
|
|
struct xfs_attr_intent *attr;
|
2022-05-09 17:09:07 +08:00
|
|
|
|
2022-05-22 14:00:26 +08:00
|
|
|
attr = container_of(item, struct xfs_attr_intent, xattri_list);
|
2022-05-20 12:41:34 +08:00
|
|
|
xfs_attr_free_item(attr);
|
2022-05-09 17:09:07 +08:00
|
|
|
}
|
|
|
|
|
2022-05-04 10:41:02 +08:00
|
|
|
STATIC bool
|
|
|
|
xfs_attri_item_match(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
uint64_t intent_id)
|
|
|
|
{
|
|
|
|
return ATTRI_ITEM(lip)->attri_format.alfi_id == intent_id;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Is this recovered ATTRI format ok? */
|
|
|
|
static inline bool
|
|
|
|
xfs_attri_validate(
|
|
|
|
struct xfs_mount *mp,
|
|
|
|
struct xfs_attri_log_format *attrp)
|
|
|
|
{
|
|
|
|
unsigned int op = attrp->alfi_op_flags &
|
2022-05-22 13:59:48 +08:00
|
|
|
XFS_ATTRI_OP_FLAGS_TYPE_MASK;
|
2022-05-04 10:41:02 +08:00
|
|
|
|
|
|
|
if (attrp->__pad != 0)
|
|
|
|
return false;
|
|
|
|
|
2022-05-22 13:59:48 +08:00
|
|
|
if (attrp->alfi_op_flags & ~XFS_ATTRI_OP_FLAGS_TYPE_MASK)
|
2022-05-20 12:41:47 +08:00
|
|
|
return false;
|
|
|
|
|
2022-05-20 12:42:15 +08:00
|
|
|
if (attrp->alfi_attr_filter & ~XFS_ATTRI_FILTER_MASK)
|
|
|
|
return false;
|
|
|
|
|
2022-05-04 10:41:02 +08:00
|
|
|
/* alfi_op_flags should be either a set or remove */
|
2022-05-11 15:05:23 +08:00
|
|
|
switch (op) {
|
2022-05-22 13:59:48 +08:00
|
|
|
case XFS_ATTRI_OP_FLAGS_SET:
|
|
|
|
case XFS_ATTRI_OP_FLAGS_REPLACE:
|
|
|
|
case XFS_ATTRI_OP_FLAGS_REMOVE:
|
2022-05-11 15:05:23 +08:00
|
|
|
break;
|
|
|
|
default:
|
2022-05-04 10:41:02 +08:00
|
|
|
return false;
|
2022-05-11 15:05:23 +08:00
|
|
|
}
|
2022-05-04 10:41:02 +08:00
|
|
|
|
|
|
|
if (attrp->alfi_value_len > XATTR_SIZE_MAX)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if ((attrp->alfi_name_len > XATTR_NAME_MAX) ||
|
|
|
|
(attrp->alfi_name_len == 0))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return xfs_verify_ino(mp, attrp->alfi_ino);
|
|
|
|
}
|
|
|
|
|
2022-05-09 17:09:07 +08:00
|
|
|
/*
|
|
|
|
* Process an attr intent item that was recovered from the log. We need to
|
|
|
|
* delete the attr that it describes.
|
|
|
|
*/
|
|
|
|
STATIC int
|
|
|
|
xfs_attri_item_recover(
|
|
|
|
struct xfs_log_item *lip,
|
|
|
|
struct list_head *capture_list)
|
|
|
|
{
|
|
|
|
struct xfs_attri_log_item *attrip = ATTRI_ITEM(lip);
|
2022-05-22 14:00:26 +08:00
|
|
|
struct xfs_attr_intent *attr;
|
2022-05-09 17:09:07 +08:00
|
|
|
struct xfs_mount *mp = lip->li_log->l_mp;
|
|
|
|
struct xfs_inode *ip;
|
|
|
|
struct xfs_da_args *args;
|
|
|
|
struct xfs_trans *tp;
|
|
|
|
struct xfs_trans_res tres;
|
|
|
|
struct xfs_attri_log_format *attrp;
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
struct xfs_attri_log_nameval *nv = attrip->attri_nameval;
|
2022-06-24 00:26:38 +08:00
|
|
|
int error;
|
2022-05-09 17:09:07 +08:00
|
|
|
int total;
|
|
|
|
int local;
|
|
|
|
struct xfs_attrd_log_item *done_item = NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* First check the validity of the attr described by the ATTRI. If any
|
|
|
|
* are bad, then assume that all are bad and just toss the ATTRI.
|
|
|
|
*/
|
|
|
|
attrp = &attrip->attri_format;
|
|
|
|
if (!xfs_attri_validate(mp, attrp) ||
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
!xfs_attr_namecheck(nv->name.i_addr, nv->name.i_len))
|
2022-05-09 17:09:07 +08:00
|
|
|
return -EFSCORRUPTED;
|
|
|
|
|
|
|
|
error = xlog_recover_iget(mp, attrp->alfi_ino, &ip);
|
|
|
|
if (error)
|
|
|
|
return error;
|
|
|
|
|
2022-05-22 14:00:26 +08:00
|
|
|
attr = kmem_zalloc(sizeof(struct xfs_attr_intent) +
|
2022-05-09 17:09:07 +08:00
|
|
|
sizeof(struct xfs_da_args), KM_NOFS);
|
|
|
|
args = (struct xfs_da_args *)(attr + 1);
|
|
|
|
|
2022-05-11 15:01:22 +08:00
|
|
|
attr->xattri_da_args = args;
|
2022-05-20 12:41:47 +08:00
|
|
|
attr->xattri_op_flags = attrp->alfi_op_flags &
|
2022-05-22 13:59:48 +08:00
|
|
|
XFS_ATTRI_OP_FLAGS_TYPE_MASK;
|
2022-05-09 17:09:07 +08:00
|
|
|
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
/*
|
|
|
|
* We're reconstructing the deferred work state structure from the
|
|
|
|
* recovered log item. Grab a reference to the name/value buffer and
|
|
|
|
* attach it to the new work state.
|
|
|
|
*/
|
|
|
|
attr->xattri_nameval = xfs_attri_log_nameval_get(nv);
|
|
|
|
ASSERT(attr->xattri_nameval);
|
|
|
|
|
2022-05-09 17:09:07 +08:00
|
|
|
args->dp = ip;
|
|
|
|
args->geo = mp->m_attr_geo;
|
|
|
|
args->whichfork = XFS_ATTR_FORK;
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
args->name = nv->name.i_addr;
|
|
|
|
args->namelen = nv->name.i_len;
|
2022-05-09 17:09:07 +08:00
|
|
|
args->hashval = xfs_da_hashname(args->name, args->namelen);
|
2022-05-20 12:42:15 +08:00
|
|
|
args->attr_filter = attrp->alfi_attr_filter & XFS_ATTRI_FILTER_MASK;
|
xfs: fix TOCTOU race involving the new logged xattrs control knob
I found a race involving the larp control knob, aka the debugging knob
that lets developers enable logging of extended attribute updates:
Thread 1 Thread 2
echo 0 > /sys/fs/xfs/debug/larp
setxattr(REPLACE)
xfs_has_larp (returns false)
xfs_attr_set
echo 1 > /sys/fs/xfs/debug/larp
xfs_attr_defer_replace
xfs_attr_init_replace_state
xfs_has_larp (returns true)
xfs_attr_init_remove_state
<oops, wrong DAS state!>
This isn't a particularly severe problem right now because xattr logging
is only enabled when CONFIG_XFS_DEBUG=y, and developers *should* know
what they're doing.
However, the eventual intent is that callers should be able to ask for
the assistance of the log in persisting xattr updates. This capability
might not be required for /all/ callers, which means that dynamic
control must work correctly. Once an xattr update has decided whether
or not to use logged xattrs, it needs to stay in that mode until the end
of the operation regardless of what subsequent parallel operations might
do.
Therefore, it is an error to continue sampling xfs_globals.larp once
xfs_attr_change has made a decision about larp, and it was not correct
for me to have told Allison that ->create_intent functions can sample
the global log incompat feature bitfield to decide to elide a log item.
Instead, create a new op flag for the xfs_da_args structure, and convert
all other callers of xfs_has_larp and xfs_sb_version_haslogxattrs within
the attr update state machine to look for the operations flag.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
2022-06-06 09:51:22 +08:00
|
|
|
args->op_flags = XFS_DA_OP_RECOVERY | XFS_DA_OP_OKNOENT |
|
|
|
|
XFS_DA_OP_LOGGED;
|
|
|
|
|
|
|
|
ASSERT(xfs_sb_version_haslogxattrs(&mp->m_sb));
|
2022-05-09 17:09:07 +08:00
|
|
|
|
2022-05-20 12:41:47 +08:00
|
|
|
switch (attr->xattri_op_flags) {
|
2022-05-22 13:59:48 +08:00
|
|
|
case XFS_ATTRI_OP_FLAGS_SET:
|
|
|
|
case XFS_ATTRI_OP_FLAGS_REPLACE:
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
args->value = nv->value.i_addr;
|
|
|
|
args->valuelen = nv->value.i_len;
|
2022-05-09 17:09:07 +08:00
|
|
|
args->total = xfs_attr_calc_size(args, &local);
|
xfs: ATTR_REPLACE algorithm with LARP enabled needs rework
We can't use the same algorithm for replacing an existing attribute
when logging attributes. The existing algorithm is essentially:
1. create new attr w/ INCOMPLETE
2. atomically flip INCOMPLETE flags between old + new attribute
3. remove old attr which is marked w/ INCOMPLETE
This algorithm guarantees that we see either the old or new
attribute, and if we fail after the atomic flag flip, we don't have
to recover the removal of the old attr because we never see
INCOMPLETE attributes in lookups.
For logged attributes, however, this does not work. The logged
attribute intents do not track the work that has been done as the
transaction rolls, and hence the only recovery mechanism we have is
"run the replace operation from scratch".
This is further exacerbated by the attempt to avoid needing the
INCOMPLETE flag to create an atomic swap. This means we can create
a second active attribute of the same name before we remove the
original. If we fail at any point after the create but before the
removal has completed, we end up with duplicate attributes in
the attr btree and recovery only tries to replace one of them.
There are several other failure modes where we can leave partially
allocated remote attributes that expose stale data, partially free
remote attributes that enable UAF based stale data exposure, etc.
TO fix this, we need a different algorithm for replace operations
when LARP is enabled. Luckily, it's not that complex if we take the
right first step. That is, the first thing we log is the attri
intent with the new name/value pair and mark the old attr as
INCOMPLETE in the same transaction.
From there, we then remove the old attr and keep relogging the
new name/value in the intent, such that we always know that we have
to create the new attr in recovery. Once the old attr is removed,
we then run a normal ATTR_CREATE operation relogging the intent as
we go. If the new attr is local, then it gets created in a single
atomic transaction that also logs the final intent done. If the new
attr is remote, the we set INCOMPLETE on the new attr while we
allocate and set the remote value, and then we clear the INCOMPLETE
flag at in the last transaction taht logs the final intent done.
If we fail at any point in this algorithm, log recovery will always
see the same state on disk: the new name/value in the intent, and
either an INCOMPLETE attr or no attr in the attr btree. If we find
an INCOMPLETE attr, we run the full replace starting with removing
the INCOMPLETE attr. If we don't find it, then we simply create the
new attr.
Notably, recovery of a failed create that has an INCOMPLETE flag set
is now the same - we start with the lookup of the INCOMPLETE attr,
and if that exists then we do the full replace recovery process,
otherwise we just create the new attr.
Hence changing the way we do the replace operation when LARP is
enabled allows us to use the same log recovery algorithm for both
the ATTR_CREATE and ATTR_REPLACE operations. This is also the same
algorithm we use for runtime ATTR_REPLACE operations (except for the
step setting up the initial conditions).
The result is that:
- ATTR_CREATE uses the same algorithm regardless of whether LARP is
enabled or not
- ATTR_REPLACE with larp=0 is identical to the old algorithm
- ATTR_REPLACE with larp=1 runs an unmodified attr removal algorithm
from the larp=0 code and then runs the unmodified ATTR_CREATE
code.
- log recovery when larp=1 runs the same ATTR_REPLACE algorithm as
it uses at runtime.
Because the state machine is now quite clean, changing the algorithm
is really just a case of changing the initial state and how the
states link together for the ATTR_REPLACE case. Hence it's not a
huge amount of code for what is a fairly substantial rework
of the attr logging and recovery algorithm....
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-12 13:12:56 +08:00
|
|
|
if (xfs_inode_hasattr(args->dp))
|
|
|
|
attr->xattri_dela_state = xfs_attr_init_replace_state(args);
|
|
|
|
else
|
|
|
|
attr->xattri_dela_state = xfs_attr_init_add_state(args);
|
xfs: separate out initial attr_set states
We current use XFS_DAS_UNINIT for several steps in the attr_set
state machine. We use it for setting shortform xattrs, converting
from shortform to leaf, leaf add, leaf-to-node and leaf add. All of
these things are essentially known before we start the state machine
iterating, so we really should separate them out:
XFS_DAS_SF_ADD:
- tries to do a shortform add
- on success -> done
- on ENOSPC converts to leaf, -> XFS_DAS_LEAF_ADD
- on error, dies.
XFS_DAS_LEAF_ADD:
- tries to do leaf add
- on success:
- inline attr -> done
- remote xattr || REPLACE -> XFS_DAS_FOUND_LBLK
- on ENOSPC converts to node, -> XFS_DAS_NODE_ADD
- on error, dies
XFS_DAS_NODE_ADD:
- tries to do node add
- on success:
- inline attr -> done
- remote xattr || REPLACE -> XFS_DAS_FOUND_NBLK
- on error, dies
This makes it easier to understand how the state machine starts
up and sets us up on the path to further state machine
simplifications.
This also converts the DAS state tracepoints to use strings rather
than numbers, as converting between enums and numbers requires
manual counting rather than just reading the name.
This also introduces a XFS_DAS_DONE state so that we can trace
successful operation completions easily.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Allison Henderson<allison.henderson@oracle.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-12 13:12:52 +08:00
|
|
|
break;
|
2022-05-22 13:59:48 +08:00
|
|
|
case XFS_ATTRI_OP_FLAGS_REMOVE:
|
xfs: ATTR_REPLACE algorithm with LARP enabled needs rework
We can't use the same algorithm for replacing an existing attribute
when logging attributes. The existing algorithm is essentially:
1. create new attr w/ INCOMPLETE
2. atomically flip INCOMPLETE flags between old + new attribute
3. remove old attr which is marked w/ INCOMPLETE
This algorithm guarantees that we see either the old or new
attribute, and if we fail after the atomic flag flip, we don't have
to recover the removal of the old attr because we never see
INCOMPLETE attributes in lookups.
For logged attributes, however, this does not work. The logged
attribute intents do not track the work that has been done as the
transaction rolls, and hence the only recovery mechanism we have is
"run the replace operation from scratch".
This is further exacerbated by the attempt to avoid needing the
INCOMPLETE flag to create an atomic swap. This means we can create
a second active attribute of the same name before we remove the
original. If we fail at any point after the create but before the
removal has completed, we end up with duplicate attributes in
the attr btree and recovery only tries to replace one of them.
There are several other failure modes where we can leave partially
allocated remote attributes that expose stale data, partially free
remote attributes that enable UAF based stale data exposure, etc.
TO fix this, we need a different algorithm for replace operations
when LARP is enabled. Luckily, it's not that complex if we take the
right first step. That is, the first thing we log is the attri
intent with the new name/value pair and mark the old attr as
INCOMPLETE in the same transaction.
From there, we then remove the old attr and keep relogging the
new name/value in the intent, such that we always know that we have
to create the new attr in recovery. Once the old attr is removed,
we then run a normal ATTR_CREATE operation relogging the intent as
we go. If the new attr is local, then it gets created in a single
atomic transaction that also logs the final intent done. If the new
attr is remote, the we set INCOMPLETE on the new attr while we
allocate and set the remote value, and then we clear the INCOMPLETE
flag at in the last transaction taht logs the final intent done.
If we fail at any point in this algorithm, log recovery will always
see the same state on disk: the new name/value in the intent, and
either an INCOMPLETE attr or no attr in the attr btree. If we find
an INCOMPLETE attr, we run the full replace starting with removing
the INCOMPLETE attr. If we don't find it, then we simply create the
new attr.
Notably, recovery of a failed create that has an INCOMPLETE flag set
is now the same - we start with the lookup of the INCOMPLETE attr,
and if that exists then we do the full replace recovery process,
otherwise we just create the new attr.
Hence changing the way we do the replace operation when LARP is
enabled allows us to use the same log recovery algorithm for both
the ATTR_CREATE and ATTR_REPLACE operations. This is also the same
algorithm we use for runtime ATTR_REPLACE operations (except for the
step setting up the initial conditions).
The result is that:
- ATTR_CREATE uses the same algorithm regardless of whether LARP is
enabled or not
- ATTR_REPLACE with larp=0 is identical to the old algorithm
- ATTR_REPLACE with larp=1 runs an unmodified attr removal algorithm
from the larp=0 code and then runs the unmodified ATTR_CREATE
code.
- log recovery when larp=1 runs the same ATTR_REPLACE algorithm as
it uses at runtime.
Because the state machine is now quite clean, changing the algorithm
is really just a case of changing the initial state and how the
states link together for the ATTR_REPLACE case. Hence it's not a
huge amount of code for what is a fairly substantial rework
of the attr logging and recovery algorithm....
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-12 13:12:56 +08:00
|
|
|
if (!xfs_inode_hasattr(args->dp))
|
|
|
|
goto out;
|
2022-05-12 13:12:56 +08:00
|
|
|
attr->xattri_dela_state = xfs_attr_init_remove_state(args);
|
xfs: separate out initial attr_set states
We current use XFS_DAS_UNINIT for several steps in the attr_set
state machine. We use it for setting shortform xattrs, converting
from shortform to leaf, leaf add, leaf-to-node and leaf add. All of
these things are essentially known before we start the state machine
iterating, so we really should separate them out:
XFS_DAS_SF_ADD:
- tries to do a shortform add
- on success -> done
- on ENOSPC converts to leaf, -> XFS_DAS_LEAF_ADD
- on error, dies.
XFS_DAS_LEAF_ADD:
- tries to do leaf add
- on success:
- inline attr -> done
- remote xattr || REPLACE -> XFS_DAS_FOUND_LBLK
- on ENOSPC converts to node, -> XFS_DAS_NODE_ADD
- on error, dies
XFS_DAS_NODE_ADD:
- tries to do node add
- on success:
- inline attr -> done
- remote xattr || REPLACE -> XFS_DAS_FOUND_NBLK
- on error, dies
This makes it easier to understand how the state machine starts
up and sets us up on the path to further state machine
simplifications.
This also converts the DAS state tracepoints to use strings rather
than numbers, as converting between enums and numbers requires
manual counting rather than just reading the name.
This also introduces a XFS_DAS_DONE state so that we can trace
successful operation completions easily.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Allison Henderson<allison.henderson@oracle.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-12 13:12:52 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
ASSERT(0);
|
|
|
|
error = -EFSCORRUPTED;
|
|
|
|
goto out;
|
2022-05-09 17:09:07 +08:00
|
|
|
}
|
2022-05-11 15:01:23 +08:00
|
|
|
|
|
|
|
xfs_init_attr_trans(args, &tres, &total);
|
2022-05-09 17:09:07 +08:00
|
|
|
error = xfs_trans_alloc(mp, &tres, total, 0, XFS_TRANS_RESERVE, &tp);
|
|
|
|
if (error)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
args->trans = tp;
|
|
|
|
done_item = xfs_trans_get_attrd(tp, attrip);
|
|
|
|
|
|
|
|
xfs_ilock(ip, XFS_ILOCK_EXCL);
|
|
|
|
xfs_trans_ijoin(tp, ip, 0);
|
|
|
|
|
2022-06-24 00:26:38 +08:00
|
|
|
error = xfs_xattri_finish_update(attr, done_item);
|
|
|
|
if (error == -EAGAIN) {
|
|
|
|
/*
|
|
|
|
* There's more work to do, so add the intent item to this
|
|
|
|
* transaction so that we can continue it later.
|
|
|
|
*/
|
2022-05-09 17:09:07 +08:00
|
|
|
xfs_defer_add(tp, XFS_DEFER_OPS_TYPE_ATTR, &attr->xattri_list);
|
2022-06-24 00:26:38 +08:00
|
|
|
error = xfs_defer_ops_capture_and_commit(tp, capture_list);
|
|
|
|
if (error)
|
|
|
|
goto out_unlock;
|
|
|
|
|
|
|
|
xfs_iunlock(ip, XFS_ILOCK_EXCL);
|
|
|
|
xfs_irele(ip);
|
|
|
|
return 0;
|
|
|
|
}
|
2022-05-09 17:09:07 +08:00
|
|
|
if (error) {
|
|
|
|
xfs_trans_cancel(tp);
|
|
|
|
goto out_unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
error = xfs_defer_ops_capture_and_commit(tp, capture_list);
|
|
|
|
out_unlock:
|
|
|
|
xfs_iunlock(ip, XFS_ILOCK_EXCL);
|
|
|
|
xfs_irele(ip);
|
|
|
|
out:
|
2022-06-24 00:26:38 +08:00
|
|
|
xfs_attr_free_item(attr);
|
2022-05-09 17:09:07 +08:00
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Re-log an intent item to push the log tail forward. */
|
|
|
|
static struct xfs_log_item *
|
|
|
|
xfs_attri_item_relog(
|
|
|
|
struct xfs_log_item *intent,
|
|
|
|
struct xfs_trans *tp)
|
|
|
|
{
|
|
|
|
struct xfs_attrd_log_item *attrdp;
|
|
|
|
struct xfs_attri_log_item *old_attrip;
|
|
|
|
struct xfs_attri_log_item *new_attrip;
|
|
|
|
struct xfs_attri_log_format *new_attrp;
|
|
|
|
struct xfs_attri_log_format *old_attrp;
|
|
|
|
|
|
|
|
old_attrip = ATTRI_ITEM(intent);
|
|
|
|
old_attrp = &old_attrip->attri_format;
|
|
|
|
|
|
|
|
tp->t_flags |= XFS_TRANS_DIRTY;
|
|
|
|
attrdp = xfs_trans_get_attrd(tp, old_attrip);
|
|
|
|
set_bit(XFS_LI_DIRTY, &attrdp->attrd_item.li_flags);
|
|
|
|
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
/*
|
|
|
|
* Create a new log item that shares the same name/value buffer as the
|
|
|
|
* old log item.
|
|
|
|
*/
|
|
|
|
new_attrip = xfs_attri_init(tp->t_mountp, old_attrip->attri_nameval);
|
2022-05-09 17:09:07 +08:00
|
|
|
new_attrp = &new_attrip->attri_format;
|
|
|
|
|
|
|
|
new_attrp->alfi_ino = old_attrp->alfi_ino;
|
|
|
|
new_attrp->alfi_op_flags = old_attrp->alfi_op_flags;
|
|
|
|
new_attrp->alfi_value_len = old_attrp->alfi_value_len;
|
|
|
|
new_attrp->alfi_name_len = old_attrp->alfi_name_len;
|
2022-05-20 12:42:15 +08:00
|
|
|
new_attrp->alfi_attr_filter = old_attrp->alfi_attr_filter;
|
2022-05-09 17:09:07 +08:00
|
|
|
|
|
|
|
xfs_trans_add_item(tp, &new_attrip->attri_item);
|
|
|
|
set_bit(XFS_LI_DIRTY, &new_attrip->attri_item.li_flags);
|
|
|
|
|
|
|
|
return &new_attrip->attri_item;
|
|
|
|
}
|
|
|
|
|
2022-05-04 10:41:02 +08:00
|
|
|
STATIC int
|
|
|
|
xlog_recover_attri_commit_pass2(
|
|
|
|
struct xlog *log,
|
|
|
|
struct list_head *buffer_list,
|
|
|
|
struct xlog_recover_item *item,
|
|
|
|
xfs_lsn_t lsn)
|
|
|
|
{
|
|
|
|
struct xfs_mount *mp = log->l_mp;
|
|
|
|
struct xfs_attri_log_item *attrip;
|
|
|
|
struct xfs_attri_log_format *attri_formatp;
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
struct xfs_attri_log_nameval *nv;
|
|
|
|
const void *attr_value = NULL;
|
2022-05-20 12:42:36 +08:00
|
|
|
const void *attr_name;
|
2022-10-21 07:08:11 +08:00
|
|
|
size_t len;
|
2022-05-04 10:41:02 +08:00
|
|
|
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
attri_formatp = item->ri_buf[0].i_addr;
|
2022-05-20 12:42:36 +08:00
|
|
|
attr_name = item->ri_buf[1].i_addr;
|
2022-05-04 10:41:02 +08:00
|
|
|
|
2022-05-20 12:42:36 +08:00
|
|
|
/* Validate xfs_attri_log_format before the large memory allocation */
|
2022-10-21 07:08:11 +08:00
|
|
|
len = sizeof(struct xfs_attri_log_format);
|
|
|
|
if (item->ri_buf[0].i_len != len) {
|
2022-10-26 06:07:14 +08:00
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
item->ri_buf[0].i_addr, item->ri_buf[0].i_len);
|
2022-10-21 07:08:11 +08:00
|
|
|
return -EFSCORRUPTED;
|
|
|
|
}
|
|
|
|
|
2022-05-04 10:41:02 +08:00
|
|
|
if (!xfs_attri_validate(mp, attri_formatp)) {
|
2022-10-26 06:07:14 +08:00
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
item->ri_buf[0].i_addr, item->ri_buf[0].i_len);
|
2022-05-04 10:41:02 +08:00
|
|
|
return -EFSCORRUPTED;
|
|
|
|
}
|
|
|
|
|
2022-10-21 07:08:11 +08:00
|
|
|
/* Validate the attr name */
|
|
|
|
if (item->ri_buf[1].i_len !=
|
|
|
|
xlog_calc_iovec_len(attri_formatp->alfi_name_len)) {
|
2022-10-26 06:07:14 +08:00
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
item->ri_buf[0].i_addr, item->ri_buf[0].i_len);
|
2022-10-21 07:08:11 +08:00
|
|
|
return -EFSCORRUPTED;
|
|
|
|
}
|
|
|
|
|
2022-05-20 12:42:36 +08:00
|
|
|
if (!xfs_attr_namecheck(attr_name, attri_formatp->alfi_name_len)) {
|
2022-10-26 06:07:14 +08:00
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
item->ri_buf[1].i_addr, item->ri_buf[1].i_len);
|
2022-05-20 12:42:36 +08:00
|
|
|
return -EFSCORRUPTED;
|
|
|
|
}
|
|
|
|
|
2022-10-21 07:08:11 +08:00
|
|
|
/* Validate the attr value, if present */
|
|
|
|
if (attri_formatp->alfi_value_len != 0) {
|
|
|
|
if (item->ri_buf[2].i_len != xlog_calc_iovec_len(attri_formatp->alfi_value_len)) {
|
2022-10-26 06:07:14 +08:00
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
item->ri_buf[0].i_addr,
|
|
|
|
item->ri_buf[0].i_len);
|
2022-10-21 07:08:11 +08:00
|
|
|
return -EFSCORRUPTED;
|
|
|
|
}
|
|
|
|
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
attr_value = item->ri_buf[2].i_addr;
|
2022-10-21 07:08:11 +08:00
|
|
|
}
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Memory alloc failure will cause replay to abort. We attach the
|
|
|
|
* name/value buffer to the recovered incore log item and drop our
|
|
|
|
* reference.
|
|
|
|
*/
|
|
|
|
nv = xfs_attri_log_nameval_alloc(attr_name,
|
|
|
|
attri_formatp->alfi_name_len, attr_value,
|
|
|
|
attri_formatp->alfi_value_len);
|
2022-05-04 10:41:02 +08:00
|
|
|
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
attrip = xfs_attri_init(mp, nv);
|
2022-10-21 07:08:11 +08:00
|
|
|
memcpy(&attrip->attri_format, attri_formatp, len);
|
2022-05-04 10:41:02 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The ATTRI has two references. One for the ATTRD and one for ATTRI to
|
|
|
|
* ensure it makes it into the AIL. Insert the ATTRI into the AIL
|
|
|
|
* directly and drop the ATTRI reference. Note that
|
|
|
|
* xfs_trans_ail_update() drops the AIL lock.
|
|
|
|
*/
|
|
|
|
xfs_trans_ail_insert(log->l_ailp, &attrip->attri_item, lsn);
|
|
|
|
xfs_attri_release(attrip);
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 06:43:46 +08:00
|
|
|
xfs_attri_log_nameval_put(nv);
|
2022-05-04 10:41:02 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2022-05-09 17:09:07 +08:00
|
|
|
/*
|
|
|
|
* This routine is called to allocate an "attr free done" log item.
|
|
|
|
*/
|
|
|
|
static struct xfs_attrd_log_item *
|
|
|
|
xfs_trans_get_attrd(struct xfs_trans *tp,
|
|
|
|
struct xfs_attri_log_item *attrip)
|
|
|
|
{
|
|
|
|
struct xfs_attrd_log_item *attrdp;
|
|
|
|
|
|
|
|
ASSERT(tp != NULL);
|
|
|
|
|
2022-05-11 15:03:23 +08:00
|
|
|
attrdp = kmem_cache_zalloc(xfs_attrd_cache, GFP_NOFS | __GFP_NOFAIL);
|
2022-05-09 17:09:07 +08:00
|
|
|
|
|
|
|
xfs_log_item_init(tp->t_mountp, &attrdp->attrd_item, XFS_LI_ATTRD,
|
|
|
|
&xfs_attrd_item_ops);
|
|
|
|
attrdp->attrd_attrip = attrip;
|
|
|
|
attrdp->attrd_format.alfd_alf_id = attrip->attri_format.alfi_id;
|
|
|
|
|
|
|
|
xfs_trans_add_item(tp, &attrdp->attrd_item);
|
|
|
|
return attrdp;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Get an ATTRD so we can process all the attrs. */
|
|
|
|
static struct xfs_log_item *
|
|
|
|
xfs_attr_create_done(
|
|
|
|
struct xfs_trans *tp,
|
|
|
|
struct xfs_log_item *intent,
|
|
|
|
unsigned int count)
|
|
|
|
{
|
|
|
|
if (!intent)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return &xfs_trans_get_attrd(tp, ATTRI_ITEM(intent))->attrd_item;
|
|
|
|
}
|
|
|
|
|
|
|
|
const struct xfs_defer_op_type xfs_attr_defer_type = {
|
|
|
|
.max_items = 1,
|
|
|
|
.create_intent = xfs_attr_create_intent,
|
|
|
|
.abort_intent = xfs_attr_abort_intent,
|
|
|
|
.create_done = xfs_attr_create_done,
|
|
|
|
.finish_item = xfs_attr_finish_item,
|
|
|
|
.cancel_item = xfs_attr_cancel_item,
|
|
|
|
};
|
|
|
|
|
2022-05-04 10:41:02 +08:00
|
|
|
/*
|
|
|
|
* This routine is called when an ATTRD format structure is found in a committed
|
|
|
|
* transaction in the log. Its purpose is to cancel the corresponding ATTRI if
|
|
|
|
* it was still in the log. To do this it searches the AIL for the ATTRI with
|
|
|
|
* an id equal to that in the ATTRD format structure. If we find it we drop
|
|
|
|
* the ATTRD reference, which removes the ATTRI from the AIL and frees it.
|
|
|
|
*/
|
|
|
|
STATIC int
|
|
|
|
xlog_recover_attrd_commit_pass2(
|
|
|
|
struct xlog *log,
|
|
|
|
struct list_head *buffer_list,
|
|
|
|
struct xlog_recover_item *item,
|
|
|
|
xfs_lsn_t lsn)
|
|
|
|
{
|
|
|
|
struct xfs_attrd_log_format *attrd_formatp;
|
|
|
|
|
|
|
|
attrd_formatp = item->ri_buf[0].i_addr;
|
|
|
|
if (item->ri_buf[0].i_len != sizeof(struct xfs_attrd_log_format)) {
|
2022-10-26 06:07:14 +08:00
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, log->l_mp,
|
|
|
|
item->ri_buf[0].i_addr, item->ri_buf[0].i_len);
|
2022-05-04 10:41:02 +08:00
|
|
|
return -EFSCORRUPTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
xlog_recover_release_intent(log, XFS_LI_ATTRI,
|
|
|
|
attrd_formatp->alfd_alf_id);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct xfs_item_ops xfs_attri_item_ops = {
|
|
|
|
.flags = XFS_ITEM_INTENT,
|
|
|
|
.iop_size = xfs_attri_item_size,
|
|
|
|
.iop_format = xfs_attri_item_format,
|
|
|
|
.iop_unpin = xfs_attri_item_unpin,
|
|
|
|
.iop_release = xfs_attri_item_release,
|
2022-05-09 17:09:07 +08:00
|
|
|
.iop_recover = xfs_attri_item_recover,
|
2022-05-04 10:41:02 +08:00
|
|
|
.iop_match = xfs_attri_item_match,
|
2022-05-09 17:09:07 +08:00
|
|
|
.iop_relog = xfs_attri_item_relog,
|
2022-05-04 10:41:02 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
const struct xlog_recover_item_ops xlog_attri_item_ops = {
|
|
|
|
.item_type = XFS_LI_ATTRI,
|
|
|
|
.commit_pass2 = xlog_recover_attri_commit_pass2,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct xfs_item_ops xfs_attrd_item_ops = {
|
|
|
|
.flags = XFS_ITEM_RELEASE_WHEN_COMMITTED |
|
|
|
|
XFS_ITEM_INTENT_DONE,
|
|
|
|
.iop_size = xfs_attrd_item_size,
|
|
|
|
.iop_format = xfs_attrd_item_format,
|
|
|
|
.iop_release = xfs_attrd_item_release,
|
2022-05-09 17:09:07 +08:00
|
|
|
.iop_intent = xfs_attrd_item_intent,
|
2022-05-04 10:41:02 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
const struct xlog_recover_item_ops xlog_attrd_item_ops = {
|
|
|
|
.item_type = XFS_LI_ATTRD,
|
|
|
|
.commit_pass2 = xlog_recover_attrd_commit_pass2,
|
|
|
|
};
|