deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2021-46982
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: compress: fix race condition of overwrite vs truncate

pos_fsstress testcase complains a panic as belew:

------------[ cut here ]------------
kernel BUG at fs/f2fs/compress.c:1082!
invalid opcode: 0000 [#1] SMP PTI
CPU: 4 PID: 2753477 Comm: kworker/u16:2 Tainted: G           OE     5.12.0-rc1-custom #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
Workqueue: writeback wb_workfn (flush-252:16)
RIP: 0010:prepare_compress_overwrite+0x4c0/0x760 [f2fs]
Call Trace:
 f2fs_prepare_compress_overwrite+0x5f/0x80 [f2fs]
 f2fs_write_cache_pages+0x468/0x8a0 [f2fs]
 f2fs_write_data_pages+0x2a4/0x2f0 [f2fs]
 do_writepages+0x38/0xc0
 __writeback_single_inode+0x44/0x2a0
 writeback_sb_inodes+0x223/0x4d0
 __writeback_inodes_wb+0x56/0xf0
 wb_writeback+0x1dd/0x290
 wb_workfn+0x309/0x500
 process_one_work+0x220/0x3c0
 worker_thread+0x53/0x420
 kthread+0x12f/0x150
 ret_from_fork+0x22/0x30

The root cause is truncate() may race with overwrite as below,
so that one reference count left in page can not guarantee the
page attaching in mapping tree all the time, after truncation,
later find_lock_page() may return NULL pointer.

- prepare_compress_overwrite
 - f2fs_pagecache_get_page
 - unlock_page
					- f2fs_setattr
					 - truncate_setsize
					  - truncate_inode_page
					   - delete_from_page_cache
 - find_lock_page

Fix this by avoiding referencing updated page.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/5639b73fd3bc6fc8ca72e3a9ac15aacaabd7ebff; https://git.kernel.org/stable/c/64acb100fe3beb5d20184d0ae3307235bd3555c4; https://git.kernel.org/stable/c/936158b15e2648253afb824d252c910c496d34b5
CVE: CVE-2021-46983
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

nvmet-rdma: Fix NULL deref when SEND is completed with error

When running some traffic and taking down the link on peer, a
retry counter exceeded error is received. This leads to
nvmet_rdma_error_comp which tried accessing the cq_context to
obtain the queue. The cq_context is no longer valid after the
fix to use shared CQ mechanism and should be obtained similar
to how it is obtained in other functions from the wc->qp.

[ 905.786331] nvmet_rdma: SEND for CQE 0x00000000e3337f90 failed with status transport retry counter exceeded (12).
[ 905.832048] BUG: unable to handle kernel NULL pointer dereference at [PII_REDACTED]
[ 905.839919] PGD 0 P4D 0
[ 905.842464] Oops: 0000 1 SMP NOPTI
[ 905.846144] CPU: 13 PID: 1557 Comm: kworker/13:1H Kdump: loaded Tainted: G OE --------- - - 4.18.0-304.el8.x86_64 #1
[ 905.872135] RIP: 0010:nvmet_rdma_error_comp+0x5/0x1b [nvmet_rdma]
[ 905.878259] Code: 19 4f c0 e8 89 b3 a5 f6 e9 5b e0 ff ff 0f b7 75 14 4c 89 ea 48 c7 c7 08 1a 4f c0 e8 71 b3 a5 f6 e9 4b e0 ff ff 0f 1f 44 00 00 <48> 8b 47 48 48 85 c0 74 08 48 89 c7 e9 98 bf 49 00 e9 c3 e3 ff ff
[ 905.897135] RSP: 0018:ffffab601c45fe28 EFLAGS: 00010246
[ 905.902387] RAX: [PII_REDACTED] RBX: ffff9e729ea2f800 RCX: [PII_REDACTED]
[ 905.909558] RDX: [PII_REDACTED] RSI: ffff9e72df9567c8 RDI: [PII_REDACTED]
[ 905.916731] RBP: ffff9e729ea2b400 R08:[PII_REDACTED]00074d R09: [PII_REDACTED]
[ 905.923903] R10: [PII_REDACTED] R11: ffffab601c45fcc0 R12: [PII_REDACTED]
[ 905.931074] R13: [PII_REDACTED] R14: [PII_REDACTED] R15: ffff9e729ea2f400
[ 905.938247] FS: [PII_REDACTED](0000) GS:ffff9e72df940000(0000) knlGS:[PII_REDACTED]
[ 905.938249] CS: 0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[ 905.950067] nvmet_rdma: SEND for CQE 0x00000000c7356cca failed with status transport retry counter exceeded (12).
[ 905.961855] CR2: [PII_REDACTED] CR3: 000000678d010004 CR4:[PII_REDACTED]7706e0
[ 905.961855] DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
[ 905.961856] DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
[ 905.961857] PKRU: 55555554
[ 906.010315] Call Trace:
[ 906.012778] __ib_process_cq+0x89/0x170 [ib_core]
[ 906.017509] ib_cq_poll_work+0x26/0x80 [ib_core]
[ 906.022152] process_one_work+0x1a7/0x360
[ 906.026182] ? create_worker+0x1a0/0x1a0
[ 906.030123] worker_thread+0x30/0x390
[ 906.033802] ? create_worker+0x1a0/0x1a0
[ 906.037744] kthread+0x116/0x130
[ 906.040988] ? kthread_flush_work_fn+0x10/0x10
[ 906.045456] ret_from_fork+0x1f/0x40
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/17fb6dfa5162b89ecfa07df891a53afec321abe8; https://git.kernel.org/stable/c/5bdb34466ad8370546dfa0497594fb1d6f2fed90; https://git.kernel.org/stable/c/64f3410c7bfc389b1a58611d0799f4a36ce4b6b5
CVE: CVE-2021-46984
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

kyber: fix out of bounds access when preempted

__blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and
passes the hctx to ->bio_merge(). kyber_bio_merge() then gets the ctx
for the current CPU again and uses that to get the corresponding Kyber
context in the passed hctx. However, the thread may be preempted between
the two calls to blk_mq_get_ctx(), and the ctx returned the second time
may no longer correspond to the passed hctx. This "works" accidentally
most of the time, but it can cause us to read garbage if the second ctx
came from an hctx with more ctx's than the first one (i.e., if
ctx->index_hw[hctx->type] > hctx->nr_ctx).

This manifested as this UBSAN array index out of bounds error reported
by Jakub:

UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9
index 13106 is out of range for type 'long unsigned int [128]'
Call Trace:
 dump_stack+0xa4/0xe5
 ubsan_epilogue+0x5/0x40
 __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34
 queued_spin_lock_slowpath+0x476/0x480
 do_raw_spin_lock+0x1c2/0x1d0
 kyber_bio_merge+0x112/0x180
 blk_mq_submit_bio+0x1f5/0x1100
 submit_bio_noacct+0x7b0/0x870
 submit_bio+0xc2/0x3a0
 btrfs_map_bio+0x4f0/0x9d0
 btrfs_submit_data_bio+0x24e/0x310
 submit_one_bio+0x7f/0xb0
 submit_extent_page+0xc4/0x440
 __extent_writepage_io+0x2b8/0x5e0
 __extent_writepage+0x28d/0x6e0
 extent_write_cache_pages+0x4d7/0x7a0
 extent_writepages+0xa2/0x110
 do_writepages+0x8f/0x180
 __writeback_single_inode+0x99/0x7f0
 writeback_sb_inodes+0x34e/0x790
 __writeback_inodes_wb+0x9e/0x120
 wb_writeback+0x4d2/0x660
 wb_workfn+0x64d/0xa10
 process_one_work+0x53a/0xa80
 worker_thread+0x69/0x5b0
 kthread+0x20b/0x240
 ret_from_fork+0x1f/0x30

Only Kyber uses the hctx, so fix it by passing the request_queue to
->bio_merge() instead. BFQ and mq-deadline just use that, and Kyber can
map the queues itself to avoid the mismatch.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/0b6b4b90b74c27bea968c214d820ba4254b903a5; https://git.kernel.org/stable/c/2ef3c76540c49167a0bc3d5f80d00fd1fc4586df; https://git.kernel.org/stable/c/54dbe2d2c1fcabf650c7a8b747601da355cd7f9f
CVE: CVE-2021-46985
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPI: scan: Fix a memory leak in an error handling path

If 'acpi_device_set_name()' fails, we must free
'acpi_device_bus_id->bus_id' or there is a (potential) memory leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0c8bd174f0fc131bc9dfab35cd8784f59045da87; https://git.kernel.org/stable/c/5ab9857dde7c3ea3faef6b128d718cf8ba98721b; https://git.kernel.org/stable/c/6901a4f795e0e8d65ae779cb37fc22e0bf294712
CVE: CVE-2021-46986
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: dwc3: gadget: Free gadget structure only after freeing endpoints

As part of commit e81a7018d93a ("usb: dwc3: allocate gadget structure
dynamically") the dwc3_gadget_release() was added which will free
the dwc->gadget structure upon the device's removal when
usb_del_gadget_udc() is called in dwc3_gadget_exit().

However, simply freeing the gadget results a dangling pointer
situation: the endpoints created in dwc3_gadget_init_endpoints()
have their dep->endpoint.ep_list members chained off the list_head
anchored at dwc->gadget->ep_list.  Thus when dwc->gadget is freed,
the first dwc3_ep in the list now has a dangling prev pointer and
likewise for the next pointer of the dwc3_ep at the tail of the list.
The dwc3_gadget_free_endpoints() that follows will result in a
use-after-free when it calls list_del().

This was caught by enabling KASAN and performing a driver unbind.
The recent commit 568262bf5492 ("usb: dwc3: core: Add shutdown
callback for dwc3") also exposes this as a panic during shutdown.

There are a few possibilities to fix this.  One could be to perform
a list_del() of the gadget->ep_list itself which removes it from
the rest of the dwc3_ep chain.

Another approach is what this patch does, by splitting up the
usb_del_gadget_udc() call into its separate "del" and "put"
components.  This allows dwc3_gadget_free_endpoints() to be
called before the gadget is finally freed with usb_put_gadget().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/1ea775021282d90e1d08d696b7ab54aa75d688e5; https://git.kernel.org/stable/c/b4b8e9601d7ee8806d2687f081a42485d27674a1; https://git.kernel.org/stable/c/bb9c74a5bd1462499fe5ccb1e3c5ac40dcfa9139
CVE: CVE-2021-46988
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

userfaultfd: release page in error path to avoid BUG_ON

Consider the following sequence of events:

1. Userspace issues a UFFD ioctl, which ends up calling into
   shmem_mfill_atomic_pte(). We successfully account the blocks, we
   shmem_alloc_page(), but then the copy_from_user() fails. We return
   -ENOENT. We don't release the page we allocated.
2. Our caller detects this error code, tries the copy_from_user() after
   dropping the mmap_lock, and retries, calling back into
   shmem_mfill_atomic_pte().
3. Meanwhile, let's say another process filled up the tmpfs being used.
4. So shmem_mfill_atomic_pte() fails to account blocks this time, and
   immediately returns - without releasing the page.

This triggers a BUG_ON in our caller, which asserts that the page
should always be consumed, unless -ENOENT is returned.

To fix this, detect if we have such a "dangling" page when accounting
fails, and if so, release it before returning.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/07c9b834c97d0fa3402fb7f3f3b32df370a6ff1f; https://git.kernel.org/stable/c/140cfd9980124aecb6c03ef2e69c72d0548744de; https://git.kernel.org/stable/c/2d59a0ed8b26b8f3638d8afc31f839e27759f1f6
CVE: CVE-2021-46989
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

hfsplus: prevent corruption in shrinking truncate

I believe there are some issues introduced by commit 31651c607151
("hfsplus: avoid deadlock on file truncation")

HFS+ has extent records which always contains 8 extents.  In case the
first extent record in catalog file gets full, new ones are allocated from
extents overflow file.

In case shrinking truncate happens to middle of an extent record which
locates in extents overflow file, the logic in hfsplus_file_truncate() was
changed so that call to hfs_brec_remove() is not guarded any more.

Right action would be just freeing the extents that exceed the new size
inside extent record by calling hfsplus_free_extents(), and then check if
the whole extent record should be removed.  However since the guard
(blk_cnt > start) is now after the call to hfs_brec_remove(), this has
unfortunate effect that the last matching extent record is removed
unconditionally.

To reproduce this issue, create a file which has at least 10 extents, and
then perform shrinking truncate into middle of the last extent record, so
that the number of remaining extents is not under or divisible by 8.  This
causes the last extent record (8 extents) to be removed totally instead of
truncating into middle of it.  Thus this causes corruption, and lost data.

Fix for this is simply checking if the new truncated end is below the
start of this extent record, making it safe to remove the full extent
record.  However call to hfs_brec_remove() can't be moved to it's previous
place since we're dropping ->tree_lock and it can cause a race condition
and the cached info being invalidated possibly corrupting the node data.

Another issue is related to this one.  When entering into the block
(blk_cnt > start) we are not holding the ->tree_lock.  We break out from
the loop not holding the lock, but hfs_find_exit() does unlock it.  Not
sure if it's possible for someone else to take the lock under our feet,
but it can cause hard to debug errors and premature unlocking.  Even if
there's no real risk of it, the locking should still always be kept in
balance.  Thus taking the lock now just before the check.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/52dde855663e5db824af51db39b5757d2ef3e28a; https://git.kernel.org/stable/c/97314e45aa1223a42d60256a62c5d9af54baf446; https://git.kernel.org/stable/c/adbd8a2a8cc05d9e501f93e5c95c59307874cc99
CVE: CVE-2021-46990
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/64s: Fix crashes when toggling entry flush barrier

The entry flush mitigation can be enabled/disabled at runtime via a
debugfs file (entry_flush), which causes the kernel to patch itself to
enable/disable the relevant mitigations.

However depending on which mitigation we're using, it may not be safe to
do that patching while other CPUs are active. For example the following
crash:

  sleeper[15639]: segfault (11) at c[PII_REDACTED]04c20 nip c[PII_REDACTED]04c20 lr c[PII_REDACTED]04c20

Shows that we returned to userspace with a corrupted LR that points into
the kernel, due to executing the partially patched call to the fallback
entry flush (ie. we missed the LR restore).

Fix it by doing the patching under stop machine. The CPUs that aren't
doing the patching will be spinning in the core of the stop machine
logic. That is currently sufficient for our purposes, because none of
the patching we do is to that code or anywhere in the vicinity.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0b4eb172cc12dc102cd0ad013e53ee4463db9508; https://git.kernel.org/stable/c/0c25a7bb697f2e6ee65b6d63782f675bf129511a; https://git.kernel.org/stable/c/2db22ba4e0e103f00e0512e0ecce36ac78c644f8
CVE: CVE-2021-46991
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

i40e: Fix use-after-free in i40e_client_subtask()

Currently the call to i40e_client_del_instance frees the object
pf->cinst, however pf->cinst->lan_info is being accessed after
the free. Fix this by adding the missing return.

Addresses-Coverity: ("Read from pointer after free")
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/1fd5d262e7442192ac7611ff1597a36c5b044323; https://git.kernel.org/stable/c/38318f23a7ef86a8b1862e5e8078c4de121960c3; https://git.kernel.org/stable/c/4ebc10aa7cd17fd9857dedac69600465c9dd16d1
CVE: CVE-2021-46992
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nftables: avoid overflows in nft_hash_buckets()

Number of buckets being stored in 32bit variables, we have to
ensure that no overflows occur in nft_hash_buckets()

syzbot injected a size == 0x40000000 and reported:

UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
shift exponent 64 is too large for 64-bit type 'long unsigned int'
CPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0x141/0x1d7 lib/dump_stack.c:120
 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148
 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327
 __roundup_pow_of_two include/linux/log2.h:57 [inline]
 nft_hash_buckets net/netfilter/nft_set_hash.c:411 [inline]
 nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652
 nft_select_set_ops net/netfilter/nf_tables_api.c:3586 [inline]
 nf_tables_newset+0xe62/0x3110 net/netfilter/nf_tables_api.c:4322
 nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488
 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [inline]
 nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:630
 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]
 netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338
 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927
 sock_sendmsg_nosec net/socket.c:654 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:674
 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/1e8ab479cfbe5751efccedb95afb9b112a5ba475; https://git.kernel.org/stable/c/2824cafc6a93792d9ad85939c499161214d84c4b; https://git.kernel.org/stable/c/72b49dd116ca00a46a11d5a4d8d7987f05ed9cd7
CVE: CVE-2021-46993
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

sched: Fix out-of-bound access in uclamp

Util-clamp places tasks in different buckets based on their clamp values
for performance reasons. However, the size of buckets is currently
computed using a rounding division, which can lead to an off-by-one
error in some configurations.

For instance, with 20 buckets, the bucket size will be 1024/20=51. A
task with a clamp of 1024 will be mapped to bucket id 1024/51=20. Sadly,
correct indexes are in range [0,19], hence leading to an out of bound
memory access.

Clamp the bucket id to fix the issue.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/3da3f804b82a0a382d523a21acf4cf3bb35f936d; https://git.kernel.org/stable/c/42ee47c7e3569d9a0e2cb5053c496d97d380472f; https://git.kernel.org/stable/c/687f523c134b7f0bd040ee1230f6d17990d54172
CVE: CVE-2021-46994
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

can: mcp251x: fix resume from sleep before interface was brought up

Since 8ce8c0abcba3 the driver queues work via priv->restart_work when
resuming after suspend, even when the interface was not previously
enabled. This causes a null dereference error as the workqueue is only
allocated and initialized in mcp251x_open().

To fix this we move the workqueue init to mcp251x_can_probe() as there
is no reason to do it later and repeat it whenever mcp251x_open() is
called.

[mkl: fix error handling in mcp251x_stop()]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/03c427147b2d3e503af258711af4fc792b89b0af; https://git.kernel.org/stable/c/6f8f1c27b577de15f69fefce3c502bb6300d825c; https://git.kernel.org/stable/c/e1e10a390fd9479209c4d834d916ca5e6d5d396b
CVE: CVE-2021-46995
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

can: mcp251xfd: mcp251xfd_probe(): fix an error pointer dereference in probe

When we converted this code to use dev_err_probe() we accidentally
removed a return. It means that if devm_clk_get() it will lead to an
Oops when we call clk_get_rate() on the next line.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/15f8f96ec7fc35024d4e03296e4d838fcea33d83; https://git.kernel.org/stable/c/4cc7faa406975b460aa674606291dea197c1210c; https://git.kernel.org/stable/c/15f8f96ec7fc35024d4e03296e4d838fcea33d83
CVE: CVE-2021-46996
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: nftables: Fix a memleak from userdata error path in new objects

Release object name if userdata allocation fails.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/2c784a500f5edd337258b0fdb2f31bc9abde1a23; https://git.kernel.org/stable/c/59fa98bfa1f4013d658d990cac88c87b46ff410c; https://git.kernel.org/stable/c/85dfd816fabfc16e71786eda0a33a7046688b5b0
CVE: CVE-2021-46998
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

ethernet:enic: Fix a use after free bug in enic_hard_start_xmit

In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside
enic_queue_wq_skb, if some error happens, the skb will be freed
by dev_kfree_skb(skb). But the freed skb is still used in
skb_tx_timestamp(skb).

My patch makes enic_queue_wq_skb() return error and goto spin_unlock()
incase of error. The solution is provided by Govind.
See https://lkml.org/lkml/2021/4/30/961.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/25a87b1f566b5eb2af2857a928f0e2310d900976; https://git.kernel.org/stable/c/643001b47adc844ae33510c4bb93c236667008a3; https://git.kernel.org/stable/c/6892396ebf04ea2c021d80e10f4075e014cd7cc3
CVE: CVE-2021-46999
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

sctp: do asoc update earlier in sctp_sf_do_dupcook_a

There's a panic that occurs in a few of envs, the call trace is as below:

  [] general protection fault, ... 0x29acd70f1000a: 0000 [#1] SMP PTI
  [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp]
  []  sctp_assoc_control_transport+0x1b9/0x210 [sctp]
  []  sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp]
  []  sctp_cmd_interpreter.isra.21+0x1231/0x1a10 [sctp]
  []  sctp_do_sm+0xc3/0x2a0 [sctp]
  []  sctp_generate_timeout_event+0x81/0xf0 [sctp]

This is caused by a transport use-after-free issue. When processing a
duplicate COOKIE-ECHO chunk in sctp_sf_do_dupcook_a(), both COOKIE-ACK
and SHUTDOWN chunks are allocated with the transort from the new asoc.
However, later in the sideeffect machine, the old asoc is used to send
them out and old asoc's shutdown_last_sent_to is set to the transport
that SHUTDOWN chunk attached to in sctp_cmd_setup_t2(), which actually
belongs to the new asoc. After the new_asoc is freed and the old asoc
T2 timeout, the old asoc's shutdown_last_sent_to that is already freed
would be accessed in sctp_sf_t2_timer_expire().

Thanks Alexander and Jere for helping dig into this issue.

To fix it, this patch is to do the asoc update first, then allocate
the COOKIE-ACK and SHUTDOWN chunks with the 'updated' old asoc. This
would make more sense, as a chunk from an asoc shouldn't be sent out
with another asoc. We had fixed quite a few issues caused by this.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0bfd913c2121b3d553bfd52810fe6061d542d625; https://git.kernel.org/stable/c/35b4f24415c854cd718ccdf38dbea6297f010aae; https://git.kernel.org/stable/c/61b877bad9bb0d82b7d8841be[PII_REDACTED]0a704
CVE: CVE-2021-47000
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

ceph: fix inode leak on getattr error in __fh_to_dentry
CVSS Score: 3.3 (LOW)
References: https://git.kernel.org/stable/c/0a219432127d396120fc88cabd82785e0ff72a2f; https://git.kernel.org/stable/c/1775c7ddacfcea29051c[PII_REDACTED]8f8f4d751b; https://git.kernel.org/stable/c/22fa4c8288f1ec40f6d62d7a32c57ac176f9f0bc
CVE: CVE-2021-47001
Published: 2024-02-28
Description: In the Linux kernel, the following vulnerability has been resolved:

xprtrdma: Fix cwnd update ordering

After a reconnect, the reply handler is opening the cwnd (and thus
enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs()
can post enough Receive WRs to receive their replies. This causes an
RNR and the new connection is lost immediately.

The race is most clearly exposed when KASAN and disconnect injection
are enabled. This slows down rpcrdma_rep_create() enough to allow
the send side to post a bunch of RPC Calls before the Receive
completion handler can invoke ib_post_recv().
CVSS Score: 4.7 (MEDIUM)
References: https://git.kernel.org/stable/c/19b5fa9489b5706bc878c3a522a7f771079e2fa0; https://git.kernel.org/stable/c/35d8b10a25884050bb3b0149b62c3818ec59f77c; https://git.kernel.org/stable/c/8834ecb5df22b7ff3c9b0deba7726579bb613f95