Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2021-46988 State: PUBLISHED Published: 2024-02-28T08:13:15.310Z Last Updated: 2025-05-04T07:01:49.099Z Vendors: Linux Products: Linux 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
r 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. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/3191162
l Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/319116227e52d49eee671f0aa278bac89b3c1b69 - https://git.kernel.org/stable/c/07c9b834c97d0fa3402fb7f3f3b32df370a6ff1f - https://git.kernel.org/stable/c/b3f1731c6d7fbc1ebe3ed8eff6d6bec56d76ff43 - https://git.kernel.org/stable/c/140cfd9980124aecb6c03ef2e69c72d0548744de - https://git.kernel.org/stable/c/ad53127973034c63b5348715a1043d0e80ceb330 - https://git.kernel.org/stable/c/2d59a0ed8b26b8f3638d8afc31f839e27759f1f6 - https://git.kernel.org/stable/c/7ed9d238c7dbb1fdb63ad96a6184985151b0171c
CVE ID: CVE-2021-46989 State: PUBLISHED Published: 2024-02-28T08:13:15.930Z Last Updated: 2025-05-04T07:01:50.434Z Vendors: Linux Products: Linux 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() w
ate 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 recor
e, 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 no
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. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: -
ck now just before the check. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/52dde855663e5db824af51db39b5757d2ef3e28a - https://git.kernel.org/stable/c/c451a6bafb5f422197d31536f82116aed132b72c - https://git.kernel.org/stable/c/adbd8a2a8cc05d9e501f93e5c95c59307874cc99 - https://git.kernel.org/stable/c/c477f62db1a0c0ecaa60a29713006ceeeb04b685 - https://git.kernel.org/stable/c/97314e45aa1223a42d60256a62c5d9af54baf446 - https://git.kernel.org/stable/c/c3187cf32216313fb316084efac4dab3a8459b1d
CVE ID: CVE-2021-46990 State: PUBLISHED Published: 2024-02-28T08:13:16.569Z Last Updated: 2025-05-04T12:40:44.599Z Vendors: Linux Products: Linux 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 c000000000004c20 nip c000000000004c20 lr c0000000
ive. For example the following crash: sleeper[15639]: segfault (11) at c000000000004c20 nip c000000000004c20 lr c000000000004c20 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. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.o
vicinity. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/8382b15864e5014261b4f36c2aa89723612ee058 - https://git.kernel.org/stable/c/0c25a7bb697f2e6ee65b6d63782f675bf129511a - https://git.kernel.org/stable/c/ee4b7aab93c2631c3bb0753023c5dda592bb666b - https://git.kernel.org/stable/c/2db22ba4e0e103f00e0512e0ecce36ac78c644f8 - https://git.kernel.org/stable/c/0b4eb172cc12dc102cd0ad013e53ee4463db9508 - https://git.kernel.org/stable/c/d2e3590ca39ccfd8a5a46d8c7f095cb6c7b9ae92 - https://git.kernel.org/stable/c/dd0d6117052faace5440db20fc37175efe921c7d - https://git.kernel.org/stable/c/5bc00fdda1e934c557351a9c751a205293e68cbf -
c/dd0d6117052faace5440db20fc37175efe921c7d - https://git.kernel.org/stable/c/5bc00fdda1e934c557351a9c751a205293e68cbf - https://git.kernel.org/stable/c/aec86b052df6541cc97c5fca44e5934cbea4963b
CVE ID: CVE-2021-46991 State: PUBLISHED Published: 2024-02-28T08:13:17.195Z Last Updated: 2025-05-04T07:01:52.574Z Vendors: Linux Products: Linux 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") Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/c1322eaeb8af0d8985b5cc5fa759140fa0e57b84 - https://git.kernel.org/stable
: References: - https://git.kernel.org/stable/c/c1322eaeb8af0d8985b5cc5fa759140fa0e57b84 - https://git.kernel.org/stable/c/d718c15a2bf9ae082d5ae4d177fb19ef23cb4132 - https://git.kernel.org/stable/c/829a713450b8fb127cbabfc1244c1d8179ec5107 - https://git.kernel.org/stable/c/4ebc10aa7cd17fd9857dedac69600465c9dd16d1 - https://git.kernel.org/stable/c/1fd5d262e7442192ac7611ff1597a36c5b044323 - https://git.kernel.org/stable/c/38318f23a7ef86a8b1862e5e8078c4de121960c3
CVE ID: CVE-2021-46992 State: PUBLISHED Published: 2024-02-28T08:13:17.814Z Last Updated: 2025-05-04T07:01:53.656Z Vendors: Linux Products: Linux 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/Goo
U: 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
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 ar
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 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/2824cafc6a93792d9ad85939c499161214d84c4b - https://git.kernel.org/stable/c/efcd730ddd6f25578bd31bfe703e593e2421d708 - https://git.kernel.org/stable/c/c77e2ef18167ad334e27610ced9a7f6af5ec1787 - https://git.kernel.org/stable/c/72b49dd116ca00a46a11d5a4d8d7987f05ed9cd7 - https://git.kernel.org/stable/c/1e8ab479cfbe5751efccedb95afb9b112a5ba475 - https://git.kernel.org/stable/c/a388d10961ff8578b1a6691945d406c0f33aa71b - https://git.ker
751efccedb95afb9b112a5ba475 - https://git.kernel.org/stable/c/a388d10961ff8578b1a6691945d406c0f33aa71b - https://git.kernel.org/stable/c/a54754ec9891830ba548e2010c889e3c8146e449
CVE ID: CVE-2021-46993 State: PUBLISHED Published: 2024-02-28T08:13:18.494Z Last Updated: 2025-05-04T07:01:54.678Z Vendors: Linux Products: Linux 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 t
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. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/687f523c134b7f0bd040ee1230f6d17990d54172 - https://git.kernel.org/stable/c/f7347c85490b92dd144fa1fba9e1eca501656ab3 - https://git.kernel.org/stable/c/3da3f804b82a0a382d523a21acf4cf3bb35f936d - https://git.kernel.org/stable/c/42ee47c7e3569d9a0e2cb5053c496d97d380472f - https://git.kernel.org/stable/c/6d2f8909a5fabb73fe2a63918117943986c39b6c
CVE ID: CVE-2021-46994 State: PUBLISHED Published: 2024-02-28T08:13:19.115Z Last Updated: 2025-05-04T07:01:55.985Z Vendors: Linux Products: Linux 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
e 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()] Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/eecb4df8ec9f896b19ee05bfa632ac6c1dcd8f21 - https://git.kernel.org/stable/c/6f8f1c27b577de15f69fefce3c502bb6300d825c - https://git.kernel.org/stable/c/e1e10a390fd9479209c4d834d916ca5e6d5d396b - https://git.kernel.org/stable/c/03c427147b2d3e503af258711af4fc792b89b0af
CVE ID: CVE-2021-46995 State: PUBLISHED Published: 2024-02-28T08:13:19.751Z Last Updated: 2025-05-04T07:01:57.355Z Vendors: Linux Products: Linux 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. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/15f8f96ec7fc35024d4e03296e4d838fcea33d83 - https://git.kernel.org/stable/c/4cc7faa40697
https://git.kernel.org/stable/c/15f8f96ec7fc35024d4e03296e4d838fcea33d83 - https://git.kernel.org/stable/c/4cc7faa406975b460aa674606291dea197c1210c
CVE ID: CVE-2021-46996 State: PUBLISHED Published: 2024-02-28T08:13:20.406Z Last Updated: 2025-05-04T07:01:58.380Z Vendors: Linux Products: Linux 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. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/2c784a500f5edd337258b0fdb2f31bc9abde1a23 - https://git.kernel.org/stable/c/59fa98bfa1f4013d658d990cac88c87b46ff410c - https://git.kernel.org/stable/c/dd3bebf515f336214a91994348a2b86b9a1d3d7f - https://git.kernel.org/stable/c/8
b46ff410c - https://git.kernel.org/stable/c/dd3bebf515f336214a91994348a2b86b9a1d3d7f - https://git.kernel.org/stable/c/85dfd816fabfc16e71786eda0a33a7046688b5b0
CVE ID: CVE-2021-46997 State: PUBLISHED Published: 2024-02-28T08:13:21.043Z Last Updated: 2025-05-04T07:01:59.453Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64: entry: always set GIC_PRIO_PSR_I_SET during entry Zenghui reports that booting a kernel with "irqchip.gicv3_pseudo_nmi=1" on the command line hits a warning during kernel entry, due to the way we manipulate the PMR. Early in the entry sequence, we call lockdep_hardirqs_off() to inform lockdep that interrupts have been masked (as the HW sets DAIF wqhen entering an exception). Architecturally PMR_EL1 is not affected by exception entry, and we don't set GIC_PRIO_PS
F wqhen entering an exception). Architecturally PMR_EL1 is not affected by exception entry, and we don't set GIC_PRIO_PSR_I_SET in the PMR early in the exception entry sequence, so early in exception entry the PMR can indicate that interrupts are unmasked even though they are masked by DAIF. If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the exception entry paths, and hence lockdep_hardirqs_off() will WARN() that something is amiss. We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during exception entry so that kernel code sees a consistent environment. We must also update local_daif_inherit()
I_SET during exception entry so that kernel code sees a consistent environment. We must also update local_daif_inherit() to undo this, as currently only touches DAIF. For other paths, local_daif_restore() will update both DAIF and the PMR. With this done, we can remove the existing special cases which set this later in the entry code. We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with local_daif_save(), as this will warn if it ever encounters (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. This matches the gic_prio_kentry_setup that we have to retain for ret_to_user. The original splat from Zenghui's report was: | DEBUG_LOCKS_WARN_ON(!irqs_disabled()
we have to retain for ret_to_user. The original splat from Zenghui's report was: | DEBUG_LOCKS_WARN_ON(!irqs_disabled()) | WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8 | Modules linked in: | CPU: 3 PID: 125 Comm: modprobe Tainted: G W 5.12.0-rc8+ #463 | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=--) | pc : lockdep_hardirqs_off+0xd4/0xe8 | lr : lockdep_hardirqs_off+0xd4/0xe8 | sp : ffff80002a39bad0 | pmr_save: 000000e0 | x29: ffff80002a39bad0 x28: ffff0000de214bc0 | x27: ffff0000de1c0400 x26: 000000000049b328 | x25: 0000000000406f30 x24: ffff0000de1c00a0 | x23: 0000000020400005
bc0 | x27: ffff0000de1c0400 x26: 000000000049b328 | x25: 0000000000406f30 x24: ffff0000de1c00a0 | x23: 0000000020400005 x22: ffff8000105f747c | x21: 0000000096000044 x20: 0000000000498ef9 | x19: ffff80002a39bc88 x18: ffffffffffffffff | x17: 0000000000000000 x16: ffff800011c61eb0 | x15: ffff800011700a88 x14: 0720072007200720 | x13: 0720072007200720 x12: 0720072007200720 | x11: 0720072007200720 x10: 0720072007200720 | x9 : ffff80002a39bad0 x8 : ffff80002a39bad0 | x7 : ffff8000119f0800 x6 : c0000000ffff7fff | x5 : ffff8000119f07a8 x4 : 0000000000000001 | x3 : 9bcdab23f2432800 x2 : ffff800011730538 | x1 : 9bcdab23f2432800 x0 : 0000000000000000 | Call trace: | lockdep_hardirqs_off+0xd4/0xe8 | ent
x2 : ffff800011730538 | x1 : 9bcdab23f2432800 x0 : 0000000000000000 | Call trace: | lockdep_hardirqs_off+0xd4/0xe8 | enter_from_kernel_mode.isra.5+0x7c/0xa8 | el1_abort+0x24/0x100 | el1_sync_handler+0x80/0xd0 | el1_sync+0x6c/0x100 | __arch_clear_user+0xc/0x90 | load_elf_binary+0x9fc/0x1450 | bprm_execve+0x404/0x880 | kernel_execve+0x180/0x188 | call_usermodehelper_exec_async+0xdc/0x158 | ret_from_fork+0x10/0x18 Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/51524fa8b5f7b879ba569227738375d283b79382 - https://git.kernel.org/stable/c/e67a83f078005461b59b4c776e6b5addd11725fa - https://git.kernel.org/stable/c/d8d52005f57bb
https://git.kernel.org/stable/c/e67a83f078005461b59b4c776e6b5addd11725fa - https://git.kernel.org/stable/c/d8d52005f57bbb4a4ec02f647e2555d327135c68 - https://git.kernel.org/stable/c/4d6a38da8e79e94cbd1344aa90876f0f805db705
CVE ID: CVE-2021-46998 State: PUBLISHED Published: 2024-02-28T08:13:21.651Z Last Updated: 2025-05-04T07:02:00.757Z Vendors: Linux Products: Linux 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. Additional Analyst Notes: - CVE Progr
rror. The solution is provided by Govind. See https://lkml.org/lkml/2021/4/30/961. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/25a87b1f566b5eb2af2857a928f0e2310d900976 - https://git.kernel.org/stable/c/f7f6f07774091a6ddd98500b85386c3c6afb30d3 - https://git.kernel.org/stable/c/7afdd6aba95c8a526038e7abe283eeac3e4320f1 - https://git.kernel.org/stable/c/6892396ebf04ea2c021d80e10f4075e014cd7cc3 - https://git.kernel.org/stable/c/d90529392aaf498dafa95d212295d64b2cea4e24 - https://git.kernel.org/stable/c/643001b47adc844ae33510c4bb93c236667008a3
CVE ID: CVE-2021-46999 State: PUBLISHED Published: 2024-02-28T08:13:22.256Z Last Updated: 2025-05-04T12:40:45.930Z Vendors: Linux Products: Linux 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_genera
6+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 tha
longs 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. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d624f2991b977821375fbd56c91b0c91d456a697 - https://git.kern
ram Container: References: - https://git.kernel.org/stable/c/d624f2991b977821375fbd56c91b0c91d456a697 - https://git.kernel.org/stable/c/b1b31948c0af44628e43353828453461bb74098f - https://git.kernel.org/stable/c/f01988ecf3654f805282dce2d3bb9afe68d2691e - https://git.kernel.org/stable/c/61b877bad9bb0d82b7d8841be50872557090a704 - https://git.kernel.org/stable/c/0bfd913c2121b3d553bfd52810fe6061d542d625 - https://git.kernel.org/stable/c/35b4f24415c854cd718ccdf38dbea6297f010aae