2022-05-03 19:41:02 -07:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-or-later
|
|
|
|
*
|
|
|
|
* Copyright (C) 2022 Oracle. All Rights Reserved.
|
|
|
|
* Author: Allison Henderson <allison.henderson@oracle.com>
|
|
|
|
*/
|
|
|
|
#ifndef __XFS_ATTR_ITEM_H__
|
|
|
|
#define __XFS_ATTR_ITEM_H__
|
|
|
|
|
|
|
|
/* kernel only ATTRI/ATTRD definitions */
|
|
|
|
|
|
|
|
struct xfs_mount;
|
|
|
|
struct kmem_zone;
|
|
|
|
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-22 15:43:46 -07:00
|
|
|
struct xfs_attri_log_nameval {
|
|
|
|
struct xfs_log_iovec name;
|
2024-04-22 09:47:42 -07:00
|
|
|
struct xfs_log_iovec new_name; /* PPTR_REPLACE only */
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-22 15:43:46 -07:00
|
|
|
struct xfs_log_iovec value;
|
2024-04-22 09:47:42 -07:00
|
|
|
struct xfs_log_iovec new_value; /* PPTR_REPLACE only */
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-22 15:43:46 -07:00
|
|
|
refcount_t refcount;
|
|
|
|
|
|
|
|
/* name and value follow the end of this struct */
|
|
|
|
};
|
|
|
|
|
2022-05-03 19:41:02 -07:00
|
|
|
/*
|
|
|
|
* This is the "attr intention" log item. It is used to log the fact that some
|
|
|
|
* extended attribute operations need to be processed. An operation is
|
|
|
|
* currently either a set or remove. Set or remove operations are described by
|
2022-05-21 23:00:26 -07:00
|
|
|
* the xfs_attr_intent which may be logged to this intent.
|
2022-05-03 19:41:02 -07:00
|
|
|
*
|
|
|
|
* During a normal attr operation, name and value point to the name and value
|
|
|
|
* fields of the caller's xfs_da_args structure. During a recovery, the name
|
|
|
|
* and value buffers are copied from the log, and stored in a trailing buffer
|
2022-05-21 23:00:26 -07:00
|
|
|
* attached to the xfs_attr_intent until they are committed. They are freed
|
|
|
|
* when the xfs_attr_intent itself is freed when the work is done.
|
2022-05-03 19:41:02 -07:00
|
|
|
*/
|
|
|
|
struct xfs_attri_log_item {
|
|
|
|
struct xfs_log_item attri_item;
|
|
|
|
atomic_t attri_refcount;
|
xfs: share xattr name and value buffers when logging xattr updates
While running xfs/297 and generic/642, I noticed a crash in
xfs_attri_item_relog when it tries to copy the attr name to the new
xattri log item. I think what happened here was that we called
->iop_commit on the old attri item (which nulls out the pointers) as
part of a log force at the same time that a chained attr operation was
ongoing. The system was busy enough that at some later point, the defer
ops operation decided it was necessary to relog the attri log item, but
as we've detached the name buffer from the old attri log item, we can't
copy it to the new one, and kaboom.
I think there's a broader refcounting problem with LARP mode -- the
setxattr code can return to userspace before the CIL actually formats
and commits the log item, which results in a UAF bug. Therefore, the
xattr log item needs to be able to retain a reference to the name and
value buffers until the log items have completely cleared the log.
Furthermore, each time we create an intent log item, we allocate new
memory and (re)copy the contents; sharing here would be very useful.
Solve the UAF and the unnecessary memory allocations by having the log
code create a single refcounted buffer to contain the name and value
contents. This buffer can be passed from old to new during a relog
operation, and the logging code can (optionally) attach it to the
xfs_attr_item for reuse when LARP mode is enabled.
This also fixes a problem where the xfs_attri_log_item objects weren't
being freed back to the same cache where they came from.
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2022-05-22 15:43:46 -07:00
|
|
|
struct xfs_attri_log_nameval *attri_nameval;
|
2022-05-03 19:41:02 -07:00
|
|
|
struct xfs_attri_log_format attri_format;
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is the "attr done" log item. It is used to log the fact that some attrs
|
|
|
|
* earlier mentioned in an attri item have been freed.
|
|
|
|
*/
|
|
|
|
struct xfs_attrd_log_item {
|
|
|
|
struct xfs_log_item attrd_item;
|
|
|
|
struct xfs_attri_log_item *attrd_attrip;
|
|
|
|
struct xfs_attrd_log_format attrd_format;
|
|
|
|
};
|
|
|
|
|
2022-05-21 22:59:48 -07:00
|
|
|
extern struct kmem_cache *xfs_attri_cache;
|
|
|
|
extern struct kmem_cache *xfs_attrd_cache;
|
|
|
|
|
2024-04-22 09:47:37 -07:00
|
|
|
enum xfs_attr_defer_op {
|
|
|
|
XFS_ATTR_DEFER_SET,
|
|
|
|
XFS_ATTR_DEFER_REMOVE,
|
|
|
|
XFS_ATTR_DEFER_REPLACE,
|
|
|
|
};
|
|
|
|
|
|
|
|
void xfs_attr_defer_add(struct xfs_da_args *args, enum xfs_attr_defer_op op);
|
|
|
|
|
2022-05-03 19:41:02 -07:00
|
|
|
#endif /* __XFS_ATTR_ITEM_H__ */
|