2022-05-04 05:41:02 +03: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 12:09:07 +03:00
# include "xfs_bmap_btree.h"
2022-05-04 05:41:02 +03: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_inode.h"
# include "xfs_trans_space.h"
2022-05-11 10:01:22 +03:00
# include "xfs_errortag.h"
2022-05-04 05:41:02 +03:00
# include "xfs_error.h"
# include "xfs_log_priv.h"
# include "xfs_log_recover.h"
2022-05-22 08:59:48 +03:00
struct kmem_cache * xfs_attri_cache ;
struct kmem_cache * xfs_attrd_cache ;
2022-05-04 05:41:02 +03:00
static const struct xfs_item_ops xfs_attri_item_ops ;
static const struct xfs_item_ops xfs_attrd_item_ops ;
2022-05-09 12:09:07 +03:00
static struct xfs_attrd_log_item * xfs_trans_get_attrd ( struct xfs_trans * tp ,
struct xfs_attri_log_item * attrip ) ;
2022-05-04 05:41:02 +03:00
static inline struct xfs_attri_log_item * ATTRI_ITEM ( struct xfs_log_item * lip )
{
return container_of ( lip , struct xfs_attri_log_item , attri_item ) ;
}
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03: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 64 kB 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 ) ;
if ( ! nv )
return nv ;
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 05:41:02 +03:00
STATIC void
xfs_attri_item_free (
struct xfs_attri_log_item * attrip )
{
kmem_free ( attrip - > attri_item . li_lv_shadow ) ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
xfs_attri_log_nameval_put ( attrip - > attri_nameval ) ;
kmem_cache_free ( xfs_attri_cache , attrip ) ;
2022-05-04 05:41:02 +03:00
}
/*
* Freeing the attrip requires that we remove it from the AIL if it has already
* been placed there . However , the ATTRI may not yet have been placed in the
* AIL when called by xfs_attri_release ( ) from ATTRD processing due to the
* ordering of committed vs unpin operations in bulk insert operations . Hence
* the reference count to ensure only the last caller frees the ATTRI .
*/
STATIC void
xfs_attri_release (
struct xfs_attri_log_item * attrip )
{
ASSERT ( atomic_read ( & attrip - > attri_refcount ) > 0 ) ;
if ( ! atomic_dec_and_test ( & attrip - > attri_refcount ) )
return ;
xfs_trans_ail_delete ( & attrip - > attri_item , 0 ) ;
xfs_attri_item_free ( attrip ) ;
}
STATIC void
xfs_attri_item_size (
struct xfs_log_item * lip ,
int * nvecs ,
int * nbytes )
{
struct xfs_attri_log_item * attrip = ATTRI_ITEM ( lip ) ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
struct xfs_attri_log_nameval * nv = attrip - > attri_nameval ;
2022-05-04 05:41:02 +03:00
* nvecs + = 2 ;
* nbytes + = sizeof ( struct xfs_attri_log_format ) +
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
xlog_calc_iovec_len ( nv - > name . i_len ) ;
2022-05-04 05:41:02 +03:00
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
if ( ! nv - > value . i_len )
2022-05-04 05:41:02 +03:00
return ;
* nvecs + = 1 ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
* nbytes + = xlog_calc_iovec_len ( nv - > value . i_len ) ;
2022-05-04 05:41:02 +03:00
}
/*
* This is called to fill in the log iovecs for the given attri log
* item . We use 1 iovec for the attri_format_item , 1 for the name , and
* another for the value if it is present
*/
STATIC void
xfs_attri_item_format (
struct xfs_log_item * lip ,
struct xfs_log_vec * lv )
{
struct xfs_attri_log_item * attrip = ATTRI_ITEM ( lip ) ;
struct xfs_log_iovec * vecp = NULL ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
struct xfs_attri_log_nameval * nv = attrip - > attri_nameval ;
2022-05-04 05:41:02 +03:00
attrip - > attri_format . alfi_type = XFS_LI_ATTRI ;
attrip - > attri_format . alfi_size = 1 ;
/*
* This size accounting must be done before copying the attrip into the
* iovec . If we do it after , the wrong size will be recorded to the log
* and we trip across assertion checks for bad region sizes later during
* the log recovery .
*/
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
ASSERT ( nv - > name . i_len > 0 ) ;
2022-05-04 05:41:02 +03:00
attrip - > attri_format . alfi_size + + ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
if ( nv - > value . i_len > 0 )
2022-05-04 05:41:02 +03:00
attrip - > attri_format . alfi_size + + ;
xlog_copy_iovec ( lv , & vecp , XLOG_REG_TYPE_ATTRI_FORMAT ,
& attrip - > attri_format ,
sizeof ( struct xfs_attri_log_format ) ) ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03: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 05:41:02 +03:00
}
/*
* The unpin operation is the last place an ATTRI is manipulated in the log . It
* is either inserted in the AIL or aborted in the event of a log I / O error . In
* either case , the ATTRI transaction has been successfully committed to make
* it this far . Therefore , we expect whoever committed the ATTRI to either
* construct and commit the ATTRD or drop the ATTRD ' s reference in the event of
* error . Simply drop the log ' s ATTRI reference now that the log is done with
* it .
*/
STATIC void
xfs_attri_item_unpin (
struct xfs_log_item * lip ,
int remove )
{
xfs_attri_release ( ATTRI_ITEM ( lip ) ) ;
}
STATIC void
xfs_attri_item_release (
struct xfs_log_item * lip )
{
xfs_attri_release ( ATTRI_ITEM ( lip ) ) ;
}
/*
* Allocate and initialize an attri item . Caller may allocate an additional
* trailing buffer for name and value
*/
STATIC struct xfs_attri_log_item *
xfs_attri_init (
struct xfs_mount * mp ,
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
struct xfs_attri_log_nameval * nv )
2022-05-04 05:41:02 +03:00
{
struct xfs_attri_log_item * attrip ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
attrip = kmem_cache_zalloc ( xfs_attri_cache , GFP_NOFS | __GFP_NOFAIL ) ;
2022-05-04 05:41:02 +03:00
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03: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 05:41:02 +03: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 ;
}
/*
* Copy an attr format buffer from the given buf , and into the destination attr
* format structure .
*/
STATIC int
xfs_attri_copy_format (
struct xfs_log_iovec * buf ,
struct xfs_attri_log_format * dst_attr_fmt )
{
struct xfs_attri_log_format * src_attr_fmt = buf - > i_addr ;
size_t len ;
len = sizeof ( struct xfs_attri_log_format ) ;
if ( buf - > i_len ! = len ) {
XFS_ERROR_REPORT ( __func__ , XFS_ERRLEVEL_LOW , NULL ) ;
return - EFSCORRUPTED ;
}
memcpy ( ( char * ) dst_attr_fmt , ( char * ) src_attr_fmt , len ) ;
return 0 ;
}
static inline struct xfs_attrd_log_item * ATTRD_ITEM ( struct xfs_log_item * lip )
{
return container_of ( lip , struct xfs_attrd_log_item , attrd_item ) ;
}
STATIC void
xfs_attrd_item_free ( struct xfs_attrd_log_item * attrdp )
{
kmem_free ( attrdp - > attrd_item . li_lv_shadow ) ;
2022-05-20 07:42:49 +03:00
kmem_cache_free ( xfs_attrd_cache , attrdp ) ;
2022-05-04 05:41:02 +03: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 12:09:07 +03:00
static struct xfs_log_item *
xfs_attrd_item_intent (
struct xfs_log_item * lip )
{
return & ATTRD_ITEM ( lip ) - > attrd_attrip - > attri_item ;
}
/*
* Performs one step of an attribute update intent and marks the attrd item
* dirty . . An attr operation may be a set or a remove . Note that the
* transaction is marked dirty regardless of whether the operation succeeds or
* fails to support the ATTRI / ATTRD lifecycle rules .
*/
STATIC int
xfs_xattri_finish_update (
2022-05-22 09:00:26 +03:00
struct xfs_attr_intent * attr ,
2022-05-12 08:12:56 +03:00
struct xfs_attrd_log_item * attrdp )
2022-05-09 12:09:07 +03:00
{
2022-05-11 10:01:22 +03:00
struct xfs_da_args * args = attr - > xattri_da_args ;
2022-05-09 12:09:07 +03:00
int error ;
2022-05-11 10:01:22 +03:00
if ( XFS_TEST_ERROR ( false , args - > dp - > i_mount , XFS_ERRTAG_LARP ) ) {
error = - EIO ;
goto out ;
}
2022-05-12 08:12:56 +03:00
error = xfs_attr_set_iter ( attr ) ;
if ( ! error & & attr - > xattri_dela_state ! = XFS_DAS_DONE )
error = - EAGAIN ;
2022-05-11 10:01:22 +03:00
out :
2022-05-09 12:09:07 +03:00
/*
* Mark the transaction dirty , even on error . This ensures the
* transaction is aborted , which :
*
* 1. ) releases the ATTRI and frees the ATTRD
* 2. ) shuts down the filesystem
*/
args - > trans - > t_flags | = XFS_TRANS_DIRTY | XFS_TRANS_HAS_INTENT_DONE ;
/*
* attr intent / done items are null when logged attributes are disabled
*/
if ( attrdp )
set_bit ( XFS_LI_DIRTY , & attrdp - > attrd_item . li_flags ) ;
return error ;
}
/* Log an attr to the intent item. */
STATIC void
xfs_attr_log_item (
struct xfs_trans * tp ,
struct xfs_attri_log_item * attrip ,
2022-05-22 09:00:26 +03:00
const struct xfs_attr_intent * attr )
2022-05-09 12:09:07 +03:00
{
struct xfs_attri_log_format * attrp ;
tp - > t_flags | = XFS_TRANS_DIRTY ;
set_bit ( XFS_LI_DIRTY , & attrip - > attri_item . li_flags ) ;
/*
2022-05-22 09:00:26 +03:00
* At this point the xfs_attr_intent has been constructed , and we ' ve
2022-05-09 12:09:07 +03:00
* created the log intent . Fill in the attri log item and log format
2022-05-22 09:00:26 +03:00
* structure with fields from this xfs_attr_intent
2022-05-09 12:09:07 +03:00
*/
attrp = & attrip - > attri_format ;
2022-05-11 10:01:22 +03:00
attrp - > alfi_ino = attr - > xattri_da_args - > dp - > i_ino ;
2022-05-22 08:59:48 +03:00
ASSERT ( ! ( attr - > xattri_op_flags & ~ XFS_ATTRI_OP_FLAGS_TYPE_MASK ) ) ;
2022-05-09 12:09:07 +03:00
attrp - > alfi_op_flags = attr - > xattri_op_flags ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
attrp - > alfi_value_len = attr - > xattri_nameval - > value . i_len ;
attrp - > alfi_name_len = attr - > xattri_nameval - > name . i_len ;
2022-05-20 07:42:15 +03: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 12:09:07 +03: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 09:00:26 +03:00
struct xfs_attr_intent * attr ;
2022-05-09 12:09:07 +03:00
ASSERT ( count = = 1 ) ;
if ( ! xfs_sb_version_haslogxattrs ( & mp - > m_sb ) )
return NULL ;
/*
* Each attr item only performs one attribute operation at a time , so
* this is a list of one
*/
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
attr = list_first_entry_or_null ( items , struct xfs_attr_intent ,
xattri_list ) ;
/*
* 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 ) {
struct xfs_da_args * args = attr - > xattri_da_args ;
/*
* 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 12:09:07 +03:00
}
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
if ( ! attr - > xattri_nameval )
return ERR_PTR ( - ENOMEM ) ;
attrip = xfs_attri_init ( mp , attr - > xattri_nameval ) ;
xfs_trans_add_item ( tp , & attrip - > attri_item ) ;
xfs_attr_log_item ( tp , attrip , attr ) ;
2022-05-09 12:09:07 +03:00
return & attrip - > attri_item ;
}
2022-05-20 07:41:34 +03:00
static inline void
xfs_attr_free_item (
2022-05-22 09:00:26 +03:00
struct xfs_attr_intent * attr )
2022-05-20 07:41:34 +03:00
{
if ( attr - > xattri_da_state )
xfs_da_state_free ( attr - > xattri_da_state ) ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
xfs_attri_log_nameval_put ( attr - > xattri_nameval ) ;
2022-05-22 08:59:48 +03:00
if ( attr - > xattri_da_args - > op_flags & XFS_DA_OP_RECOVERY )
kmem_free ( attr ) ;
else
kmem_cache_free ( xfs_attr_intent_cache , attr ) ;
2022-05-20 07:41:34 +03:00
}
2022-05-09 12:09:07 +03:00
/* Process an attr. */
STATIC int
xfs_attr_finish_item (
struct xfs_trans * tp ,
struct xfs_log_item * done ,
struct list_head * item ,
struct xfs_btree_cur * * state )
{
2022-05-22 09:00:26 +03:00
struct xfs_attr_intent * attr ;
2022-05-09 12:09:07 +03:00
struct xfs_attrd_log_item * done_item = NULL ;
int error ;
2022-05-22 09:00:26 +03:00
attr = container_of ( item , struct xfs_attr_intent , xattri_list ) ;
2022-05-09 12:09:07 +03:00
if ( done )
done_item = ATTRD_ITEM ( done ) ;
/*
* Always reset trans after EAGAIN cycle
* since the transaction is new
*/
2022-05-11 10:01:22 +03:00
attr - > xattri_da_args - > trans = tp ;
2022-05-09 12:09:07 +03:00
2022-05-12 08:12:56 +03:00
error = xfs_xattri_finish_update ( attr , done_item ) ;
2022-05-09 12:09:07 +03:00
if ( error ! = - EAGAIN )
2022-05-20 07:41:34 +03:00
xfs_attr_free_item ( attr ) ;
2022-05-09 12:09:07 +03:00
return error ;
}
/* Abort all pending ATTRs. */
STATIC void
xfs_attr_abort_intent (
struct xfs_log_item * intent )
{
xfs_attri_release ( ATTRI_ITEM ( intent ) ) ;
}
/* Cancel an attr */
STATIC void
xfs_attr_cancel_item (
struct list_head * item )
{
2022-05-22 09:00:26 +03:00
struct xfs_attr_intent * attr ;
2022-05-09 12:09:07 +03:00
2022-05-22 09:00:26 +03:00
attr = container_of ( item , struct xfs_attr_intent , xattri_list ) ;
2022-05-20 07:41:34 +03:00
xfs_attr_free_item ( attr ) ;
2022-05-09 12:09:07 +03:00
}
2022-05-04 05:41:02 +03: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 08:59:48 +03:00
XFS_ATTRI_OP_FLAGS_TYPE_MASK ;
2022-05-04 05:41:02 +03:00
if ( attrp - > __pad ! = 0 )
return false ;
2022-05-22 08:59:48 +03:00
if ( attrp - > alfi_op_flags & ~ XFS_ATTRI_OP_FLAGS_TYPE_MASK )
2022-05-20 07:41:47 +03:00
return false ;
2022-05-20 07:42:15 +03:00
if ( attrp - > alfi_attr_filter & ~ XFS_ATTRI_FILTER_MASK )
return false ;
2022-05-04 05:41:02 +03:00
/* alfi_op_flags should be either a set or remove */
2022-05-11 10:05:23 +03:00
switch ( op ) {
2022-05-22 08:59:48 +03:00
case XFS_ATTRI_OP_FLAGS_SET :
case XFS_ATTRI_OP_FLAGS_REPLACE :
case XFS_ATTRI_OP_FLAGS_REMOVE :
2022-05-11 10:05:23 +03:00
break ;
default :
2022-05-04 05:41:02 +03:00
return false ;
2022-05-11 10:05:23 +03:00
}
2022-05-04 05:41:02 +03:00
if ( attrp - > alfi_value_len > XATTR_SIZE_MAX )
return false ;
if ( ( attrp - > alfi_name_len > XATTR_NAME_MAX ) | |
( attrp - > alfi_name_len = = 0 ) )
return false ;
return xfs_verify_ino ( mp , attrp - > alfi_ino ) ;
}
2022-05-09 12:09:07 +03:00
/*
* Process an attr intent item that was recovered from the log . We need to
* delete the attr that it describes .
*/
STATIC int
xfs_attri_item_recover (
struct xfs_log_item * lip ,
struct list_head * capture_list )
{
struct xfs_attri_log_item * attrip = ATTRI_ITEM ( lip ) ;
2022-05-22 09:00:26 +03:00
struct xfs_attr_intent * attr ;
2022-05-09 12:09:07 +03:00
struct xfs_mount * mp = lip - > li_log - > l_mp ;
struct xfs_inode * ip ;
struct xfs_da_args * args ;
struct xfs_trans * tp ;
struct xfs_trans_res tres ;
struct xfs_attri_log_format * attrp ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
struct xfs_attri_log_nameval * nv = attrip - > attri_nameval ;
2022-05-09 12:09:07 +03:00
int error , ret = 0 ;
int total ;
int local ;
struct xfs_attrd_log_item * done_item = NULL ;
/*
* First check the validity of the attr described by the ATTRI . If any
* are bad , then assume that all are bad and just toss the ATTRI .
*/
attrp = & attrip - > attri_format ;
if ( ! xfs_attri_validate ( mp , attrp ) | |
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
! xfs_attr_namecheck ( nv - > name . i_addr , nv - > name . i_len ) )
2022-05-09 12:09:07 +03:00
return - EFSCORRUPTED ;
error = xlog_recover_iget ( mp , attrp - > alfi_ino , & ip ) ;
if ( error )
return error ;
2022-05-22 09:00:26 +03:00
attr = kmem_zalloc ( sizeof ( struct xfs_attr_intent ) +
2022-05-09 12:09:07 +03:00
sizeof ( struct xfs_da_args ) , KM_NOFS ) ;
args = ( struct xfs_da_args * ) ( attr + 1 ) ;
2022-05-11 10:01:22 +03:00
attr - > xattri_da_args = args ;
2022-05-20 07:41:47 +03:00
attr - > xattri_op_flags = attrp - > alfi_op_flags &
2022-05-22 08:59:48 +03:00
XFS_ATTRI_OP_FLAGS_TYPE_MASK ;
2022-05-09 12:09:07 +03:00
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
/*
* We ' re reconstructing the deferred work state structure from the
* recovered log item . Grab a reference to the name / value buffer and
* attach it to the new work state .
*/
attr - > xattri_nameval = xfs_attri_log_nameval_get ( nv ) ;
ASSERT ( attr - > xattri_nameval ) ;
2022-05-09 12:09:07 +03:00
args - > dp = ip ;
args - > geo = mp - > m_attr_geo ;
args - > whichfork = XFS_ATTR_FORK ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
args - > name = nv - > name . i_addr ;
args - > namelen = nv - > name . i_len ;
2022-05-09 12:09:07 +03:00
args - > hashval = xfs_da_hashname ( args - > name , args - > namelen ) ;
2022-05-20 07:42:15 +03:00
args - > attr_filter = attrp - > alfi_attr_filter & XFS_ATTRI_FILTER_MASK ;
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 08:12:56 +03:00
args - > op_flags = XFS_DA_OP_RECOVERY | XFS_DA_OP_OKNOENT ;
2022-05-09 12:09:07 +03:00
2022-05-20 07:41:47 +03:00
switch ( attr - > xattri_op_flags ) {
2022-05-22 08:59:48 +03:00
case XFS_ATTRI_OP_FLAGS_SET :
case XFS_ATTRI_OP_FLAGS_REPLACE :
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
args - > value = nv - > value . i_addr ;
args - > valuelen = nv - > value . i_len ;
2022-05-09 12:09:07 +03: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 08:12:56 +03: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 08:12:52 +03:00
break ;
2022-05-22 08:59:48 +03:00
case XFS_ATTRI_OP_FLAGS_REMOVE :
xfs: ATTR_REPLACE algorithm with LARP enabled needs rework
We can't use the same algorithm for replacing an existing attribute
when logging attributes. The existing algorithm is essentially:
1. create new attr w/ INCOMPLETE
2. atomically flip INCOMPLETE flags between old + new attribute
3. remove old attr which is marked w/ INCOMPLETE
This algorithm guarantees that we see either the old or new
attribute, and if we fail after the atomic flag flip, we don't have
to recover the removal of the old attr because we never see
INCOMPLETE attributes in lookups.
For logged attributes, however, this does not work. The logged
attribute intents do not track the work that has been done as the
transaction rolls, and hence the only recovery mechanism we have is
"run the replace operation from scratch".
This is further exacerbated by the attempt to avoid needing the
INCOMPLETE flag to create an atomic swap. This means we can create
a second active attribute of the same name before we remove the
original. If we fail at any point after the create but before the
removal has completed, we end up with duplicate attributes in
the attr btree and recovery only tries to replace one of them.
There are several other failure modes where we can leave partially
allocated remote attributes that expose stale data, partially free
remote attributes that enable UAF based stale data exposure, etc.
TO fix this, we need a different algorithm for replace operations
when LARP is enabled. Luckily, it's not that complex if we take the
right first step. That is, the first thing we log is the attri
intent with the new name/value pair and mark the old attr as
INCOMPLETE in the same transaction.
From there, we then remove the old attr and keep relogging the
new name/value in the intent, such that we always know that we have
to create the new attr in recovery. Once the old attr is removed,
we then run a normal ATTR_CREATE operation relogging the intent as
we go. If the new attr is local, then it gets created in a single
atomic transaction that also logs the final intent done. If the new
attr is remote, the we set INCOMPLETE on the new attr while we
allocate and set the remote value, and then we clear the INCOMPLETE
flag at in the last transaction taht logs the final intent done.
If we fail at any point in this algorithm, log recovery will always
see the same state on disk: the new name/value in the intent, and
either an INCOMPLETE attr or no attr in the attr btree. If we find
an INCOMPLETE attr, we run the full replace starting with removing
the INCOMPLETE attr. If we don't find it, then we simply create the
new attr.
Notably, recovery of a failed create that has an INCOMPLETE flag set
is now the same - we start with the lookup of the INCOMPLETE attr,
and if that exists then we do the full replace recovery process,
otherwise we just create the new attr.
Hence changing the way we do the replace operation when LARP is
enabled allows us to use the same log recovery algorithm for both
the ATTR_CREATE and ATTR_REPLACE operations. This is also the same
algorithm we use for runtime ATTR_REPLACE operations (except for the
step setting up the initial conditions).
The result is that:
- ATTR_CREATE uses the same algorithm regardless of whether LARP is
enabled or not
- ATTR_REPLACE with larp=0 is identical to the old algorithm
- ATTR_REPLACE with larp=1 runs an unmodified attr removal algorithm
from the larp=0 code and then runs the unmodified ATTR_CREATE
code.
- log recovery when larp=1 runs the same ATTR_REPLACE algorithm as
it uses at runtime.
Because the state machine is now quite clean, changing the algorithm
is really just a case of changing the initial state and how the
states link together for the ATTR_REPLACE case. Hence it's not a
huge amount of code for what is a fairly substantial rework
of the attr logging and recovery algorithm....
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-12 08:12:56 +03:00
if ( ! xfs_inode_hasattr ( args - > dp ) )
goto out ;
2022-05-12 08:12:56 +03: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 08:12:52 +03:00
break ;
default :
ASSERT ( 0 ) ;
error = - EFSCORRUPTED ;
goto out ;
2022-05-09 12:09:07 +03:00
}
2022-05-11 10:01:23 +03:00
xfs_init_attr_trans ( args , & tres , & total ) ;
2022-05-09 12:09:07 +03:00
error = xfs_trans_alloc ( mp , & tres , total , 0 , XFS_TRANS_RESERVE , & tp ) ;
if ( error )
goto out ;
args - > trans = tp ;
done_item = xfs_trans_get_attrd ( tp , attrip ) ;
xfs_ilock ( ip , XFS_ILOCK_EXCL ) ;
xfs_trans_ijoin ( tp , ip , 0 ) ;
2022-05-12 08:12:56 +03:00
ret = xfs_xattri_finish_update ( attr , done_item ) ;
2022-05-09 12:09:07 +03:00
if ( ret = = - EAGAIN ) {
/* There's more work to do, so add it to this transaction */
xfs_defer_add ( tp , XFS_DEFER_OPS_TYPE_ATTR , & attr - > xattri_list ) ;
} else
error = ret ;
if ( error ) {
xfs_trans_cancel ( tp ) ;
goto out_unlock ;
}
error = xfs_defer_ops_capture_and_commit ( tp , capture_list ) ;
out_unlock :
2022-05-11 10:01:22 +03:00
if ( attr - > xattri_leaf_bp )
xfs_buf_relse ( attr - > xattri_leaf_bp ) ;
2022-05-09 12:09:07 +03:00
xfs_iunlock ( ip , XFS_ILOCK_EXCL ) ;
xfs_irele ( ip ) ;
out :
if ( ret ! = - EAGAIN )
2022-05-20 07:41:34 +03:00
xfs_attr_free_item ( attr ) ;
2022-05-09 12:09:07 +03:00
return error ;
}
/* Re-log an intent item to push the log tail forward. */
static struct xfs_log_item *
xfs_attri_item_relog (
struct xfs_log_item * intent ,
struct xfs_trans * tp )
{
struct xfs_attrd_log_item * attrdp ;
struct xfs_attri_log_item * old_attrip ;
struct xfs_attri_log_item * new_attrip ;
struct xfs_attri_log_format * new_attrp ;
struct xfs_attri_log_format * old_attrp ;
old_attrip = ATTRI_ITEM ( intent ) ;
old_attrp = & old_attrip - > attri_format ;
tp - > t_flags | = XFS_TRANS_DIRTY ;
attrdp = xfs_trans_get_attrd ( tp , old_attrip ) ;
set_bit ( XFS_LI_DIRTY , & attrdp - > attrd_item . li_flags ) ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03: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 12:09:07 +03: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 07:42:15 +03:00
new_attrp - > alfi_attr_filter = old_attrp - > alfi_attr_filter ;
2022-05-09 12:09:07 +03:00
xfs_trans_add_item ( tp , & new_attrip - > attri_item ) ;
set_bit ( XFS_LI_DIRTY , & new_attrip - > attri_item . li_flags ) ;
return & new_attrip - > attri_item ;
}
2022-05-04 05:41:02 +03:00
STATIC int
xlog_recover_attri_commit_pass2 (
struct xlog * log ,
struct list_head * buffer_list ,
struct xlog_recover_item * item ,
xfs_lsn_t lsn )
{
struct xfs_mount * mp = log - > l_mp ;
struct xfs_attri_log_item * attrip ;
struct xfs_attri_log_format * attri_formatp ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
struct xfs_attri_log_nameval * nv ;
const void * attr_value = NULL ;
2022-05-20 07:42:36 +03:00
const void * attr_name ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
int error ;
2022-05-04 05:41:02 +03:00
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
attri_formatp = item - > ri_buf [ 0 ] . i_addr ;
2022-05-20 07:42:36 +03:00
attr_name = item - > ri_buf [ 1 ] . i_addr ;
2022-05-04 05:41:02 +03:00
2022-05-20 07:42:36 +03:00
/* Validate xfs_attri_log_format before the large memory allocation */
2022-05-04 05:41:02 +03:00
if ( ! xfs_attri_validate ( mp , attri_formatp ) ) {
XFS_ERROR_REPORT ( __func__ , XFS_ERRLEVEL_LOW , mp ) ;
return - EFSCORRUPTED ;
}
2022-05-20 07:42:36 +03:00
if ( ! xfs_attr_namecheck ( attr_name , attri_formatp - > alfi_name_len ) ) {
XFS_ERROR_REPORT ( __func__ , XFS_ERRLEVEL_LOW , mp ) ;
return - EFSCORRUPTED ;
}
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
if ( attri_formatp - > alfi_value_len )
attr_value = item - > ri_buf [ 2 ] . i_addr ;
/*
* 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 ) ;
if ( ! nv )
2022-05-04 05:41:02 +03:00
return - ENOMEM ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
attrip = xfs_attri_init ( mp , nv ) ;
error = xfs_attri_copy_format ( & item - > ri_buf [ 0 ] , & attrip - > attri_format ) ;
2022-05-04 05:41:02 +03:00
if ( error )
goto out ;
/*
* The ATTRI has two references . One for the ATTRD and one for ATTRI to
* ensure it makes it into the AIL . Insert the ATTRI into the AIL
* directly and drop the ATTRI reference . Note that
* xfs_trans_ail_update ( ) drops the AIL lock .
*/
xfs_trans_ail_insert ( log - > l_ailp , & attrip - > attri_item , lsn ) ;
xfs_attri_release ( attrip ) ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
xfs_attri_log_nameval_put ( nv ) ;
2022-05-04 05:41:02 +03:00
return 0 ;
out :
xfs_attri_item_free ( attrip ) ;
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-23 01:43:46 +03:00
xfs_attri_log_nameval_put ( nv ) ;
2022-05-04 05:41:02 +03:00
return error ;
}
2022-05-09 12:09:07 +03:00
/*
* This routine is called to allocate an " attr free done " log item .
*/
static struct xfs_attrd_log_item *
xfs_trans_get_attrd ( struct xfs_trans * tp ,
struct xfs_attri_log_item * attrip )
{
struct xfs_attrd_log_item * attrdp ;
ASSERT ( tp ! = NULL ) ;
2022-05-11 10:03:23 +03:00
attrdp = kmem_cache_zalloc ( xfs_attrd_cache , GFP_NOFS | __GFP_NOFAIL ) ;
2022-05-09 12:09:07 +03:00
xfs_log_item_init ( tp - > t_mountp , & attrdp - > attrd_item , XFS_LI_ATTRD ,
& xfs_attrd_item_ops ) ;
attrdp - > attrd_attrip = attrip ;
attrdp - > attrd_format . alfd_alf_id = attrip - > attri_format . alfi_id ;
xfs_trans_add_item ( tp , & attrdp - > attrd_item ) ;
return attrdp ;
}
/* Get an ATTRD so we can process all the attrs. */
static struct xfs_log_item *
xfs_attr_create_done (
struct xfs_trans * tp ,
struct xfs_log_item * intent ,
unsigned int count )
{
if ( ! intent )
return NULL ;
return & xfs_trans_get_attrd ( tp , ATTRI_ITEM ( intent ) ) - > attrd_item ;
}
const struct xfs_defer_op_type xfs_attr_defer_type = {
. max_items = 1 ,
. create_intent = xfs_attr_create_intent ,
. abort_intent = xfs_attr_abort_intent ,
. create_done = xfs_attr_create_done ,
. finish_item = xfs_attr_finish_item ,
. cancel_item = xfs_attr_cancel_item ,
} ;
2022-05-04 05:41:02 +03:00
/*
* This routine is called when an ATTRD format structure is found in a committed
* transaction in the log . Its purpose is to cancel the corresponding ATTRI if
* it was still in the log . To do this it searches the AIL for the ATTRI with
* an id equal to that in the ATTRD format structure . If we find it we drop
* the ATTRD reference , which removes the ATTRI from the AIL and frees it .
*/
STATIC int
xlog_recover_attrd_commit_pass2 (
struct xlog * log ,
struct list_head * buffer_list ,
struct xlog_recover_item * item ,
xfs_lsn_t lsn )
{
struct xfs_attrd_log_format * attrd_formatp ;
attrd_formatp = item - > ri_buf [ 0 ] . i_addr ;
if ( item - > ri_buf [ 0 ] . i_len ! = sizeof ( struct xfs_attrd_log_format ) ) {
XFS_ERROR_REPORT ( __func__ , XFS_ERRLEVEL_LOW , NULL ) ;
return - EFSCORRUPTED ;
}
xlog_recover_release_intent ( log , XFS_LI_ATTRI ,
attrd_formatp - > alfd_alf_id ) ;
return 0 ;
}
static const struct xfs_item_ops xfs_attri_item_ops = {
. flags = XFS_ITEM_INTENT ,
. iop_size = xfs_attri_item_size ,
. iop_format = xfs_attri_item_format ,
. iop_unpin = xfs_attri_item_unpin ,
. iop_release = xfs_attri_item_release ,
2022-05-09 12:09:07 +03:00
. iop_recover = xfs_attri_item_recover ,
2022-05-04 05:41:02 +03:00
. iop_match = xfs_attri_item_match ,
2022-05-09 12:09:07 +03:00
. iop_relog = xfs_attri_item_relog ,
2022-05-04 05:41:02 +03:00
} ;
const struct xlog_recover_item_ops xlog_attri_item_ops = {
. item_type = XFS_LI_ATTRI ,
. commit_pass2 = xlog_recover_attri_commit_pass2 ,
} ;
static const struct xfs_item_ops xfs_attrd_item_ops = {
. flags = XFS_ITEM_RELEASE_WHEN_COMMITTED |
XFS_ITEM_INTENT_DONE ,
. iop_size = xfs_attrd_item_size ,
. iop_format = xfs_attrd_item_format ,
. iop_release = xfs_attrd_item_release ,
2022-05-09 12:09:07 +03:00
. iop_intent = xfs_attrd_item_intent ,
2022-05-04 05:41:02 +03:00
} ;
const struct xlog_recover_item_ops xlog_attrd_item_ops = {
. item_type = XFS_LI_ATTRD ,
. commit_pass2 = xlog_recover_attrd_commit_pass2 ,
} ;