2022-05-04 02:41:02 +00: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 09:09:07 +00:00
|
|
|
#include "xfs_bmap_btree.h"
|
2022-05-04 02:41:02 +00: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 07:01:22 +00:00
|
|
|
#include "xfs_errortag.h"
|
2022-05-04 02:41:02 +00:00
|
|
|
#include "xfs_error.h"
|
|
|
|
#include "xfs_log_priv.h"
|
|
|
|
#include "xfs_log_recover.h"
|
|
|
|
|
2022-05-22 05:59:48 +00:00
|
|
|
struct kmem_cache *xfs_attri_cache;
|
|
|
|
struct kmem_cache *xfs_attrd_cache;
|
|
|
|
|
2022-05-04 02:41:02 +00:00
|
|
|
static const struct xfs_item_ops xfs_attri_item_ops;
|
|
|
|
static const struct xfs_item_ops xfs_attrd_item_ops;
|
|
|
|
|
|
|
|
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-22 22:43:46 +00: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 02:41:02 +00:00
|
|
|
STATIC void
|
|
|
|
xfs_attri_item_free(
|
|
|
|
struct xfs_attri_log_item *attrip)
|
|
|
|
{
|
2024-01-15 22:59:42 +00:00
|
|
|
kvfree(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-22 22:43:46 +00:00
|
|
|
xfs_attri_log_nameval_put(attrip->attri_nameval);
|
|
|
|
kmem_cache_free(xfs_attri_cache, attrip);
|
2022-05-04 02:41:02 +00: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-22 22:43:46 +00:00
|
|
|
struct xfs_attri_log_nameval *nv = attrip->attri_nameval;
|
2022-05-04 02:41:02 +00: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-22 22:43:46 +00:00
|
|
|
xlog_calc_iovec_len(nv->name.i_len);
|
2022-05-04 02:41:02 +00: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-22 22:43:46 +00:00
|
|
|
if (!nv->value.i_len)
|
2022-05-04 02:41:02 +00: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-22 22:43:46 +00:00
|
|
|
*nbytes += xlog_calc_iovec_len(nv->value.i_len);
|
2022-05-04 02:41:02 +00: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-22 22:43:46 +00:00
|
|
|
struct xfs_attri_log_nameval *nv = attrip->attri_nameval;
|
2022-05-04 02:41:02 +00: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-22 22:43:46 +00:00
|
|
|
ASSERT(nv->name.i_len > 0);
|
2022-05-04 02:41:02 +00: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-22 22:43:46 +00:00
|
|
|
if (nv->value.i_len > 0)
|
2022-05-04 02:41:02 +00: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-22 22:43:46 +00: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 02:41:02 +00: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-22 22:43:46 +00:00
|
|
|
struct xfs_attri_log_nameval *nv)
|
2022-05-04 02:41:02 +00:00
|
|
|
{
|
|
|
|
struct xfs_attri_log_item *attrip;
|
|
|
|
|
2024-01-15 22:59:46 +00:00
|
|
|
attrip = kmem_cache_zalloc(xfs_attri_cache, GFP_KERNEL | __GFP_NOFAIL);
|
2022-05-04 02:41:02 +00: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-22 22:43:46 +00: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 02:41:02 +00: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)
|
|
|
|
{
|
2024-01-15 22:59:42 +00:00
|
|
|
kvfree(attrdp->attrd_item.li_lv_shadow);
|
2022-05-20 04:42:49 +00:00
|
|
|
kmem_cache_free(xfs_attrd_cache, attrdp);
|
2022-05-04 02:41:02 +00: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 09:09:07 +00:00
|
|
|
static struct xfs_log_item *
|
|
|
|
xfs_attrd_item_intent(
|
|
|
|
struct xfs_log_item *lip)
|
|
|
|
{
|
|
|
|
return &ATTRD_ITEM(lip)->attrd_attrip->attri_item;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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 06:00:26 +00:00
|
|
|
const struct xfs_attr_intent *attr)
|
2022-05-09 09:09:07 +00:00
|
|
|
{
|
|
|
|
struct xfs_attri_log_format *attrp;
|
|
|
|
|
|
|
|
/*
|
2022-05-22 06:00:26 +00:00
|
|
|
* At this point the xfs_attr_intent has been constructed, and we've
|
2022-05-09 09:09:07 +00:00
|
|
|
* created the log intent. Fill in the attri log item and log format
|
2022-05-22 06:00:26 +00:00
|
|
|
* structure with fields from this xfs_attr_intent
|
2022-05-09 09:09:07 +00:00
|
|
|
*/
|
|
|
|
attrp = &attrip->attri_format;
|
2022-05-11 07:01:22 +00:00
|
|
|
attrp->alfi_ino = attr->xattri_da_args->dp->i_ino;
|
2022-05-22 05:59:48 +00:00
|
|
|
ASSERT(!(attr->xattri_op_flags & ~XFS_ATTRI_OP_FLAGS_TYPE_MASK));
|
2022-05-09 09:09:07 +00: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-22 22:43:46 +00:00
|
|
|
attrp->alfi_value_len = attr->xattri_nameval->value.i_len;
|
|
|
|
attrp->alfi_name_len = attr->xattri_nameval->name.i_len;
|
2022-05-20 04:42:15 +00: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 09:09:07 +00: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 06:00:26 +00: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 01:51:22 +00:00
|
|
|
struct xfs_da_args *args;
|
2022-05-09 09:09:07 +00: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-22 22:43:46 +00: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 01:51:22 +00: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-22 22:43:46 +00: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 09:09:07 +00: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-22 22:43:46 +00:00
|
|
|
|
|
|
|
attrip = xfs_attri_init(mp, attr->xattri_nameval);
|
|
|
|
xfs_attr_log_item(tp, attrip, attr);
|
2022-05-09 09:09:07 +00:00
|
|
|
|
|
|
|
return &attrip->attri_item;
|
|
|
|
}
|
|
|
|
|
2022-05-20 04:41:34 +00:00
|
|
|
static inline void
|
|
|
|
xfs_attr_free_item(
|
2022-05-22 06:00:26 +00:00
|
|
|
struct xfs_attr_intent *attr)
|
2022-05-20 04:41:34 +00: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-22 22:43:46 +00:00
|
|
|
xfs_attri_log_nameval_put(attr->xattri_nameval);
|
2022-05-22 05:59:48 +00:00
|
|
|
if (attr->xattri_da_args->op_flags & XFS_DA_OP_RECOVERY)
|
2024-01-15 22:59:43 +00:00
|
|
|
kfree(attr);
|
2022-05-22 05:59:48 +00:00
|
|
|
else
|
|
|
|
kmem_cache_free(xfs_attr_intent_cache, attr);
|
2022-05-20 04:41:34 +00:00
|
|
|
}
|
|
|
|
|
2024-02-22 20:44:22 +00:00
|
|
|
static inline struct xfs_attr_intent *attri_entry(const struct list_head *e)
|
|
|
|
{
|
|
|
|
return list_entry(e, struct xfs_attr_intent, xattri_list);
|
|
|
|
}
|
|
|
|
|
2022-05-09 09:09:07 +00: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)
|
|
|
|
{
|
2024-02-22 20:44:22 +00:00
|
|
|
struct xfs_attr_intent *attr = attri_entry(item);
|
2023-11-30 18:23:19 +00:00
|
|
|
struct xfs_da_args *args;
|
2022-05-09 09:09:07 +00:00
|
|
|
int error;
|
|
|
|
|
2023-11-30 18:23:19 +00:00
|
|
|
args = attr->xattri_da_args;
|
2022-05-09 09:09:07 +00:00
|
|
|
|
2023-11-30 18:23:19 +00:00
|
|
|
/* Reset trans after EAGAIN cycle since the transaction is new */
|
|
|
|
args->trans = tp;
|
|
|
|
|
|
|
|
if (XFS_TEST_ERROR(false, args->dp->i_mount, XFS_ERRTAG_LARP)) {
|
|
|
|
error = -EIO;
|
|
|
|
goto out;
|
|
|
|
}
|
2022-05-09 09:09:07 +00:00
|
|
|
|
2023-11-30 18:23:19 +00:00
|
|
|
/* If an attr removal is trivially complete, we're done. */
|
|
|
|
if (attr->xattri_op_flags == XFS_ATTRI_OP_FLAGS_REMOVE &&
|
|
|
|
!xfs_inode_hasattr(args->dp)) {
|
|
|
|
error = 0;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
error = xfs_attr_set_iter(attr);
|
|
|
|
if (!error && attr->xattri_dela_state != XFS_DAS_DONE)
|
|
|
|
return -EAGAIN;
|
2022-05-09 09:09:07 +00:00
|
|
|
|
2023-11-30 18:23:19 +00:00
|
|
|
out:
|
|
|
|
xfs_attr_free_item(attr);
|
2022-05-09 09:09:07 +00: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)
|
|
|
|
{
|
2024-02-22 20:44:22 +00:00
|
|
|
struct xfs_attr_intent *attr = attri_entry(item);
|
2022-05-09 09:09:07 +00:00
|
|
|
|
2022-05-20 04:41:34 +00:00
|
|
|
xfs_attr_free_item(attr);
|
2022-05-09 09:09:07 +00:00
|
|
|
}
|
|
|
|
|
2022-05-04 02:41:02 +00: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 05:59:48 +00:00
|
|
|
XFS_ATTRI_OP_FLAGS_TYPE_MASK;
|
2022-05-04 02:41:02 +00:00
|
|
|
|
|
|
|
if (attrp->__pad != 0)
|
|
|
|
return false;
|
|
|
|
|
2022-05-22 05:59:48 +00:00
|
|
|
if (attrp->alfi_op_flags & ~XFS_ATTRI_OP_FLAGS_TYPE_MASK)
|
2022-05-20 04:41:47 +00:00
|
|
|
return false;
|
|
|
|
|
2022-05-20 04:42:15 +00:00
|
|
|
if (attrp->alfi_attr_filter & ~XFS_ATTRI_FILTER_MASK)
|
|
|
|
return false;
|
|
|
|
|
2022-05-04 02:41:02 +00:00
|
|
|
/* alfi_op_flags should be either a set or remove */
|
2022-05-11 07:05:23 +00:00
|
|
|
switch (op) {
|
2022-05-22 05:59:48 +00:00
|
|
|
case XFS_ATTRI_OP_FLAGS_SET:
|
|
|
|
case XFS_ATTRI_OP_FLAGS_REPLACE:
|
|
|
|
case XFS_ATTRI_OP_FLAGS_REMOVE:
|
2022-05-11 07:05:23 +00:00
|
|
|
break;
|
|
|
|
default:
|
2022-05-04 02:41:02 +00:00
|
|
|
return false;
|
2022-05-11 07:05:23 +00:00
|
|
|
}
|
2022-05-04 02:41:02 +00: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);
|
|
|
|
}
|
|
|
|
|
2023-11-22 19:13:03 +00:00
|
|
|
static inline struct xfs_attr_intent *
|
|
|
|
xfs_attri_recover_work(
|
|
|
|
struct xfs_mount *mp,
|
2023-11-22 18:38:10 +00:00
|
|
|
struct xfs_defer_pending *dfp,
|
2023-11-22 19:13:03 +00:00
|
|
|
struct xfs_attri_log_format *attrp,
|
2023-11-22 21:39:25 +00:00
|
|
|
struct xfs_inode **ipp,
|
2023-11-22 19:13:03 +00:00
|
|
|
struct xfs_attri_log_nameval *nv)
|
2022-05-09 09:09:07 +00:00
|
|
|
{
|
2022-05-22 06:00:26 +00:00
|
|
|
struct xfs_attr_intent *attr;
|
2022-05-09 09:09:07 +00:00
|
|
|
struct xfs_da_args *args;
|
|
|
|
int local;
|
2023-11-22 21:39:25 +00:00
|
|
|
int error;
|
|
|
|
|
|
|
|
error = xlog_recover_iget(mp, attrp->alfi_ino, ipp);
|
|
|
|
if (error)
|
|
|
|
return ERR_PTR(error);
|
2022-05-09 09:09:07 +00:00
|
|
|
|
2024-01-15 22:59:39 +00:00
|
|
|
attr = kzalloc(sizeof(struct xfs_attr_intent) +
|
2024-01-15 22:59:47 +00:00
|
|
|
sizeof(struct xfs_da_args), GFP_KERNEL | __GFP_NOFAIL);
|
2022-05-09 09:09:07 +00:00
|
|
|
args = (struct xfs_da_args *)(attr + 1);
|
|
|
|
|
2022-05-11 07:01:22 +00:00
|
|
|
attr->xattri_da_args = args;
|
2022-05-20 04:41:47 +00:00
|
|
|
attr->xattri_op_flags = attrp->alfi_op_flags &
|
2022-05-22 05:59:48 +00:00
|
|
|
XFS_ATTRI_OP_FLAGS_TYPE_MASK;
|
2022-05-09 09:09:07 +00: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-22 22:43:46 +00: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);
|
|
|
|
|
2023-11-22 21:39:25 +00:00
|
|
|
args->dp = *ipp;
|
2022-05-09 09:09:07 +00:00
|
|
|
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-22 22:43:46 +00:00
|
|
|
args->name = nv->name.i_addr;
|
|
|
|
args->namelen = nv->name.i_len;
|
2022-05-09 09:09:07 +00:00
|
|
|
args->hashval = xfs_da_hashname(args->name, args->namelen);
|
2022-05-20 04:42:15 +00: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 01:51:22 +00:00
|
|
|
args->op_flags = XFS_DA_OP_RECOVERY | XFS_DA_OP_OKNOENT |
|
|
|
|
XFS_DA_OP_LOGGED;
|
2024-04-15 21:54:34 +00:00
|
|
|
args->owner = args->dp->i_ino;
|
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 01:51:22 +00:00
|
|
|
|
|
|
|
ASSERT(xfs_sb_version_haslogxattrs(&mp->m_sb));
|
2022-05-09 09:09:07 +00:00
|
|
|
|
2022-05-20 04:41:47 +00:00
|
|
|
switch (attr->xattri_op_flags) {
|
2022-05-22 05:59:48 +00: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-22 22:43:46 +00:00
|
|
|
args->value = nv->value.i_addr;
|
|
|
|
args->valuelen = nv->value.i_len;
|
2022-05-09 09:09:07 +00: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 05:12:56 +00: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 05:12:52 +00:00
|
|
|
break;
|
2022-05-22 05:59:48 +00:00
|
|
|
case XFS_ATTRI_OP_FLAGS_REMOVE:
|
2022-05-12 05:12:56 +00: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 05:12:52 +00:00
|
|
|
break;
|
2022-05-09 09:09:07 +00:00
|
|
|
}
|
2022-05-11 07:01:23 +00:00
|
|
|
|
2023-11-22 19:13:03 +00:00
|
|
|
xfs_defer_add_item(dfp, &attr->xattri_list);
|
|
|
|
return attr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Process an attr intent item that was recovered from the log. We need to
|
|
|
|
* delete the attr that it describes.
|
|
|
|
*/
|
|
|
|
STATIC int
|
2023-11-22 21:39:25 +00:00
|
|
|
xfs_attr_recover_work(
|
2023-11-22 19:13:03 +00:00
|
|
|
struct xfs_defer_pending *dfp,
|
|
|
|
struct list_head *capture_list)
|
|
|
|
{
|
|
|
|
struct xfs_log_item *lip = dfp->dfp_intent;
|
|
|
|
struct xfs_attri_log_item *attrip = ATTRI_ITEM(lip);
|
|
|
|
struct xfs_attr_intent *attr;
|
|
|
|
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 resv;
|
|
|
|
struct xfs_attri_log_format *attrp;
|
|
|
|
struct xfs_attri_log_nameval *nv = attrip->attri_nameval;
|
|
|
|
int error;
|
|
|
|
int total;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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_attr_namecheck(nv->name.i_addr, nv->name.i_len))
|
|
|
|
return -EFSCORRUPTED;
|
|
|
|
|
2023-11-22 21:39:25 +00:00
|
|
|
attr = xfs_attri_recover_work(mp, dfp, attrp, &ip, nv);
|
|
|
|
if (IS_ERR(attr))
|
|
|
|
return PTR_ERR(attr);
|
2023-11-22 19:13:03 +00:00
|
|
|
args = attr->xattri_da_args;
|
|
|
|
|
xfs: reserve less log space when recovering log intent items
Wengang Wang reports that a customer's system was running a number of
truncate operations on a filesystem with a very small log. Contention
on the reserve heads lead to other threads stalling on smaller updates
(e.g. mtime updates) long enough to result in the node being rebooted
on account of the lack of responsivenes. The node failed to recover
because log recovery of an EFI became stuck waiting for a grant of
reserve space. From Wengang's report:
"For the file deletion, log bytes are reserved basing on
xfs_mount->tr_itruncate which is:
tr_logres = 175488,
tr_logcount = 2,
tr_logflags = XFS_TRANS_PERM_LOG_RES,
"You see it's a permanent log reservation with two log operations (two
transactions in rolling mode). After calculation (xlog_calc_unit_res()
adds space for various log headers), the final log space needed per
transaction changes from 175488 to 180208 bytes. So the total log
space needed is 360416 bytes (180208 * 2). [That quantity] of log space
(360416 bytes) needs to be reserved for both run time inode removing
(xfs_inactive_truncate()) and EFI recover (xfs_efi_item_recover())."
In other words, runtime pre-reserves 360K of space in anticipation of
running a chain of two transactions in which each transaction gets a
180K reservation.
Now that we've allocated the transaction, we delete the bmap mapping,
log an EFI to free the space, and roll the transaction as part of
finishing the deferops chain. Rolling creates a new xfs_trans which
shares its ticket with the old transaction. Next, xfs_trans_roll calls
__xfs_trans_commit with regrant == true, which calls xlog_cil_commit
with the same regrant parameter.
xlog_cil_commit calls xfs_log_ticket_regrant, which decrements t_cnt and
subtracts t_curr_res from the reservation and write heads.
If the filesystem is fresh and the first transaction only used (say)
20K, then t_curr_res will be 160K, and we give that much reservation
back to the reservation head. Or if the file is really fragmented and
the first transaction actually uses 170K, then t_curr_res will be 10K,
and that's what we give back to the reservation.
Having done that, we're now headed into the second transaction with an
EFI and 180K of reservation. Other threads apparently consumed all the
reservation for smaller transactions, such as timestamp updates.
Now let's say the first transaction gets written to disk and we crash
without ever completing the second transaction. Now we remount the fs,
log recovery finds the unfinished EFI, and calls xfs_efi_recover to
finish the EFI. However, xfs_efi_recover starts a new tr_itruncate
tranasction, which asks for 360K log reservation. This is a lot more
than the 180K that we had reserved at the time of the crash. If the
first EFI to be recovered is also pinning the tail of the log, we will
be unable to free any space in the log, and recovery livelocks.
Wengang confirmed this:
"Now we have the second transaction which has 180208 log bytes reserved
too. The second transaction is supposed to process intents including
extent freeing. With my hacking patch, I blocked the extent freeing 5
hours. So in that 5 hours, 180208 (NOT 360416) log bytes are reserved.
"With my test case, other transactions (update timestamps) then happen.
As my hacking patch pins the journal tail, those timestamp-updating
transactions finally use up (almost) all the left available log space
(in memory in on disk). And finally the on disk (and in memory)
available log space goes down near to 180208 bytes. Those 180208 bytes
are reserved by [the] second (extent-free) transaction [in the chain]."
Wengang and I noticed that EFI recovery starts a transaction, completes
one step of the chain, and commits the transaction without completing
any other steps of the chain. Those subsequent steps are completed by
xlog_finish_defer_ops, which allocates yet another transaction to
finish the rest of the chain. That transaction gets the same tr_logres
as the head transaction, but with tr_logcount = 1 to force regranting
with every roll to avoid livelocks.
In other words, we already figured this out in commit 929b92f64048d
("xfs: xfs_defer_capture should absorb remaining transaction
reservation"), but should have applied that logic to each intent item's
recovery function. For Wengang's case, the xfs_trans_alloc call in the
EFI recovery function should only be asking for a single transaction's
worth of log reservation -- 180K, not 360K.
Quoting Wengang again:
"With log recovery, during EFI recovery, we use tr_itruncate again to
reserve two transactions that needs 360416 log bytes. Reserving 360416
bytes fails [stalls] because we now only have about 180208 available.
"Actually during the EFI recover, we only need one transaction to free
the extents just like the 2nd transaction at RUNTIME. So it only needs
to reserve 180208 rather than 360416 bytes. We have (a bit) more than
180208 available log bytes on disk, so [if we decrease the reservation
to 180K] the reservation goes and the recovery [finishes]. That is to
say: we can fix the log recover part to fix the issue. We can introduce
a new xfs_trans_res xfs_mount->tr_ext_free
{
tr_logres = 175488,
tr_logcount = 0,
tr_logflags = 0,
}
"and use tr_ext_free instead of tr_itruncate in EFI recover."
However, I don't think it quite makes sense to create an entirely new
transaction reservation type to handle single-stepping during log
recovery. Instead, we should copy the transaction reservation
information in the xfs_mount, change tr_logcount to 1, and pass that
into xfs_trans_alloc. We know this won't risk changing the min log size
computation since we always ask for a fraction of the reservation for
all known transaction types.
This looks like it's been lurking in the codebase since commit
3d3c8b5222b92, which changed the xfs_trans_reserve call in
xlog_recover_process_efi to use the tr_logcount in tr_itruncate.
That changed the EFI recovery transaction from making a
non-XFS_TRANS_PERM_LOG_RES request for one transaction's worth of log
space to a XFS_TRANS_PERM_LOG_RES request for two transactions worth.
Fixes: 3d3c8b5222b92 ("xfs: refactor xfs_trans_reserve() interface")
Complements: 929b92f64048d ("xfs: xfs_defer_capture should absorb remaining transaction reservation")
Suggested-by: Wengang Wang <wen.gang.wang@oracle.com>
Cc: Srikanth C S <srikanth.c.s@oracle.com>
[djwong: apply the same transformation to all log intent recovery]
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
2023-09-11 15:39:05 +00:00
|
|
|
xfs_init_attr_trans(args, &resv, &total);
|
|
|
|
resv = xlog_recover_resv(&resv);
|
|
|
|
error = xfs_trans_alloc(mp, &resv, total, 0, XFS_TRANS_RESERVE, &tp);
|
2022-05-09 09:09:07 +00:00
|
|
|
if (error)
|
2023-11-22 19:13:03 +00:00
|
|
|
return error;
|
2022-05-09 09:09:07 +00:00
|
|
|
args->trans = tp;
|
2023-11-22 19:13:03 +00:00
|
|
|
|
2022-05-09 09:09:07 +00:00
|
|
|
xfs_ilock(ip, XFS_ILOCK_EXCL);
|
|
|
|
xfs_trans_ijoin(tp, ip, 0);
|
|
|
|
|
2023-11-22 19:25:45 +00:00
|
|
|
error = xlog_recover_finish_intent(tp, dfp);
|
2023-11-30 17:57:42 +00:00
|
|
|
if (error == -EFSCORRUPTED)
|
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
&attrip->attri_format,
|
|
|
|
sizeof(attrip->attri_format));
|
2022-05-09 09:09:07 +00: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);
|
|
|
|
return error;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Re-log an intent item to push the log tail forward. */
|
|
|
|
static struct xfs_log_item *
|
2023-11-30 20:31:30 +00:00
|
|
|
xfs_attr_relog_intent(
|
|
|
|
struct xfs_trans *tp,
|
2022-05-09 09:09:07 +00:00
|
|
|
struct xfs_log_item *intent,
|
2023-11-30 20:31:30 +00:00
|
|
|
struct xfs_log_item *done_item)
|
2022-05-09 09:09:07 +00:00
|
|
|
{
|
|
|
|
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;
|
|
|
|
|
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-22 22:43:46 +00: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 09:09:07 +00: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 04:42:15 +00:00
|
|
|
new_attrp->alfi_attr_filter = old_attrp->alfi_attr_filter;
|
2022-05-09 09:09:07 +00:00
|
|
|
|
|
|
|
return &new_attrip->attri_item;
|
|
|
|
}
|
|
|
|
|
2023-12-13 09:06:30 +00:00
|
|
|
/* 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)
|
|
|
|
{
|
|
|
|
struct xfs_attri_log_item *attrip;
|
|
|
|
struct xfs_attrd_log_item *attrdp;
|
|
|
|
|
|
|
|
attrip = ATTRI_ITEM(intent);
|
|
|
|
|
2024-01-15 22:59:46 +00:00
|
|
|
attrdp = kmem_cache_zalloc(xfs_attrd_cache, GFP_KERNEL | __GFP_NOFAIL);
|
2023-12-13 09:06:30 +00: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;
|
|
|
|
|
|
|
|
return &attrdp->attrd_item;
|
|
|
|
}
|
|
|
|
|
|
|
|
const struct xfs_defer_op_type xfs_attr_defer_type = {
|
2023-12-13 09:06:31 +00:00
|
|
|
.name = "attr",
|
2023-12-13 09:06:30 +00:00
|
|
|
.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,
|
|
|
|
.recover_work = xfs_attr_recover_work,
|
|
|
|
.relog_intent = xfs_attr_relog_intent,
|
|
|
|
};
|
|
|
|
|
2022-05-04 02:41:02 +00: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-22 22:43:46 +00:00
|
|
|
struct xfs_attri_log_nameval *nv;
|
|
|
|
const void *attr_value = NULL;
|
2022-05-20 04:42:36 +00:00
|
|
|
const void *attr_name;
|
2022-10-20 23:08:11 +00:00
|
|
|
size_t len;
|
2022-05-04 02:41:02 +00: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-22 22:43:46 +00:00
|
|
|
attri_formatp = item->ri_buf[0].i_addr;
|
2022-05-20 04:42:36 +00:00
|
|
|
attr_name = item->ri_buf[1].i_addr;
|
2022-05-04 02:41:02 +00:00
|
|
|
|
2022-05-20 04:42:36 +00:00
|
|
|
/* Validate xfs_attri_log_format before the large memory allocation */
|
2022-10-20 23:08:11 +00:00
|
|
|
len = sizeof(struct xfs_attri_log_format);
|
|
|
|
if (item->ri_buf[0].i_len != len) {
|
2022-10-25 22:07:14 +00:00
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
item->ri_buf[0].i_addr, item->ri_buf[0].i_len);
|
2022-10-20 23:08:11 +00:00
|
|
|
return -EFSCORRUPTED;
|
|
|
|
}
|
|
|
|
|
2022-05-04 02:41:02 +00:00
|
|
|
if (!xfs_attri_validate(mp, attri_formatp)) {
|
2022-10-25 22:07:14 +00:00
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
item->ri_buf[0].i_addr, item->ri_buf[0].i_len);
|
2022-05-04 02:41:02 +00:00
|
|
|
return -EFSCORRUPTED;
|
|
|
|
}
|
|
|
|
|
2022-10-20 23:08:11 +00:00
|
|
|
/* Validate the attr name */
|
|
|
|
if (item->ri_buf[1].i_len !=
|
|
|
|
xlog_calc_iovec_len(attri_formatp->alfi_name_len)) {
|
2022-10-25 22:07:14 +00:00
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
item->ri_buf[0].i_addr, item->ri_buf[0].i_len);
|
2022-10-20 23:08:11 +00:00
|
|
|
return -EFSCORRUPTED;
|
|
|
|
}
|
|
|
|
|
2022-05-20 04:42:36 +00:00
|
|
|
if (!xfs_attr_namecheck(attr_name, attri_formatp->alfi_name_len)) {
|
2022-10-25 22:07:14 +00:00
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
item->ri_buf[1].i_addr, item->ri_buf[1].i_len);
|
2022-05-20 04:42:36 +00:00
|
|
|
return -EFSCORRUPTED;
|
|
|
|
}
|
|
|
|
|
2022-10-20 23:08:11 +00: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-25 22:07:14 +00:00
|
|
|
XFS_CORRUPTION_ERROR(__func__, XFS_ERRLEVEL_LOW, mp,
|
|
|
|
item->ri_buf[0].i_addr,
|
|
|
|
item->ri_buf[0].i_len);
|
2022-10-20 23:08:11 +00: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-22 22:43:46 +00:00
|
|
|
attr_value = item->ri_buf[2].i_addr;
|
2022-10-20 23:08:11 +00: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-22 22:43:46 +00: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 02:41:02 +00: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-22 22:43:46 +00:00
|
|
|
attrip = xfs_attri_init(mp, nv);
|
2022-10-20 23:08:11 +00:00
|
|
|
memcpy(&attrip->attri_format, attri_formatp, len);
|
2022-05-04 02:41:02 +00:00
|
|
|
|
2023-11-22 18:23:23 +00:00
|
|
|
xlog_recover_intent_item(log, &attrip->attri_item, lsn,
|
2023-12-14 05:16:32 +00:00
|
|
|
&xfs_attr_defer_type);
|
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-22 22:43:46 +00:00
|
|
|
xfs_attri_log_nameval_put(nv);
|
2022-05-04 02:41:02 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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-25 22:07:14 +00: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 02:41:02 +00: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,
|
|
|
|
.iop_match = xfs_attri_item_match,
|
|
|
|
};
|
|
|
|
|
|
|
|
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 09:09:07 +00:00
|
|
|
.iop_intent = xfs_attrd_item_intent,
|
2022-05-04 02:41:02 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
const struct xlog_recover_item_ops xlog_attrd_item_ops = {
|
|
|
|
.item_type = XFS_LI_ATTRD,
|
|
|
|
.commit_pass2 = xlog_recover_attrd_commit_pass2,
|
|
|
|
};
|