xamxte/cve-to-cwe huggingface dataset:
CVE-2023-52982: In the Linux kernel, the following vulnerability has been resolved:  fscache: Use wait_on_bit() to wait for the freeing of relinquished volume  The freeing of relinquished volume will wake up the pending volume acquisition by using wake_up_bit(), however it is mismatched with wait_var_event() used in fscache_wait_on_volume_collision() and it will never wake up the waiter in the wait-queue because these two functions operate on different wait-queues.  According to the implementation in fscache_wait_on_volume_collision(), if the wake-up of pending acquisition is delayed longer than 20 seconds (e.g., due to the delay of on-demand fd closing), the first wait_var_event_timeout() will timeout and the following wait_var_event() will hang forever as shown below:   FS-Cache: Potential volume collision new=00000024 old=00000022  ......  INFO: task mount:1148 blocked for more than 122 seconds.        Not tainted 6.1.0-rc6+ #1  task:mount           state:D stack:0     pid:1148  ppid:1  Call Trace:   <TASK>   __schedule+0x2f6/0xb80   schedule+0x67/0xe0   fscache_wait_on_volume_collision.cold+0x80/0x82   __fscache_acquire_volume+0x40d/0x4e0   erofs_fscache_register_volume+0x51/0xe0 [erofs]   erofs_fscache_register_fs+0x19c/0x240 [erofs]   erofs_fc_fill_super+0x746/0xaf0 [erofs]   vfs_get_super+0x7d/0x100   get_tree_nodev+0x16/0x20   erofs_fc_get_tree+0x20/0x30 [erofs]   vfs_get_tree+0x24/0xb0   path_mount+0x2fa/0xa90   do_mount+0x7c/0xa0   __x64_sys_mount+0x8b/0xe0   do_syscall_64+0x30/0x60   entry_SYSCALL_64_after_hwframe+0x46/0xb0  Considering that wake_up_bit() is more selective, so fix it by using wait_on_bit() instead of wait_var_event() to wait for the freeing of relinquished volume. In addition because waitqueue_active() is used in wake_up_bit() and clear_bit() doesn't imply any memory barrier, use clear_and_wake_up_bit() to add the missing memory barrier between cursor->flags and waitqueue_active().
CVE-2023-52995: In the Linux kernel, the following vulnerability has been resolved:  riscv/kprobe: Fix instruction simulation of JALR  Set kprobe at 'jalr 1140(ra)' of vfs_write results in the following crash:  [   32.092235] Unable to handle kernel access to user memory without uaccess routines at virtual address 00aaaaaad77b1170 [   32.093115] Oops [#1] [   32.093251] Modules linked in: [   32.093626] CPU: 0 PID: 135 Comm: ftracetest Not tainted 6.2.0-rc2-00013-gb0aa5e5df0cb-dirty #16 [   32.093985] Hardware name: riscv-virtio,qemu (DT) [   32.094280] epc : ksys_read+0x88/0xd6 [   32.094855]  ra : ksys_read+0xc0/0xd6 [   32.095016] epc : ffffffff801cda80 ra : ffffffff801cdab8 sp : ff20000000d7bdc0 [   32.095227]  gp : ffffffff80f14000 tp : ff60000080f9cb40 t0 : ffffffff80f13e80 [   32.095500]  t1 : ffffffff8000c29c t2 : ffffffff800dbc54 s0 : ff20000000d7be60 [   32.095716]  s1 : 0000000000000000 a0 : ffffffff805a64ae a1 : ffffffff80a83708 [   32.095921]  a2 : ffffffff80f160a0 a3 : 0000000000000000 a4 : f229b0afdb165300 [   32.096171]  a5 : f229b0afdb165300 a6 : ffffffff80eeebd0 a7 : 00000000000003ff [   32.096411]  s2 : ff6000007ff76800 s3 : fffffffffffffff7 s4 : 00aaaaaad77b1170 [   32.096638]  s5 : ffffffff80f160a0 s6 : ff6000007ff76800 s7 : 0000000000000030 [   32.096865]  s8 : 00ffffffc3d97be0 s9 : 0000000000000007 s10: 00aaaaaad77c9410 [   32.097092]  s11: 0000000000000000 t3 : ffffffff80f13e48 t4 : ffffffff8000c29c [   32.097317]  t5 : ffffffff8000c29c t6 : ffffffff800dbc54 [   32.097505] status: 0000000200000120 badaddr: 00aaaaaad77b1170 cause: 000000000000000d [   32.098011] [<ffffffff801cdb72>] ksys_write+0x6c/0xd6 [   32.098222] [<ffffffff801cdc06>] sys_write+0x2a/0x38 [   32.098405] [<ffffffff80003c76>] ret_from_syscall+0x0/0x2  Since the rs1 and rd might be the same one, such as 'jalr 1140(ra)', hence it requires obtaining the target address from rs1 followed by updating rd.  [Palmer: Pick Guo's cleanup]
CVE-2023-53006: In the Linux kernel, the following vulnerability has been resolved:  cifs: Fix oops due to uncleared server->smbd_conn in reconnect  In smbd_destroy(), clear the server->smbd_conn pointer after freeing the smbd_connection struct that it points to so that reconnection doesn't get confused.
CVE-2023-53010: In the Linux kernel, the following vulnerability has been resolved:  bnxt: Do not read past the end of test names  Test names were being concatenated based on a offset beyond the end of the first name, which tripped the buffer overflow detection logic:   detected buffer overflow in strnlen  [...]  Call Trace:  bnxt_ethtool_init.cold+0x18/0x18  Refactor struct hwrm_selftest_qlist_output to use an actual array, and adjust the concatenation to use snprintf() rather than a series of strncat() calls.
CVE-2023-53024: In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation  To mitigate Spectre v4, 2039f26f3aca ("bpf: Fix leakage due to insufficient speculative store bypass mitigation") inserts lfence instructions after 1) initializing a stack slot and 2) spilling a pointer to the stack.  However, this does not cover cases where a stack slot is first initialized with a pointer (subject to sanitization) but then overwritten with a scalar (not subject to sanitization because the slot was already initialized). In this case, the second write may be subject to speculative store bypass (SSB) creating a speculative pointer-as-scalar type confusion. This allows the program to subsequently leak the numerical pointer value using, for example, a branch-based cache side channel.  To fix this, also sanitize scalars if they write a stack slot that previously contained a pointer. Assuming that pointer-spills are only generated by LLVM on register-pressure, the performance impact on most real-world BPF programs should be small.  The following unprivileged BPF bytecode drafts a minimal exploit and the mitigation:    [...]   // r6 = 0 or 1 (skalar, unknown user input)   // r7 = accessible ptr for side channel   // r10 = frame pointer (fp), to be leaked   //   r9 = r10 # fp alias to encourage ssb   *(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, to be leaked   // lfence added here because of pointer spill to stack.   //   // Ommitted: Dummy bpf_ringbuf_output() here to train alias predictor   // for no r9-r10 dependency.   //   *(u64 *)(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr   // 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID,   // store may be subject to SSB   //   // fix: also add an lfence when the slot contained a ptr   //   r8 = *(u64 *)(r9 - 8)   // r8 = architecturally a scalar, speculatively a ptr   //   // leak ptr using branch-based cache side channel:   r8 &= 1 // choose bit to leak   if r8 == 0 goto SLOW // no mispredict   // architecturally dead code if input r6 is 0,   // only executes speculatively iff ptr bit is 1   r8 = *(u64 *)(r7 + 0) # encode bit in cache (0: slow, 1: fast) SLOW:   [...]  After running this, the program can time the access to *(r7 + 0) to determine whether the chosen pointer bit was 0 or 1. Repeat this 64 times to recover the whole address on amd64.  In summary, sanitization can only be skipped if one scalar is overwritten with another scalar. Scalar-confusion due to speculative store bypass can not lead to invalid accesses because the pointer bounds deducted during verification are enforced using branchless logic. See 979d63d50c0c ("bpf: prevent out of bounds speculation on pointer arithmetic") for details.  Do not make the mitigation depend on !env->allow_{uninit_stack,ptr_leaks} because speculative leaks are likely unexpected if these were enabled. For example, leaking the address to a protected log file may be acceptable while disabling the mitigation might unintentionally leak the address into the cached-state of a map that is accessible to unprivileged processes.
CVE-2023-53033: In the Linux kernel, the following vulnerability has been resolved:  netfilter: nft_payload: incorrect arithmetics when fetching VLAN header bits  If the offset + length goes over the ethernet + vlan header, then the length is adjusted to copy the bytes that are within the boundaries of the vlan_ethhdr scratchpad area. The remaining bytes beyond ethernet + vlan header are copied directly from the skbuff data area.  Fix incorrect arithmetic operator: subtract, not add, the size of the vlan header in case of double-tagged packets to adjust the length accordingly to address CVE-2023-0179.
CVE-2025-1449: A vulnerability exists in the Rockwell Automation Verve Asset Manager due to insufficient variable sanitizing. A portion of the administrative web interface for Verve's Legacy Agentless Device Inventory (ADI) capability (deprecated since the 1.36 release) allows users to change a variable with inadequate sanitizing. If exploited, it could allow a threat actor with administrative access to run arbitrary commands in the context of the container running the service.
CVE-2025-30429: A path handling issue was addressed with improved validation. This issue is fixed in visionOS 2.4, macOS Ventura 13.7.5, tvOS 18.4, iPadOS 17.7.6, iOS 18.4 and iPadOS 18.4, macOS Sequoia 15.4, macOS Sonoma 14.7.5. An app may be able to break out of its sandbox.
CVE-2025-21894: In the Linux kernel, the following vulnerability has been resolved:  net: enetc: VFs do not support HWTSTAMP_TX_ONESTEP_SYNC  Actually ENETC VFs do not support HWTSTAMP_TX_ONESTEP_SYNC because only ENETC PF can access PMa_SINGLE_STEP registers. And there will be a crash if VFs are used to test one-step timestamp, the crash log as follows.  [  129.110909] Unable to handle kernel paging request at virtual address 00000000000080c0 [  129.287769] Call trace: [  129.290219]  enetc_port_mac_wr+0x30/0xec (P) [  129.294504]  enetc_start_xmit+0xda4/0xe74 [  129.298525]  enetc_xmit+0x70/0xec [  129.301848]  dev_hard_start_xmit+0x98/0x118
CVE-2025-21903: In the Linux kernel, the following vulnerability has been resolved:  mctp i3c: handle NULL header address  daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped.  saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.
CVE-2025-21910: In the Linux kernel, the following vulnerability has been resolved:  wifi: cfg80211: regulatory: improve invalid hints checking  Syzbot keeps reporting an issue [1] that occurs when erroneous symbols sent from userspace get through into user_alpha2[] via regulatory_hint_user() call. Such invalid regulatory hints should be rejected.  While a sanity check from commit 47caf685a685 ("cfg80211: regulatory: reject invalid hints") looks to be enough to deter these very cases, there is a way to get around it due to 2 reasons.  1) The way isalpha() works, symbols other than latin lower and upper letters may be used to determine a country/domain. For instance, greek letters will also be considered upper/lower letters and for such characters isalpha() will return true as well. However, ISO-3166-1 alpha2 codes should only hold latin characters.  2) While processing a user regulatory request, between reg_process_hint_user() and regulatory_hint_user() there happens to be a call to queue_regulatory_request() which modifies letters in request->alpha2[] with toupper(). This works fine for latin symbols, less so for weird letter characters from the second part of _ctype[].  Syzbot triggers a warning in is_user_regdom_saved() by first sending over an unexpected non-latin letter that gets malformed by toupper() into a character that ends up failing isalpha() check.  Prevent this by enhancing is_an_alpha2() to ensure that incoming symbols are latin letters and nothing else.  [1] Syzbot report: ------------[ cut here ]------------ Unexpected user alpha2: A� WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 is_user_regdom_saved net/wireless/reg.c:440 [inline] WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_alpha2 net/wireless/reg.c:3424 [inline] WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516 Modules linked in: CPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 Not tainted 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: events_power_efficient crda_timeout_work RIP: 0010:is_user_regdom_saved net/wireless/reg.c:440 [inline] RIP: 0010:restore_alpha2 net/wireless/reg.c:3424 [inline] RIP: 0010:restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516 ... Call Trace:  <TASK>  crda_timeout_work+0x27/0x50 net/wireless/reg.c:542  process_one_work kernel/workqueue.c:3229 [inline]  process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310  worker_thread+0x870/0xd30 kernel/workqueue.c:3391  kthread+0x2f2/0x390 kernel/kthread.c:389  ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244  </TASK>
CVE-2025-21935: In the Linux kernel, the following vulnerability has been resolved:  rapidio: add check for rio_add_net() in rio_scan_alloc_net()  The return value of rio_add_net() should be checked.  If it fails, put_device() should be called to free the memory and give up the reference initialized in rio_add_net().
CVE-2025-21950: In the Linux kernel, the following vulnerability has been resolved:  drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmd_ioctl  In the "pmcmd_ioctl" function, three memory objects allocated by kmalloc are initialized by "hcall_get_cpu_state", which are then copied to user space. The initializer is indeed implemented in "acrn_hypercall2" (arch/x86/include/asm/acrn.h). There is a risk of information leakage due to uninitialized bytes.
CVE-2025-21955: In the Linux kernel, the following vulnerability has been resolved:  ksmbd: prevent connection release during oplock break notification  ksmbd_work could be freed when after connection release. Increment r_count of ksmbd_conn to indicate that requests are not finished yet and to not release the connection.
CVE-2025-21961: In the Linux kernel, the following vulnerability has been resolved:  eth: bnxt: fix truesize for mb-xdp-pass case  When mb-xdp is set and return is XDP_PASS, packet is converted from xdp_buff to sk_buff with xdp_update_skb_shared_info() in bnxt_xdp_build_skb(). bnxt_xdp_build_skb() passes incorrect truesize argument to xdp_update_skb_shared_info(). The truesize is calculated as BNXT_RX_PAGE_SIZE * sinfo->nr_frags but the skb_shared_info was wiped by napi_build_skb() before. So it stores sinfo->nr_frags before bnxt_xdp_build_skb() and use it instead of getting skb_shared_info from xdp_get_shared_info_from_buff().  Splat looks like:  ------------[ cut here ]------------  WARNING: CPU: 2 PID: 0 at net/core/skbuff.c:6072 skb_try_coalesce+0x504/0x590  Modules linked in: xt_nat xt_tcpudp veth af_packet xt_conntrack nft_chain_nat xt_MASQUERADE nf_conntrack_netlink xfrm_user xt_addrtype nft_coms  CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.14.0-rc2+ #3  RIP: 0010:skb_try_coalesce+0x504/0x590  Code: 4b fd ff ff 49 8b 34 24 40 80 e6 40 0f 84 3d fd ff ff 49 8b 74 24 48 40 f6 c6 01 0f 84 2e fd ff ff 48 8d 4e ff e9 25 fd ff ff <0f> 0b e99  RSP: 0018:ffffb62c4120caa8 EFLAGS: 00010287  RAX: 0000000000000003 RBX: ffffb62c4120cb14 RCX: 0000000000000ec0  RDX: 0000000000001000 RSI: ffffa06e5d7dc000 RDI: 0000000000000003  RBP: ffffa06e5d7ddec0 R08: ffffa06e6120a800 R09: ffffa06e7a119900  R10: 0000000000002310 R11: ffffa06e5d7dcec0 R12: ffffe4360575f740  R13: ffffe43600000000 R14: 0000000000000002 R15: 0000000000000002  FS:  0000000000000000(0000) GS:ffffa0755f700000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007f147b76b0f8 CR3: 00000001615d4000 CR4: 00000000007506f0  PKRU: 55555554  Call Trace:   <IRQ>   ? __warn+0x84/0x130   ? skb_try_coalesce+0x504/0x590   ? report_bug+0x18a/0x1a0   ? handle_bug+0x53/0x90   ? exc_invalid_op+0x14/0x70   ? asm_exc_invalid_op+0x16/0x20   ? skb_try_coalesce+0x504/0x590   inet_frag_reasm_finish+0x11f/0x2e0   ip_defrag+0x37a/0x900   ip_local_deliver+0x51/0x120   ip_sublist_rcv_finish+0x64/0x70   ip_sublist_rcv+0x179/0x210   ip_list_rcv+0xf9/0x130  How to reproduce: <Node A> ip link set $interface1 xdp obj xdp_pass.o ip link set $interface1 mtu 9000 up ip a a 10.0.0.1/24 dev $interface1 <Node B> ip link set $interfac2 mtu 9000 up ip a a 10.0.0.2/24 dev $interface2 ping 10.0.0.1 -s 65000  Following ping.py patch adds xdp-mb-pass case. so ping.py is going to be able to reproduce this issue.
CVE-2025-21973: In the Linux kernel, the following vulnerability has been resolved:  eth: bnxt: fix kernel panic in the bnxt_get_queue_stats{rx | tx}  When qstats-get operation is executed, callbacks of netdev_stats_ops are called. The bnxt_get_queue_stats{rx | tx} collect per-queue stats from sw_stats in the rings. But {rx | tx | cp}_ring are allocated when the interface is up. So, these rings are not allocated when the interface is down.  The qstats-get is allowed even if the interface is down. However, the bnxt_get_queue_stats{rx | tx}() accesses cp_ring and tx_ring without null check. So, it needs to avoid accessing rings if the interface is down.  Reproducer:  ip link set $interface down  ./cli.py --spec netdev.yaml --dump qstats-get OR  ip link set $interface down  python ./stats.py  Splat looks like:  BUG: kernel NULL pointer dereference, address: 0000000000000000  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 1680fa067 P4D 1680fa067 PUD 16be3b067 PMD 0  Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI  CPU: 0 UID: 0 PID: 1495 Comm: python3 Not tainted 6.14.0-rc4+ #32 5cd0f999d5a15c574ac72b3e4b907341  Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021  RIP: 0010:bnxt_get_queue_stats_rx+0xf/0x70 [bnxt_en]  Code: c6 87 b5 18 00 00 02 eb a2 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 01  RSP: 0018:ffffabef43cdb7e0 EFLAGS: 00010282  RAX: 0000000000000000 RBX: ffffffffc04c8710 RCX: 0000000000000000  RDX: ffffabef43cdb858 RSI: 0000000000000000 RDI: ffff8d504e850000  RBP: ffff8d506c9f9c00 R08: 0000000000000004 R09: ffff8d506bcd901c  R10: 0000000000000015 R11: ffff8d506bcd9000 R12: 0000000000000000  R13: ffffabef43cdb8c0 R14: ffff8d504e850000 R15: 0000000000000000  FS:  00007f2c5462b080(0000) GS:ffff8d575f600000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 0000000000000000 CR3: 0000000167fd0000 CR4: 00000000007506f0  PKRU: 55555554  Call Trace:   <TASK>   ? __die+0x20/0x70   ? page_fault_oops+0x15a/0x460   ? sched_balance_find_src_group+0x58d/0xd10   ? exc_page_fault+0x6e/0x180   ? asm_exc_page_fault+0x22/0x30   ? bnxt_get_queue_stats_rx+0xf/0x70 [bnxt_en cdd546fd48563c280cfd30e9647efa420db07bf1]   netdev_nl_stats_by_netdev+0x2b1/0x4e0   ? xas_load+0x9/0xb0   ? xas_find+0x183/0x1d0   ? xa_find+0x8b/0xe0   netdev_nl_qstats_get_dumpit+0xbf/0x1e0   genl_dumpit+0x31/0x90   netlink_dump+0x1a8/0x360
CVE-2025-21974: In the Linux kernel, the following vulnerability has been resolved:  eth: bnxt: return fail if interface is down in bnxt_queue_mem_alloc()  The bnxt_queue_mem_alloc() is called to allocate new queue memory when a queue is restarted. It internally accesses rx buffer descriptor corresponding to the index. The rx buffer descriptor is allocated and set when the interface is up and it's freed when the interface is down. So, if queue is restarted if interface is down, kernel panic occurs.  Splat looks like:  BUG: unable to handle page fault for address: 000000000000b240  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 0 P4D 0  Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI  CPU: 3 UID: 0 PID: 1563 Comm: ncdevmem2 Not tainted 6.14.0-rc2+ #9 844ddba6e7c459cafd0bf4db9a3198e  Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021  RIP: 0010:bnxt_queue_mem_alloc+0x3f/0x4e0 [bnxt_en]  Code: 41 54 4d 89 c4 4d 69 c0 c0 05 00 00 55 48 89 f5 53 48 89 fb 4c 8d b5 40 05 00 00 48 83 ec 15  RSP: 0018:ffff9dcc83fef9e8 EFLAGS: 00010202  RAX: ffffffffc0457720 RBX: ffff934ed8d40000 RCX: 0000000000000000  RDX: 000000000000001f RSI: ffff934ea508f800 RDI: ffff934ea508f808  RBP: ffff934ea508f800 R08: 000000000000b240 R09: ffff934e84f4b000  R10: ffff9dcc83fefa30 R11: ffff934e84f4b000 R12: 000000000000001f  R13: ffff934ed8d40ac0 R14: ffff934ea508fd40 R15: ffff934e84f4b000  FS:  00007fa73888c740(0000) GS:ffff93559f780000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 000000000000b240 CR3: 0000000145a2e000 CR4: 00000000007506f0  PKRU: 55555554  Call Trace:   <TASK>   ? __die+0x20/0x70   ? page_fault_oops+0x15a/0x460   ? exc_page_fault+0x6e/0x180   ? asm_exc_page_fault+0x22/0x30   ? __pfx_bnxt_queue_mem_alloc+0x10/0x10 [bnxt_en 7f85e76f4d724ba07471d7e39d9e773aea6597b7]   ? bnxt_queue_mem_alloc+0x3f/0x4e0 [bnxt_en 7f85e76f4d724ba07471d7e39d9e773aea6597b7]   netdev_rx_queue_restart+0xc5/0x240   net_devmem_bind_dmabuf_to_queue+0xf8/0x200   netdev_nl_bind_rx_doit+0x3a7/0x450   genl_family_rcv_msg_doit+0xd9/0x130   genl_rcv_msg+0x184/0x2b0   ? __pfx_netdev_nl_bind_rx_doit+0x10/0x10   ? __pfx_genl_rcv_msg+0x10/0x10   netlink_rcv_skb+0x54/0x100   genl_rcv+0x24/0x40 ...
CVE-2025-21995: In the Linux kernel, the following vulnerability has been resolved:  drm/sched: Fix fence reference count leak  The last_scheduled fence leaks when an entity is being killed and adding the cleanup callback fails.  Decrement the reference count of prev when dma_fence_add_callback() fails, ensuring proper balance.  [phasta: add git tag info for stable kernel]
CVE-2025-30401: A spoofing issue in WhatsApp for Windows prior to version 2.2450.6 displayed attachments according to their MIME type but selected the file opening handler based on the attachment’s filename extension. A maliciously crafted mismatch could have caused the recipient to inadvertently execute arbitrary code rather than view the attachment when manually opening the attachment inside WhatsApp. We have not seen evidence of exploitation in the wild.
CVE-2025-20935: Improper handling of insufficient permission or privileges in ClipboardService prior to SMR Apr-2025 Release 1 allows local attackers to access files with system privilege. User interaction is required for triggering this vulnerability.
CVE-2025-20936: Improper access control in HDCP trustlet prior to SMR Apr-2025 Release 1 allows local attackers with shell privilege to escalate their privileges to root.
CVE-2025-20938: Improper access control in SamsungContacts prior to SMR Apr-2025 Release 1 allows local attackers to access protected data in SamsungContacts.
CVE-2025-20939: Improper authorization in wireless download protocol in Galaxy Watch prior to SMR Apr-2025 Release 1 allows physical attackers to update device unique identifier of Watch devices.
CVE-2025-20940: Improper handling of insufficient permission in Samsung Device Health Manager Service prior to SMR Apr-2025 Release 1 allows local attackers to access provider in SDMHS.
CVE-2025-20941: Improper access control in InputManager to SMR Apr-2025 Release 1 allows local attackers to access the scancode of specific input device.
CVE-2025-20947: Improper handling of insufficient permission or privileges in ClipboardService prior to SMR Apr-2025 Release 1 allows local attackers to access image files across multiple users. User interaction is required for triggering this vulnerability.
CVE-2025-20951: Improper verification of intent by broadcast receiver vulnerability in Galaxy Store prior to version 4.5.90.7 allows local attackers to write arbitrary files with the privilege of Galaxy Store.
CVE-2025-22871: The net/http package improperly accepts a bare LF as a line terminator in chunked data chunk-size lines. This can permit request smuggling if a net/http server is used in conjunction with a server that incorrectly accepts a bare LF as part of a chunk-ext.
CVE-2025-20952: Improper access control in Mdecservice prior to SMR Apr-2025 Release 1 allows local attackers to access arbitrary files with system privilege.