deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-50548
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

media: i2c: hi846: Fix memory leak in hi846_parse_dt()

If any of the checks related to the supported link frequencies fail, then
the V4L2 fwnode resources don't get released before returning, which leads
to a memleak. Fix this by properly freeing the V4L2 fwnode data in a
designated label.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/[PII_REDACTED]412a8fa71960dbda81e122dafa70f7; https://git.kernel.org/stable/c/80113026d415e27483669db7a88b548d1ec3d3d1; https://git.kernel.org/stable/c/a05a9ae9ef3fffc9bc7ec2bc432a249a01155f6e
CVE: CVE-2022-50550
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

blk-iolatency: Fix memory leak on add_disk() failures

When a gendisk is successfully initialized but add_disk() fails such as when
a loop device has invalid number of minor device numbers specified,
blkcg_init_disk() is called during init and then blkcg_exit_disk() during
error handling. Unfortunately, iolatency gets initialized in the former but
doesn't get cleaned up in the latter.

This is because, in non-error cases, the cleanup is performed by
del_gendisk() calling rq_qos_exit(), the assumption being that rq_qos
policies, iolatency being one of them, can only be activated once the disk
is fully registered and visible. That assumption is true for wbt and iocost,
but not so for iolatency as it gets initialized before add_disk() is called.

It is desirable to lazy-init rq_qos policies because they are optional
features and add to hot path overhead once initialized - each IO has to walk
all the registered rq_qos policies. So, we want to switch iolatency to lazy
init too. However, that's a bigger change. As a fix for the immediate
problem, let's just add an extra call to rq_qos_exit() in blkcg_exit_disk().
This is safe because duplicate calls to rq_qos_exit() become noop's.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/215f9437dda09531bcb80605298a24219f01cec5; https://git.kernel.org/stable/c/2a126e1db5553ce4498290df019866952f858954; https://git.kernel.org/stable/c/813e693023ba10da9e75067780f8378465bf27cc
CVE: CVE-2022-50552
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

blk-mq: use quiesced elevator switch when reinitializing queues

The hctx's run_work may be racing with the elevator switch when
reinitializing hardware queues. The queue is merely frozen in this
context, but that only prevents requests from allocating and doesn't
stop the hctx work from running. The work may get an elevator pointer
that's being torn down, and can result in use-after-free errors and
kernel panics (example below). Use the quiesced elevator switch instead,
and make the previous one static since it is now only used locally.

  nvme nvme0: resetting controller
  nvme nvme0: 32/0/0 default/read/poll queues
  BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0
  Oops: 0000 [#1] SMP PTI
  Workqueue: kblockd blk_mq_run_work_fn
  RIP: 0010:kyber_has_work+0x29/0x70

...

  Call Trace:
   __blk_mq_do_dispatch_sched+0x83/0x2b0
   __blk_mq_sched_dispatch_requests+0x12e/0x170
   blk_mq_sched_dispatch_requests+0x30/0x60
   __blk_mq_run_hw_queue+0x2b/0x50
   process_one_work+0x1ef/0x380
   worker_thread+0x2d/0x3e0
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/63a681bcc32a43528ce0f690569f7f48e59c3963; https://git.kernel.org/stable/c/8237c01f1696bc53c470493bf1fe092a107648a6; https://git.kernel.org/stable/c/c478b3b2900f1834cf9eda5bfef0d[PII_REDACTED]d
CVE: CVE-2022-50554
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

blk-mq: avoid double ->queue_rq() because of early timeout

David Jeffery found one double ->queue_rq() issue, so far it can
be triggered in VM use case because of long vmexit latency or preempt
latency of vCPU pthread or long page fault in vCPU pthread, then block
IO req could be timed out before queuing the request to hardware but after
calling blk_mq_start_request() during ->queue_rq(), then timeout handler
may handle it by requeue, then double ->queue_rq() is caused, and kernel
panic.

So far, it is driver's responsibility to cover the race between timeout
and completion, so it seems supposed to be solved in driver in theory,
given driver has enough knowledge.

But it is really one common problem, lots of driver could have similar
issue, and could be hard to fix all affected drivers, even it isn't easy
for driver to handle the race. So David suggests this patch by draining
in-progress ->queue_rq() for solving this issue.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/7a73c54a[PII_REDACTED]ab586896736c9434e062a1; https://git.kernel.org/stable/c/82c229476b8f6afd7e09bc4dc77d89dc19ff7688; https://git.kernel.org/stable/c/8b3d6b029a552d2978bbac275303d11419826a69
CVE: CVE-2022-50555
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

tipc: fix a null-ptr-deref in tipc_topsrv_accept

syzbot found a crash in tipc_topsrv_accept:

  KASAN: null-ptr-deref in range [0x[PII_REDACTED]000008-0x[PII_REDACTED]00000f]
  Workqueue: tipc_rcv tipc_topsrv_accept
  RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487
  Call Trace:
   <TASK>
   tipc_topsrv_accept+0x197/0x280 net/tipc/topsrv.c:460
   process_one_work+0x991/0x1610 kernel/workqueue.c:2289
   worker_thread+0x665/0x1080 kernel/workqueue.c:2436
   kthread+0x2e4/0x3a0 kernel/kthread.c:376
   ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306

It was caused by srv->listener that might be set to null by
tipc_topsrv_stop() in net .exit whereas it's still used in
tipc_topsrv_accept() worker.

srv->listener is protected by srv->idr_lock in tipc_topsrv_stop(), so add
a check for srv->listener under srv->idr_lock in tipc_topsrv_accept() to
avoid the null-ptr-deref. To ensure the lsock is not released during the
tipc_topsrv_accept(), move sock_release() after tipc_topsrv_work_stop()
where it's waiting until the tipc_topsrv_accept worker to be done.

Note that sk_callback_lock is used to protect sk->sk_user_data instead of
srv->listener, and it should check srv in tipc_topsrv_listener_data_ready()
instead. This also ensures that no more tipc_topsrv_accept worker will be
started after tipc_conn_close() is called in tipc_topsrv_stop() where it
sets sk->sk_user_data to null.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/24b129aed8730e48f47d852d58d76825ab6f407c; https://git.kernel.org/stable/c/32a3d4660b34ce49ac0162338ebe362098e2f5df; https://git.kernel.org/stable/c/7a939503fc32bff4ed60800b73ff7fbb4aea2142
CVE: CVE-2023-53617
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

soc: aspeed: socinfo: Add kfree for kstrdup

Add kfree() in the later error handling in order to avoid memory leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/6e6d847a8ce18ab2fbec4f579f682486a82d2c6b; https://git.kernel.org/stable/c/b662856b71343d9e731c1cd4bbe54758c7791abb; https://git.kernel.org/stable/c/d9a5ad4477d2a11e9b03f00c52694451e9332228
CVE: CVE-2023-53618
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

btrfs: reject invalid reloc tree root keys with stack dump

[BUG]
Syzbot reported a crash that an ASSERT() got triggered inside
prepare_to_merge().

That ASSERT() makes sure the reloc tree is properly pointed back by its
subvolume tree.

[CAUSE]
After more debugging output, it turns out we had an invalid reloc tree:

  BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17

Note the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM,
QUOTA_TREE_OBJECTID), meaning it's a reloc tree for quota tree.

But reloc trees can only exist for subvolumes, as for non-subvolume
trees, we just COW the involved tree block, no need to create a reloc
tree since those tree blocks won't be shared with other trees.

Only subvolumes tree can share tree blocks with other trees (thus they
have BTRFS_ROOT_SHAREABLE flag).

Thus this new debug output proves my previous assumption that corrupted
on-disk data can trigger that ASSERT().

[FIX]
Besides the dedicated fix and the graceful exit, also let tree-checker to
check such root keys, to make sure reloc trees can only exist for subvolumes.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/314135b7bae9618a317874ae195272682cf2d5d4; https://git.kernel.org/stable/c/3ae93b316ca4b8b3c33798ef1d210355f2fb9318; https://git.kernel.org/stable/c/6ebcd021c92b8e4b904552e4d[PII_REDACTED]0796d
CVE: CVE-2023-53619
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: conntrack: Avoid nf_ct_helper_hash uses after free

If nf_conntrack_init_start() fails (for example due to a
register_nf_conntrack_bpf() failure), the nf_conntrack_helper_fini()
clean-up path frees the nf_ct_helper_hash map.

When built with NF_CONNTRACK=y, further netfilter modules (e.g:
netfilter_conntrack_ftp) can still be loaded and call
nf_conntrack_helpers_register(), independently of whether nf_conntrack
initialized correctly. This accesses the nf_ct_helper_hash dangling
pointer and causes a uaf, possibly leading to random memory corruption.

This patch guards nf_conntrack_helper_register() from accessing a freed
or uninitialized nf_ct_helper_hash pointer and fixes possible
uses-after-free when loading a conntrack module.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/00716f25f9697d02a0d9bd622575c7c7321ba3d0; https://git.kernel.org/stable/c/05561f822f27b9fa88fa5504ddec34bf38833034; https://git.kernel.org/stable/c/4ee69c91cb8f9ca144bc0861969e5a1a3c6152a7
CVE: CVE-2023-53620
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

md: fix soft lockup in status_resync

status_resync() will calculate 'curr_resync - recovery_active' to show
user a progress bar like following:

[============>........]  resync = 61.4%

'curr_resync' and 'recovery_active' is updated in md_do_sync(), and
status_resync() can read them concurrently, hence it's possible that
'curr_resync - recovery_active' can overflow to a huge number. In this
case status_resync() will be stuck in the loop to print a large amount
of '=', which will end up soft lockup.

Fix the problem by setting 'resync' to MD_RESYNC_ACTIVE in this case,
this way resync in progress will be reported to user.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/23309704e90859af2662bedc44101e6d1d2ece7e; https://git.kernel.org/stable/c/6efddf1e32e2a264694766ca485a4f5e04ee82a7; https://git.kernel.org/stable/c/b4acb6c3ede88d6b7d33742a09e63cfce5e7fb69
CVE: CVE-2023-53622
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

gfs2: Fix possible data races in gfs2_show_options()

Some fields such as gt_logd_secs of the struct gfs2_tune are accessed
without holding the lock gt_spin in gfs2_show_options():

  val = sdp->sd_tune.gt_logd_secs;
  if (val != 30)
    seq_printf(s, ",commit=%d", val);

And thus can cause data races when gfs2_show_options() and other functions
such as gfs2_reconfigure() are concurrently executed:

  spin_lock(&gt->gt_spin);
  gt->gt_logd_secs = newargs->ar_commit;

To fix these possible data races, the lock sdp->sd_tune.gt_spin is
acquired before accessing the fields of gfs2_tune and released after these
accesses.

Further changes by Andreas:

- Don't hold the spin lock over the seq_printf operations.
CVSS Score: 7.0 (HIGH)
CWE: CWE-362
References: https://git.kernel.org/stable/c/235a5ae73cea29109a3e06f100493f17857e6a93; https://git.kernel.org/stable/c/42077d4de49e4d9c773c97c42d5383b4899a8f9d; https://git.kernel.org/stable/c/6fa0a72cbbe45db4ed967a51f9e6f4e3afe61d20
CVE: CVE-2023-53624
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

net/sched: sch_fq: fix integer overflow of "credit"

if sch_fq is configured with "initial quantum" having values greater than
INT_MAX, the first assignment of "credit" does signed integer overflow to
a very negative value.
In this situation, the syzkaller script provided by Cristoph triggers the
CPU soft-lockup warning even with few sockets. It's not an infinite loop,
but "credit" wasn't probably meant to be minus 2Gb for each new flow.
Capping "initial quantum" to INT_MAX proved to fix the issue.

v2: validation of "initial quantum" is done in fq_policy, instead of open
    coding in fq_change() _ suggested by Jakub Kicinski
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-190
References: https://git.kernel.org/stable/c/2322462d6f9ad4874f4e3c63df3b5cc00cb1acbd; https://git.kernel.org/stable/c/4b8a05e3801661a0438fcd0cdef181030d966a5a; https://git.kernel.org/stable/c/4fbefeab88c6e79753a25099d455d3d59d2946b4
CVE: CVE-2023-53626
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: fix possible double unlock when moving a directory
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/020166bc6669ca9fb267ebd96bd88c4fb64a5d46; https://git.kernel.org/stable/c/1c93c42c7bb23057bde8a0a2ab834927ff64d20c; https://git.kernel.org/stable/c/43ce288ab5d7274a4a141d7f5e3ed2ab7b41f8a2
CVE: CVE-2023-53628
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: drop gfx_v11_0_cp_ecc_error_irq_funcs

The gfx.cp_ecc_error_irq is retired in gfx11. In gfx_v11_0_hw_fini still
use amdgpu_irq_put to disable this interrupt, which caused the call trace
in this function.

[  102.873958] Call Trace:
[  102.873959]  <TASK>
[  102.873961]  gfx_v11_0_hw_fini+0x23/0x1e0 [amdgpu]
[  102.874019]  gfx_v11_0_suspend+0xe/0x20 [amdgpu]
[  102.874072]  amdgpu_device_ip_suspend_phase2+0x240/0x460 [amdgpu]
[  102.874122]  amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu]
[  102.874172]  amdgpu_device_pre_asic_reset+0xd9/0x490 [amdgpu]
[  102.874223]  amdgpu_device_gpu_recover.cold+0x548/0xce6 [amdgpu]
[  102.874321]  amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu]
[  102.874375]  process_one_work+0x21f/0x3f0
[  102.874377]  worker_thread+0x200/0x3e0
[  102.874378]  ? process_one_work+0x3f0/0x3f0
[  102.874379]  kthread+0xfd/0x130
[  102.874380]  ? kthread_complete_and_exit+0x20/0x20
[  102.874381]  ret_from_fork+0x22/0x30

v2:
- Handle umc and gfx ras cases in separated patch
- Retired the gfx_v11_0_cp_ecc_error_irq_funcs in gfx11

v3:
- Improve the subject and code comments
- Add judgment on gfx11 in the function of amdgpu_gfx_ras_late_init

v4:
- Drop the define of CP_ME1_PIPE_INST_ADDR_INTERVAL and
SET_ECC_ME_PIPE_STATE which using in gfx_v11_0_set_cp_ecc_error_state
- Check cp_ecc_error_irq.funcs rather than ip version for a more
sustainable life

v5:
- Simplify judgment conditions
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/31b07aec4a2bdcab00770ea3a18efe49734ce153; https://git.kernel.org/stable/c/720b47229a5b24061d1c2e29ddb6043a59178d79
CVE: CVE-2023-53630
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

iommufd: Fix unpinning of pages when an access is present

syzkaller found that the calculation of batch_last_index should use
'start_index' since at input to this function the batch is either empty or
it has already been adjusted to cross any accesses so it will start at the
point we are unmapping from.

Getting this wrong causes the unmap to run over the end of the pages
which corrupts pages that were never mapped. In most cases this triggers
the num pinned debugging:

  WARNING: CPU: 0 PID: 557 at drivers/iommu/iommufd/pages.c:294 __iopt_area_unfill_domain+0x152/0x560
  Modules linked in:
  CPU: 0 PID: 557 Comm: repro Not tainted 6.3.0-rc2-eeac8ede1755 #1
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
  RIP: 0010:__iopt_area_unfill_domain+0x152/0x560
  Code: d2 0f ff 44 8b 64 24 54 48 8b 44 24 48 31 ff 44 89 e6 48 89 44 24 38 e8 fc d3 0f ff 45 85 e4 0f 85 eb 01 00 00 e8 0e d2 0f ff <0f> 0b e8 07 d2 0f ff 48 8b 44 24 38 89 5c 24 58 89 18 8b 44 24 54
  RSP: 0018:ffffc9000108baf0 EFLAGS: 00010246
  RAX: [PII_REDACTED] RBX: 00000000ffffffff RCX: ffffffff821e3f85
  RDX: [PII_REDACTED] RSI: ffff88800faf0000 RDI: [PII_REDACTED]
  RBP: ffffc9000108bd18 R08:[PII_REDACTED]03ca25 R09: [PII_REDACTED]
  R10:[PII_REDACTED]03ca00 R11: [PII_REDACTED] R12: [PII_REDACTED]
  R13: [PII_REDACTED] R14:[PII_REDACTED]0007ff R15: [PII_REDACTED]
  FS:  00007f3499ce1740(0000) GS:ffff88807dc00000(0000) knlGS:[PII_REDACTED]
  CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
  CR2: [PII_REDACTED] CR3:[PII_REDACTED]9c2001 CR4:[PII_REDACTED]770ef0
  PKRU: 55555554
  Call Trace:
   <TASK>
   iopt_area_unfill_domain+0x32/0x40
   iopt_table_remove_domain+0x23f/0x4c0
   iommufd_device_selftest_detach+0x3a/0x90
   iommufd_selftest_destroy+0x55/0x70
   iommufd_object_destroy_user+0xce/0x130
   iommufd_destroy+0xa2/0xc0
   iommufd_fops_ioctl+0x206/0x330
   __x64_sys_ioctl+0x10e/0x160
   do_syscall_64+0x3b/0x90
   entry_SYSCALL_64_after_hwframe+0x72/0xdc

Also add some useful WARN_ON sanity checks.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/70726ce4d898db57bfc4ae30ecd7da63b0dd0aa4; https://git.kernel.org/stable/c/727c28c1cef2bc013d2c8bb6c50e410a3882a04e
CVE: CVE-2023-53631
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

platform/x86: dell-sysman: Fix reference leak

If a duplicate attribute is found using kset_find_obj(),
a reference to that attribute is returned. This means
that we need to dispose it accordingly. Use kobject_put()
to dispose the duplicate attribute in such a case.

Compile-tested only.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/6ced15ff[PII_REDACTED]f1407fe722911a45a7874d; https://git.kernel.org/stable/c/7295a996fdab7bf83dc3d4078fa8b139b8e0a1bf; https://git.kernel.org/stable/c/9d9e03bec[PII_REDACTED]6580e7d6ec427241d859
CVE: CVE-2023-53633
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

accel/qaic: Fix a leak in map_user_pages()

If get_user_pages_fast() allocates some pages but not as many as we
wanted, then the current code leaks those pages.  Call put_page() on
the pages before returning.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/73274c33d961f4aa0f968f763e2c9f4210b4f4a3; https://git.kernel.org/stable/c/cdcba752a3d48fbe6f05cf2c91ab9497c8daad0c
CVE: CVE-2023-53634
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, arm64: Fixed a BTI error on returning to patched function

When BPF_TRAMP_F_CALL_ORIG is set, BPF trampoline uses BLR to jump
back to the instruction next to call site to call the patched function.
For BTI-enabled kernel, the instruction next to call site is usually
PACIASP, in this case, it's safe to jump back with BLR. But when
the call site is not followed by a PACIASP or bti, a BTI exception
is triggered.

Here is a fault log:

 Unhandled 64-bit el1h sync exception on CPU0, ESR 0x[PII_REDACTED]000002 -- BTI
 CPU: 0 PID: 263 Comm: test_progs Tainted: GF
 Hardware name: linux,dummy-virt (DT)
 pstate: 40400805 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=-c)
 pc : bpf_fentry_test1+0xc/0x30
 lr : bpf_trampoline_[PII_REDACTED]_0+0x48/0x1000
 sp : ffff80000c0c3a50
 x29: ffff80000c0c3a90 x28: ffff0000c2e6c080 x27: [PII_REDACTED]
 x26: [PII_REDACTED] x25: [PII_REDACTED] x24: [PII_REDACTED]
 x23: [PII_REDACTED] x22: 0000ffffcfd2a7f0 x21:[PII_REDACTED]00000a
 x20: 0000ffffcfd2a7f0 x19: [PII_REDACTED] x18: [PII_REDACTED]
 x17: [PII_REDACTED] x16: [PII_REDACTED] x15: 0000ffffcfd2a7f0
 x14: [PII_REDACTED] x13: [PII_REDACTED] x12: [PII_REDACTED]
 x11: [PII_REDACTED] x10: ffff80000914f5e4 x9 : ffff8000082a1528
 x8 : [PII_REDACTED] x7 : [PII_REDACTED] x6 : [PII_REDACTED]
 x5 : [PII_REDACTED] x4 : 00000000fffffff2 x3 : [PII_REDACTED]
 x2 : ffff8001f4b82000 x1 : [PII_REDACTED] x0 : [PII_REDACTED]
 Kernel panic - not syncing: Unhandled exception
 CPU: 0 PID: 263 Comm: test_progs Tainted: GF
 Hardware name: linux,dummy-virt (DT)
 Call trace:
  dump_backtrace+0xec/0x144
  show_stack+0x24/0x7c
  dump_stack_lvl+0x8c/0xb8
  dump_stack+0x18/0x34
  panic+0x1cc/0x3ec
  __el0_error_handler_common+0x0/0x130
  el1h_64_sync_handler+0x60/0xd0
  el1h_64_sync+0x78/0x7c
  bpf_fentry_test1+0xc/0x30
  bpf_fentry_test1+0xc/0x30
  bpf_prog_test_run_tracing+0xdc/0x2a0
  __sys_bpf+0x438/0x22a0
  __arm64_sys_bpf+0x30/0x54
  invoke_syscall+0x78/0x110
  el0_svc_common.constprop.0+0x6c/0x1d0
  do_el0_svc+0x38/0xe0
  el0_svc+0x30/0xd0
  el0t_64_sync_handler+0x1ac/0x1b0
  el0t_64_sync+0x1a0/0x1a4
 Kernel Offset: disabled
 CPU features: 0x0000,00034c24,f994fdab
 Memory Limit: none

And the instruction next to call site of bpf_fentry_test1 is ADD,
not PACIASP:

<bpf_fentry_test1>:
	bti     c
	nop
	nop
	add     w0, w0, #0x1
	paciasp

For BPF prog, JIT always puts a PACIASP after call site for BTI-enabled
kernel, so there is no problem. To fix it, replace BLR with RET to bypass
the branch target check.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/738a96c4a8c36950803fdd27e7c30aca92dccefd; https://git.kernel.org/stable/c/8b9c64942ada229f52fe6f1b537a50f88b3c2673; https://git.kernel.org/stable/c/eabc166919d169e[PII_REDACTED]1f52b0351e431a
CVE: CVE-2023-53635
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: conntrack: fix wrong ct->timeout value

(struct nf_conn)->timeout is an interval before the conntrack
confirmed.  After confirmed, it becomes a timestamp.

It is observed that timeout of an unconfirmed conntrack:
- Set by calling ctnetlink_change_timeout(). As a result,
  `nfct_time_stamp` was wrongly added to `ct->timeout` twice.
- Get by calling ctnetlink_dump_timeout(). As a result,
  `nfct_time_stamp` was wrongly subtracted.

Call Trace:
 <TASK>
 dump_stack_lvl
 ctnetlink_dump_timeout
 __ctnetlink_glue_build
 ctnetlink_glue_build
 __nfqnl_enqueue_packet
 nf_queue
 nf_hook_slow
 ip_mc_output
 ? __pfx_ip_finish_output
 ip_send_skb
 ? __pfx_dst_output
 udp_send_skb
 udp_sendmsg
 ? __pfx_ip_generic_getfrag
 sock_sendmsg

Separate the 2 cases in:
- Setting `ct->timeout` in __nf_ct_set_timeout().
- Getting `ct->timeout` in ctnetlink_dump_timeout().

Pablo appends:

Update ctnetlink to set up the timeout _after_ the IPS_CONFIRMED flag is
set on, otherwise conntrack creation via ctnetlink breaks.

Note that the problem described in this patch occurs since the
introduction of the nfnetlink_queue conntrack support, select a
sufficiently old Fixes: tag for -stable kernel to pick up this fix.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/73db1b8f2bb6725b7391e85aab41fdf592b3c0c1; https://git.kernel.org/stable/c/80c5ba0078e20d926d11d0778f9a43902664ebf0; https://git.kernel.org/stable/c/f612ae1ab4793701caf39386fb3b7f4b3ef44e48