deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-49936
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net/xen-netback: prevent UAF in xenvif_flush_hash()

During the list_for_each_entry_rcu iteration call of xenvif_flush_hash,
kfree_rcu does not exist inside the rcu read critical section, so if
kfree_rcu is called when the rcu grace period ends during the iteration,
UAF occurs when accessing head->next after the entry becomes free.

Therefore, to solve this, you need to change it to list_for_each_entry_safe.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0fa5e94a1811d68fbffa0725efe6d4ca62c03d12; https://git.kernel.org/stable/c/143edf098b80669d05245b2f2367dd156a83a2c5; https://git.kernel.org/stable/c/3c4423b0c4b98213b3438e15061e1d08220e6982
CVE: CVE-2024-49937
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: Set correct chandef when starting CAC

When starting CAC in a mode other than AP mode, it return a
"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]"
caused by the chandef.chan being null at the end of CAC.

Solution: Ensure the channel definition is set for the different modes
when starting CAC to avoid getting a NULL 'chan' at the end of CAC.

 Call Trace:
  ? show_regs.part.0+0x14/0x16
  ? __warn+0x67/0xc0
  ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]
  ? report_bug+0xa7/0x130
  ? exc_overflow+0x30/0x30
  ? handle_bug+0x27/0x50
  ? exc_invalid_op+0x18/0x60
  ? handle_exception+0xf6/0xf6
  ? exc_overflow+0x30/0x30
  ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]
  ? exc_overflow+0x30/0x30
  ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]
  ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211]
  ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211]
  ? process_one_work+0x165/0x280
  ? worker_thread+0x120/0x3f0
  ? kthread+0xc2/0xf0
  ? process_one_work+0x280/0x280
  ? kthread_complete_and_exit+0x20/0x20
  ? ret_from_fork+0x19/0x24

[shorten subject, remove OCB, reorder cases to match previous list]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/04053e55dd50741cf6c59b9bbaa4238218c05c70; https://git.kernel.org/stable/c/[PII_REDACTED]0396e44ce80aaeec2d93d182035651; https://git.kernel.org/stable/c/95f32191e50b75e0f75fae1bb925cdf51d8df0a3
CVE: CVE-2024-49938
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit

Syzbot points out that skb_trim() has a sanity check on the existing length of
the skb, which can be uninitialised in some error paths. The intent here is
clearly just to reset the length to zero before resubmitting, so switch to
calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length()
already contains a call to skb_reset_tail_pointer(), so remove the redundant
call.

The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar
usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-824
References: https://git.kernel.org/stable/c/012ae530afa[PII_REDACTED]de452745d33c99a321b; https://git.kernel.org/stable/c/2c230210ec0ae6ed08306ac70dc21c24b817bb95; https://git.kernel.org/stable/c/6a[PII_REDACTED]75d9247e576c15dc29823100a4e4
CVE: CVE-2024-49940
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

l2tp: prevent possible tunnel refcount underflow

When a session is created, it sets a backpointer to its tunnel. When
the session refcount drops to 0, l2tp_session_free drops the tunnel
refcount if session->tunnel is non-NULL. However, session->tunnel is
set in l2tp_session_create, before the tunnel refcount is incremented
by l2tp_session_register, which leaves a small window where
session->tunnel is non-NULL when the tunnel refcount hasn't been
bumped.

Moving the assignment to l2tp_session_register is trivial but
l2tp_session_create calls l2tp_session_set_header_len which uses
session->tunnel to get the tunnel's encap. Add an encap arg to
l2tp_session_set_header_len to avoid using session->tunnel.

If l2tpv3 sessions have colliding IDs, it is possible for
l2tp_v3_session_get to race with l2tp_session_register and fetch a
session which doesn't yet have session->tunnel set. Add a check for
this case.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/24256415d18695b46da06c93135f5b51c548b950; https://git.kernel.org/stable/c/f7415e60c25a6108cd7955a20b2e66b6251ffe02
CVE: CVE-2024-49941
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

gpiolib: Fix potential NULL pointer dereference in gpiod_get_label()

In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may
return a NULL pointer, leading to a scenario where `label->str` is accessed
without verifying if `label` itself is NULL.

This patch adds a proper NULL check for `label` before accessing
`label->str`. The check for `label->str != NULL` is removed because
`label->str` can never be NULL if `label` is not NULL.

This fixes the issue where the label name was being printed as `(efault)`
when dumping the sysfs GPIO file when `label == NULL`.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/7b99b5ab885993bff010ebcd93be5e511c56e28a; https://git.kernel.org/stable/c/9ee4b907d7a5d7a53b4ff7727c371ff3d44ccbbb
CVE: CVE-2024-49943
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe/guc_submit: add missing locking in wedged_fini

Any non-wedged queue can have a zero refcount here and can be running
concurrently with an async queue destroy, therefore dereferencing the
queue ptr to check wedge status after the lookup can trigger UAF if
queue is not wedged.  Fix this by keeping the submission_state lock held
around the check to postpone the free and make the check safe, before
dropping again around the put() to avoid the deadlock.

(cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/790533e44bfc7af929842fccd9674c9f424d4627; https://git.kernel.org/stable/c/d88f9bab7e62dd0dbe983fa70cf040042a60cc84
CVE: CVE-2024-49944
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start

In sctp_listen_start() invoked by sctp_inet_listen(), it should set the
sk_state back to CLOSED if sctp_autobind() fails due to whatever reason.

Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse
is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will
be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash
is NULL.

  KASAN: null-ptr-deref in range [0x[PII_REDACTED]000000-0x[PII_REDACTED]000007]
  RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617
  Call Trace:
   <TASK>
   __sys_listen_socket net/socket.c:1883 [inline]
   __sys_listen+0x1b7/0x230 net/socket.c:1894
   __do_sys_listen net/socket.c:1902 [inline]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0e4e2e60556c6ed00e8450b720f106a268d23062; https://git.kernel.org/stable/c/7f64cb5b4d8c872296eda0fdce3bcf099eec7aa7; https://git.kernel.org/stable/c/89bbead9d897c77d0b566349c8643030ff2abeba
CVE: CVE-2024-49945
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net/ncsi: Disable the ncsi work before freeing the associated structure

The work function can run after the ncsi device is freed, resulting
in use-after-free bugs or kernel panic.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/a0ffa68c70b367358b2672cdab6fa5bc4c40de2c; https://git.kernel.org/stable/c/dd41dab62f32d9e9e0669af8459d12a93834b238; https://git.kernel.org/stable/c/f6ca[PII_REDACTED]8181f43150b3553f2bafd71e42
CVE: CVE-2024-49948
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net: add more sanity checks to qdisc_pkt_len_init()

One path takes care of SKB_GSO_DODGY, assuming
skb->len is bigger than hdr_len.

virtio_net_hdr_to_skb() does not fully dissect TCP headers,
it only make sure it is at least 20 bytes.

It is possible for an user to provide a malicious 'GSO' packet,
total length of 80 bytes.

- 20 bytes of IPv4 header
- 60 bytes TCP header
- a small gso_size like 8

virtio_net_hdr_to_skb() would declare this packet as a normal
GSO packet, because it would see 40 bytes of payload,
bigger than gso_size.

We need to make detect this case to not underflow
qdisc_skb_cb(skb)->pkt_len.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1eebe602a8d8264a12e35e39d0645fa88dbbacdd; https://git.kernel.org/stable/c/2415f465730e48b6e38da1c7c097317bf5dd2d20; https://git.kernel.org/stable/c/27a8fabc54d2f960d47bdfbebf2bdc6e8a92a4c4
CVE: CVE-2024-49951
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: MGMT: Fix possible crash on mgmt_index_removed

If mgmt_index_removed is called while there are commands queued on
cmd_sync it could lead to crashes like the bellow trace:

0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc
0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth]
0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth]
0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth]

So while handling mgmt_index_removed this attempts to dequeue
commands passed as user_data to cmd_sync.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0cc47233af35fb5f10b5e6a027cb4ccd480caf9a; https://git.kernel.org/stable/c/19b40ca62607cef78369549d1af091f2fd558931; https://git.kernel.org/stable/c/[PII_REDACTED]aa7e4863c6869b689afb6005633b23
CVE: CVE-2024-49952
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nf_tables: prevent nf_skb_duplicated corruption

syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write
per-cpu variable nf_skb_duplicated in an unsafe way [1].

Disabling preemption as hinted by the splat is not enough,
we have to disable soft interrupts as well.

[1]
BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316
 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87
CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call Trace:
 <TASK>
  __dump_stack lib/dump_stack.c:93 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
  check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49
  nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87
  nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30
  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]
  nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288
  nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23
  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]
  nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626
  nf_hook+0x2c4/0x450 include/linux/netfilter.h:269
  NF_HOOK_COND include/linux/netfilter.h:302 [inline]
  ip_output+0x185/0x230 net/ipv4/ip_output.c:433
  ip_local_out net/ipv4/ip_output.c:129 [inline]
  ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495
  udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981
  udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x1a6/0x270 net/socket.c:745
  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
  ___sys_sendmsg net/socket.c:2651 [inline]
  __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737
  __do_sys_sendmmsg net/socket.c:2766 [inline]
  __se_sys_sendmmsg net/socket.c:2763 [inline]
  __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f4ce4f7def9
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: [PII_REDACTED]
RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9
RDX: [PII_REDACTED] RSI:[PII_REDACTED]005d40 RDI: [PII_REDACTED]
RBP: 00007f4ce4ff0b76 R08: [PII_REDACTED] R09: [PII_REDACTED]
R10: [PII_REDACTED] R11: [PII_REDACTED] R12: [PII_REDACTED]
R13: [PII_REDACTED] R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68
 </TASK>
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/38e3fd0c4a2616052eb3c8f4e6f32d1ff47cd663; https://git.kernel.org/stable/c/4e3542f40f3a94efa59ea328e307c50601ed7065; https://git.kernel.org/stable/c/50067d8b3f48e4cd4c9e817d3e9a5b5ff3507ca7
CVE: CVE-2024-49953
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice

The km.state is not checked in driver's delayed work. When
xfrm_state_check_expire() is called, the state can be reset to
XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This
happens when xfrm state is deleted, but not freed yet. As
__xfrm_state_delete() is called again in xfrm timer, the following
crash occurs.

To fix this issue, skip xfrm_state_check_expire() if km.state is not
XFRM_STATE_VALID.

 Oops: general protection fault, probably for non-canonical address 0xdead[PII_REDACTED]08: 0000 [#1] SMP
 CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core]
 RIP: 0010:__xfrm_state_delete+0x3d/0x1b0
 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48
 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246
 RAX: dead[PII_REDACTED]22 RBX: ffffffff82afa940 RCX: [PII_REDACTED]
 RDX: dead[PII_REDACTED]00 RSI: [PII_REDACTED] RDI: ffffffff82afb980
 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: [PII_REDACTED]
 R10: [PII_REDACTED] R11: ffff88885f945ff8 R12: [PII_REDACTED]
 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400
 FS:  [PII_REDACTED](0000) GS:ffff88885f940000(0000) knlGS:[PII_REDACTED]
 CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
 CR2: 00007f[PII_REDACTED] CR3:[PII_REDACTED]8d6001 CR4:[PII_REDACTED]370eb0
 DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
 DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
 Call Trace:
  <IRQ>
  ? die_addr+0x33/0x90
  ? exc_general_protection+0x1a2/0x390
  ? asm_exc_general_protection+0x22/0x30
  ? __xfrm_state_delete+0x3d/0x1b0
  ? __xfrm_state_delete+0x2f/0x1b0
  xfrm_timer_handler+0x174/0x350
  ? __xfrm_state_delete+0x1b0/0x1b0
  __hrtimer_run_queues+0x121/0x270
  hrtimer_run_softirq+0x88/0xd0
  handle_softirqs+0xcc/0x270
  do_softirq+0x3c/0x50
  </IRQ>
  <TASK>
  __local_bh_enable_ip+0x47/0x50
  mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core]
  process_one_work+0x137/0x2d0
  worker_thread+0x28d/0x3a0
  ? rescuer_thread+0x480/0x480
  kthread+0xb8/0xe0
  ? kthread_park+0x80/0x80
  ret_from_fork+0x2d/0x50
  ? kthread_park+0x80/0x80
  ret_from_fork_asm+0x11/0x20
  </TASK>
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-672
References: https://git.kernel.org/stable/c/0b[PII_REDACTED]df9ac9cedf856db9fc36d92c50ef; https://git.kernel.org/stable/c/151e7dead1f5399a73c19c4b50307ea48aff1dc0; https://git.kernel.org/stable/c/7b124695db40d5c9c5295a94ae928a8d67a01c3d
CVE: CVE-2024-49954
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

static_call: Replace pointless WARN_ON() in static_call_module_notify()

static_call_module_notify() triggers a WARN_ON(), when memory allocation
fails in __static_call_add_module().

That's not really justified, because the failure case must be correctly
handled by the well known call chain and the error code is passed
through to the initiating userspace application.

A memory allocation fail is not a fatal problem, but the WARN_ON() takes
the machine out when panic_on_warn is set.

Replace it with a pr_warn().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/85a104aaef1f56623acc10ba4c42d5f046ba65b7; https://git.kernel.org/stable/c/b83bef74c121a3311240fc4002d23486b85355e4; https://git.kernel.org/stable/c/bc9356513d56b688775497b7ac6f2b967f46a80c
CVE: CVE-2024-49955
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPI: battery: Fix possible crash when unregistering a battery hook

When a battery hook returns an error when adding a new battery, then
the battery hook is automatically unregistered.
However the battery hook provider cannot know that, so it will later
call battery_hook_unregister() on the already unregistered battery
hook, resulting in a crash.

Fix this by using the list head to mark already unregistered battery
hooks as already being unregistered so that they can be ignored by
battery_hook_unregister().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-672
References: https://git.kernel.org/stable/c/07b98400cb0285a6348188aa8c5ec6a2ae0551f7; https://git.kernel.org/stable/c/76959aff14a0012ad6b984ec7686d163deccdc16; https://git.kernel.org/stable/c/76fb2cbf01571926da8ecf6876cc8cb07d3f5183
CVE: CVE-2024-49956
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

gfs2: fix double destroy_workqueue error

When gfs2_fill_super() fails, destroy_workqueue() is called within
gfs2_gl_hash_clear(), and the subsequent code path calls
destroy_workqueue() on the same work queue again.

This issue can be fixed by setting the work queue pointer to NULL after
the first destroy_workqueue() call and checking for a NULL pointer
before attempting to destroy the work queue again.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/6cb9df81a2c462b89d2f9611009ab43ae8717841; https://git.kernel.org/stable/c/a[PII_REDACTED]d77efd76306940d742a6f23debe68
CVE: CVE-2024-49957
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ocfs2: fix null-ptr-deref when journal load failed.

During the mounting process, if journal_reset() fails because of too short
journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. 
Subsequently, ocfs2_journal_shutdown() calls
jbd2_journal_flush()->jbd2_cleanup_journal_tail()->
__jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail()
->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer
dereference error.

To resolve this issue, we should check the JBD2_LOADED flag to ensure the
journal was properly loaded.  Additionally, use journal instead of
osb->journal directly to simplify the code.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/387bf565cc03e2e8c720b8b4798efea4aacb6962; https://git.kernel.org/stable/c/5784d9fcfd43bd853654bb80c87ef293b9e8e80a; https://git.kernel.org/stable/c/703b2c7e0798d263154dc8593dc2345f75dc077f
CVE: CVE-2024-49958
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ocfs2: reserve space for inline xattr before attaching reflink tree

One of our customers reported a crash and a corrupted ocfs2 filesystem. 
The crash was due to the detection of corruption.  Upon troubleshooting,
the fsck -fn output showed the below corruption

[EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,
but fsck believes the largest valid value is 227.  Clamp the next record value? n

The stat output from the debugfs.ocfs2 showed the following corruption
where the "Next Free Rec:" had overshot the "Count:" in the root metadata
block.

        Inode: 33080590   Mode: 0640   Generation:[PII_REDACTED] (0x9c25a856)
        FS Generation: 904309833 (0x35e6ac49)
        CRC32: 00000000   ECC: 0000
        Type: Regular   Attr: 0x0   Flags: Valid
        Dynamic Features: (0x16) HasXattr InlineXattr Refcounted
        Extended Attributes Block: 0  Extended Attributes Inline Size: 256
        User: 0 (root)   Group: 0 (root)   Size:[PII_REDACTED]88
        Links: 1   Clusters: 141738
        ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829[PII_REDACTED]
        atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133[PII_REDACTED]
        mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317[PII_REDACTED]
        dtime: 0x0 -- Wed Dec 31 17:00:00 1969
        Refcount Block: 2777346
        Last Extblk: 2886943   Orphan Slot: 0
        Sub Alloc Slot: 0   Sub Alloc Bit: 14
        Tree Depth: 1   Count: 227   Next Free Rec: 230
        ## Offset        Clusters       Block#
        0  0             2310           2776351
        1  2310          2139           2777375
        2  4449          1221           2778399
        3  5670          731            2779423
        4  6401          566            2780447
        .......          ....           .......
        .......          ....           .......

The issue was in the reflink workfow while reserving space for inline
xattr.  The problematic function is ocfs2_reflink_xattr_inline().  By the
time this function is called the reflink tree is already recreated at the
destination inode from the source inode.  At this point, this function
reserves space for inline xattrs at the destination inode without even
checking if there is space at the root metadata block.  It simply reduces
the l_count from 243 to 227 thereby making space of 256 bytes for inline
xattr whereas the inode already has extents beyond this index (in this
case up to 230), thereby causing corruption.

The fix for this is to reserve space for inline metadata at the destination
inode before the reflink tree gets recreated. The customer has verified the
fix.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/020f5c53c17f66c0a8f2d37dad27ace301b8d8a1; https://git.kernel.org/stable/c/5c2072f02c0d75802ec28ec703b7d43a0dd008b5; https://git.kernel.org/stable/c/5c9807c523b4fca81d3e8e864dabc8c806402121