xamxte/cve-to-cwe huggingface dataset:
CVE-2024-56641: In the Linux kernel, the following vulnerability has been resolved:  net/smc: initialize close_work early to avoid warning  We encountered a warning that close_work was canceled before initialization.    WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0   Workqueue: events smc_lgr_terminate_work [smc]   RIP: 0010:__flush_work+0x19e/0x1b0   Call Trace:    ? __wake_up_common+0x7a/0x190    ? work_busy+0x80/0x80    __cancel_work_timer+0xe3/0x160    smc_close_cancel_work+0x1a/0x70 [smc]    smc_close_active_abort+0x207/0x360 [smc]    __smc_lgr_terminate.part.38+0xc8/0x180 [smc]    process_one_work+0x19e/0x340    worker_thread+0x30/0x370    ? process_one_work+0x340/0x340    kthread+0x117/0x130    ? __kthread_cancel_work+0x50/0x50    ret_from_fork+0x22/0x30  This is because when smc_close_cancel_work is triggered, e.g. the RDMA driver is rmmod and the LGR is terminated, the conn->close_work is flushed before initialization, resulting in WARN_ON(!work->func).  __smc_lgr_terminate             | smc_connect_{rdma|ism} -------------------------------------------------------------                                 | smc_conn_create     | \- smc_lgr_register_conn for conn in lgr->conns_all      | \- smc_conn_kill                |    \- smc_close_active_abort    |       \- smc_close_cancel_work  |          \- cancel_work_sync    |             \- __flush_work     |           (close_work)   |                          | smc_close_init                          | \- INIT_WORK(&close_work)  So fix this by initializing close_work before establishing the connection.
CVE-2024-56644: In the Linux kernel, the following vulnerability has been resolved:  net/ipv6: release expired exception dst cached in socket  Dst objects get leaked in ip6_negative_advice() when this function is executed for an expired IPv6 route located in the exception table. There are several conditions that must be fulfilled for the leak to occur: * an ICMPv6 packet indicating a change of the MTU for the path is received,   resulting in an exception dst being created * a TCP connection that uses the exception dst for routing packets must   start timing out so that TCP begins retransmissions * after the exception dst expires, the FIB6 garbage collector must not run   before TCP executes ip6_negative_advice() for the expired exception dst  When TCP executes ip6_negative_advice() for an exception dst that has expired and if no other socket holds a reference to the exception dst, the refcount of the exception dst is 2, which corresponds to the increment made by dst_init() and the increment made by the TCP socket for which the connection is timing out. The refcount made by the socket is never released. The refcount of the dst is decremented in sk_dst_reset() but that decrement is counteracted by a dst_hold() intentionally placed just before the sk_dst_reset() in ip6_negative_advice(). After ip6_negative_advice() has finished, there is no other object tied to the dst. The socket lost its reference stored in sk_dst_cache and the dst is no longer in the exception table. The exception dst becomes a leaked object.  As a result of this dst leak, an unbalanced refcount is reported for the loopback device of a net namespace being destroyed under kernels that do not contain e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"): unregister_netdevice: waiting for lo to become free. Usage count = 2  Fix the dst leak by removing the dst_hold() in ip6_negative_advice(). The patch that introduced the dst_hold() in ip6_negative_advice() was 92f1655aa2b22 ("net: fix __dst_negative_advice() race"). But 92f1655aa2b22 merely refactored the code with regards to the dst refcount so the issue was present even before 92f1655aa2b22. The bug was introduced in 54c1a859efd9f ("ipv6: Don't drop cache route entry unless timer actually expired.") where the expired cached route is deleted and the sk_dst_cache member of the socket is set to NULL by calling dst_negative_advice() but the refcount belonging to the socket is left unbalanced.  The IPv4 version - ipv4_negative_advice() - is not affected by this bug. When the TCP connection times out ipv4_negative_advice() merely resets the sk_dst_cache of the socket while decrementing the refcount of the exception dst.
CVE-2024-56654: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_event: Fix using rcu_read_(un)lock while iterating  The usage of rcu_read_(un)lock while inside list_for_each_entry_rcu is not safe since for the most part entries fetched this way shall be treated as rcu_dereference:   Note that the value returned by rcu_dereference() is valid  only within the enclosing RCU read-side critical section [1]_.  For example, the following is **not** legal::    rcu_read_lock();   p = rcu_dereference(head.next);   rcu_read_unlock();   x = p->address; /* BUG!!! */   rcu_read_lock();   y = p->data; /* BUG!!! */   rcu_read_unlock();
CVE-2024-56656: In the Linux kernel, the following vulnerability has been resolved:  bnxt_en: Fix aggregation ID mask to prevent oops on 5760X chips  The 5760X (P7) chip's HW GRO/LRO interface is very similar to that of the previous generation (5750X or P5).  However, the aggregation ID fields in the completion structures on P7 have been redefined from 16 bits to 12 bits.  The freed up 4 bits are redefined for part of the metadata such as the VLAN ID.  The aggregation ID mask was not modified when adding support for P7 chips.  Including the extra 4 bits for the aggregation ID can potentially cause the driver to store or fetch the packet header of GRO/LRO packets in the wrong TPA buffer.  It may hit the BUG() condition in __skb_pull() because the SKB contains no valid packet header:  kernel BUG at include/linux/skbuff.h:2766! Oops: invalid opcode: 0000 1 PREEMPT SMP NOPTI CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Kdump: loaded Tainted: G           OE      6.12.0-rc2+ #7 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. PowerEdge R760/0VRV9X, BIOS 1.0.1 12/27/2022 RIP: 0010:eth_type_trans+0xda/0x140 Code: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 d0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48 RSP: 0018:ff615003803fcc28 EFLAGS: 00010283 RAX: 00000000000022d2 RBX: 0000000000000003 RCX: ff2e8c25da334040 RDX: 0000000000000040 RSI: ff2e8c25c1ce8000 RDI: ff2e8c25869f9000 RBP: ff2e8c258c31c000 R08: ff2e8c25da334000 R09: 0000000000000001 R10: ff2e8c25da3342c0 R11: ff2e8c25c1ce89c0 R12: ff2e8c258e0990b0 R13: ff2e8c25bb120000 R14: ff2e8c25c1ce89c0 R15: ff2e8c25869f9000 FS:  0000000000000000(0000) GS:ff2e8c34be300000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f05317e4c8 CR3: 000000108bac6006 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace:  <IRQ>  ? die+0x33/0x90  ? do_trap+0xd9/0x100  ? eth_type_trans+0xda/0x140  ? do_error_trap+0x65/0x80  ? eth_type_trans+0xda/0x140  ? exc_invalid_op+0x4e/0x70  ? eth_type_trans+0xda/0x140  ? asm_exc_invalid_op+0x16/0x20  ? eth_type_trans+0xda/0x140  bnxt_tpa_end+0x10b/0x6b0 [bnxt_en]  ? bnxt_tpa_start+0x195/0x320 [bnxt_en]  bnxt_rx_pkt+0x902/0xd90 [bnxt_en]  ? __bnxt_tx_int.constprop.0+0x89/0x300 [bnxt_en]  ? kmem_cache_free+0x343/0x440  ? __bnxt_tx_int.constprop.0+0x24f/0x300 [bnxt_en]  __bnxt_poll_work+0x193/0x370 [bnxt_en]  bnxt_poll_p5+0x9a/0x300 [bnxt_en]  ? try_to_wake_up+0x209/0x670  __napi_poll+0x29/0x1b0  Fix it by redefining the aggregation ID mask for P5_PLUS chips to be 12 bits.  This will work because the maximum aggregation ID is less than 4096 on all P5_PLUS chips.
CVE-2024-56659: In the Linux kernel, the following vulnerability has been resolved:  net: lapb: increase LAPB_HEADER_LEN  It is unclear if net/lapb code is supposed to be ready for 8021q.  We can at least avoid crashes like the following :  skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2 ------------[ cut here ]------------  kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024  RIP: 0010:skb_panic net/core/skbuff.c:206 [inline]  RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc90002ddf638 EFLAGS: 00010282 RAX: 0000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600 RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000 RBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60 R10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140 R13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016 FS:  00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  <TASK>   skb_push+0xe5/0x100 net/core/skbuff.c:2636   nr_header+0x36/0x320 net/netrom/nr_dev.c:69   dev_hard_header include/linux/netdevice.h:3148 [inline]   vlan_dev_hard_header+0x359/0x480 net/8021q/vlan_dev.c:83   dev_hard_header include/linux/netdevice.h:3148 [inline]   lapbeth_data_transmit+0x1f6/0x2a0 drivers/net/wan/lapbether.c:257   lapb_data_transmit+0x91/0xb0 net/lapb/lapb_iface.c:447   lapb_transmit_buffer+0x168/0x1f0 net/lapb/lapb_out.c:149  lapb_establish_data_link+0x84/0xd0  lapb_device_event+0x4e0/0x670   notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93  __dev_notify_flags+0x207/0x400   dev_change_flags+0xf0/0x1a0 net/core/dev.c:8922   devinet_ioctl+0xa4e/0x1aa0 net/ipv4/devinet.c:1188   inet_ioctl+0x3d7/0x4f0 net/ipv4/af_inet.c:1003   sock_do_ioctl+0x158/0x460 net/socket.c:1227   sock_ioctl+0x626/0x8e0 net/socket.c:1346   vfs_ioctl fs/ioctl.c:51 [inline]   __do_sys_ioctl fs/ioctl.c:907 [inline]   __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
CVE-2024-56665: In the Linux kernel, the following vulnerability has been resolved:  bpf,perf: Fix invalid prog_array access in perf_event_detach_bpf_prog  Syzbot reported [1] crash that happens for following tracing scenario:    - create tracepoint perf event with attr.inherit=1, attach it to the     process and set bpf program to it   - attached process forks -> chid creates inherited event      the new child event shares the parent's bpf program and tp_event     (hence prog_array) which is global for tracepoint    - exit both process and its child -> release both events   - first perf_event_detach_bpf_prog call will release tp_event->prog_array     and second perf_event_detach_bpf_prog will crash, because     tp_event->prog_array is NULL  The fix makes sure the perf_event_detach_bpf_prog checks prog_array is valid before it tries to remove the bpf program from it.  [1] https://lore.kernel.org/bpf/Z1MR6dCIKajNS6nU@krava/T/#m91dbf0688221ec7a7fc95e896a7ef9ff93b0b8ad
CVE-2024-56671: In the Linux kernel, the following vulnerability has been resolved:  gpio: graniterapids: Fix vGPIO driver crash  Move setting irq_chip.name from probe() function to the initialization of "irq_chip" struct in order to fix vGPIO driver crash during bootup.  Crash was caused by unauthorized modification of irq_chip.name field where irq_chip struct was initialized as const.  This behavior is a consequence of suboptimal implementation of gpio_irq_chip_set_chip(), which should be changed to avoid casting away const qualifier.  Crash log: BUG: unable to handle page fault for address: ffffffffc0ba81c0 /#PF: supervisor write access in kernel mode /#PF: error_code(0x0003) - permissions violation CPU: 33 UID: 0 PID: 1075 Comm: systemd-udevd Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7 #1 Hardware name: Intel Corporation Kaseyville RP/Kaseyville RP, BIOS KVLDCRB1.PGS.0026.D73.2410081258 10/08/2024 RIP: 0010:gnr_gpio_probe+0x171/0x220 [gpio_graniterapids]
CVE-2024-56681: In the Linux kernel, the following vulnerability has been resolved:  crypto: bcm - add error check in the ahash_hmac_init function  The ahash_init functions may return fails. The ahash_hmac_init should not return ok when ahash_init returns error. For an example, ahash_init will return -ENOMEM when allocation memory is error.
CVE-2024-56684: In the Linux kernel, the following vulnerability has been resolved:  mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks()  It should be size of the struct clk_bulk_data, not data pointer pass to devm_kcalloc().
CVE-2024-56701: In the Linux kernel, the following vulnerability has been resolved:  powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore  The dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because the code calls kmalloc() while holding it, which can sleep:    # echo 1 > /proc/powerpc/vcpudispatch_stats   BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337   in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh   preempt_count: 1, expected: 0   3 locks held by sh/199:    #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438    #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4    #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4   CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152   Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries   Call Trace:     dump_stack_lvl+0x130/0x148 (unreliable)     __might_resched+0x174/0x410     kmem_cache_alloc_noprof+0x340/0x3d0     alloc_dtl_buffers+0x124/0x1ac     vcpudispatch_stats_write+0x2a8/0x5f4     proc_reg_write+0xf4/0x150     vfs_write+0xfc/0x438     ksys_write+0x88/0x148     system_call_exception+0x1c4/0x5a0     system_call_common+0xf4/0x258
CVE-2024-56709: In the Linux kernel, the following vulnerability has been resolved:  io_uring: check if iowq is killed before queuing  task work can be executed after the task has gone through io_uring termination, whether it's the final task_work run or the fallback path. In this case, task work will find ->io_wq being already killed and null'ed, which is a problem if it then tries to forward the request to io_queue_iowq(). Make io_queue_iowq() fail requests in this case.  Note that it also checks PF_KTHREAD, because the user can first close a DEFER_TASKRUN ring and shortly after kill the task, in which case ->iowq check would race.
CVE-2024-56714: In the Linux kernel, the following vulnerability has been resolved:  ionic: no double destroy workqueue  There are some FW error handling paths that can cause us to try to destroy the workqueue more than once, so let's be sure we're checking for that.  The case where this popped up was in an AER event where the handlers got called in such a way that ionic_reset_prepare() and thus ionic_dev_teardown() got called twice in a row. The second time through the workqueue was already destroyed, and destroy_workqueue() choked on the bad wq pointer.  We didn't hit this in AER handler testing before because at that time we weren't using a private workqueue.  Later we replaced the use of the system workqueue with our own private workqueue but hadn't rerun the AER handler testing since then.
CVE-2024-56717: In the Linux kernel, the following vulnerability has been resolved:  net: mscc: ocelot: fix incorrect IFH SRC_PORT field in ocelot_ifh_set_basic()  Packets injected by the CPU should have a SRC_PORT field equal to the CPU port module index in the Analyzer block (ocelot->num_phys_ports).  The blamed commit copied the ocelot_ifh_set_basic() call incorrectly from ocelot_xmit_common() in net/dsa/tag_ocelot.c. Instead of calling with "x", it calls with BIT_ULL(x), but the field is not a port mask, but rather a single port index.  [ side note: this is the technical debt of code duplication :( ]  The error used to be silent and doesn't appear to have other user-visible manifestations, but with new changes in the packing library, it now fails loudly as follows:  ------------[ cut here ]------------ Cannot store 0x40 inside bits 46-43 - will truncate sja1105 spi2.0: xmit timed out WARNING: CPU: 1 PID: 102 at lib/packing.c:98 __pack+0x90/0x198 sja1105 spi2.0: timed out polling for tstamp CPU: 1 UID: 0 PID: 102 Comm: felix_xmit Tainted: G        W        N 6.13.0-rc1-00372-gf706b85d972d-dirty #2605 Call trace:  __pack+0x90/0x198 (P)  __pack+0x90/0x198 (L)  packing+0x78/0x98  ocelot_ifh_set_basic+0x260/0x368  ocelot_port_inject_frame+0xa8/0x250  felix_port_deferred_xmit+0x14c/0x258  kthread_worker_fn+0x134/0x350  kthread+0x114/0x138  The code path pertains to the ocelot switchdev driver and to the felix secondary DSA tag protocol, ocelot-8021q. Here seen with ocelot-8021q.  The messenger (packing) is not really to blame, so fix the original commit instead.
CVE-2024-56718: In the Linux kernel, the following vulnerability has been resolved:  net/smc: protect link down work from execute after lgr freed  link down work may be scheduled before lgr freed but execute after lgr freed, which may result in crash. So it is need to hold a reference before shedule link down work, and put the reference after work executed or canceled.  The relevant crash call stack as follows:  list_del corruption. prev->next should be ffffb638c9c0fe20,     but was 0000000000000000  ------------[ cut here ]------------  kernel BUG at lib/list_debug.c:51!  invalid opcode: 0000 [#1] SMP NOPTI  CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1  Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014  Workqueue: events smc_link_down_work [smc]  RIP: 0010:__list_del_entry_valid.cold+0x31/0x47  RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086  RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000  RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80  RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38  R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002  R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0  FS:  0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  PKRU: 55555554  Call Trace:   rwsem_down_write_slowpath+0x17e/0x470   smc_link_down_work+0x3c/0x60 [smc]   process_one_work+0x1ac/0x350   worker_thread+0x49/0x2f0   ? rescuer_thread+0x360/0x360   kthread+0x118/0x140   ? __kthread_bind_mask+0x60/0x60   ret_from_fork+0x1f/0x30
CVE-2024-56749: In the Linux kernel, the following vulnerability has been resolved:  dlm: fix dlm_recover_members refcount on error  If dlm_recover_members() fails we don't drop the references of the previous created root_list that holds and keep all rsbs alive during the recovery. It might be not an unlikely event because ping_members() could run into an -EINTR if another recovery progress was triggered again.
CVE-2024-56751: In the Linux kernel, the following vulnerability has been resolved:  ipv6: release nexthop on device removal  The CI is hitting some aperiodic hangup at device removal time in the pmtu.sh self-test:  unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6 ref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at  dst_init+0x84/0x4a0  dst_alloc+0x97/0x150  ip6_dst_alloc+0x23/0x90  ip6_rt_pcpu_alloc+0x1e6/0x520  ip6_pol_route+0x56f/0x840  fib6_rule_lookup+0x334/0x630  ip6_route_output_flags+0x259/0x480  ip6_dst_lookup_tail.constprop.0+0x5c2/0x940  ip6_dst_lookup_flow+0x88/0x190  udp_tunnel6_dst_lookup+0x2a7/0x4c0  vxlan_xmit_one+0xbde/0x4a50 [vxlan]  vxlan_xmit+0x9ad/0xf20 [vxlan]  dev_hard_start_xmit+0x10e/0x360  __dev_queue_xmit+0xf95/0x18c0  arp_solicit+0x4a2/0xe00  neigh_probe+0xaa/0xf0  While the first suspect is the dst_cache, explicitly tracking the dst owing the last device reference via probes proved such dst is held by the nexthop in the originating fib6_info.  Similar to commit f5b51fe804ec ("ipv6: route: purge exception on removal"), we need to explicitly release the originating fib info when disconnecting a to-be-removed device from a live ipv6 dst: move the fib6_info cleanup into ip6_dst_ifdown().  Tested running:  ./pmtu.sh cleanup_ipv6_exception  in a tight loop for more than 400 iterations with no spat, running an unpatched kernel  I observed a splat every ~10 iterations.
CVE-2024-56752: In the Linux kernel, the following vulnerability has been resolved:  drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new()  When the call to gf100_grctx_generate() fails, unlock gr->fecs.mutex before returning the error.  Fixes smatch warning:  drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:480 gf100_gr_chan_new() warn: inconsistent returns '&gr->fecs.mutex'.
CVE-2024-56756: In the Linux kernel, the following vulnerability has been resolved:  nvme-pci: fix freeing of the HMB descriptor table  The HMB descriptor table is sized to the maximum number of descriptors that could be used for a given device, but __nvme_alloc_host_mem could break out of the loop earlier on memory allocation failure and end up using less descriptors than planned for, which leads to an incorrect size passed to dma_free_coherent.  In practice this was not showing up because the number of descriptors tends to be low and the dma coherent allocator always allocates and frees at least a page.
CVE-2024-11972: The Hunk Companion WordPress plugin before 1.9.0 does not correctly authorize some REST API endpoints, allowing unauthenticated requests to install and activate arbitrary Hunk Companion WordPress plugin before 1.9.0 from the WordPress.org repo, including vulnerable Hunk Companion WordPress plugin before 1.9.0 that have been closed.
CVE-2024-11184: The wp-enable-svg WordPress plugin through 0.7 does not sanitize SVG files when uploaded, allowing for authors and above to upload SVGs containing malicious scripts
CVE-2024-48455: An issue in Netis Wifi6 Router NX10 2.0.1.3643 and 2.0.1.3582 and Netis Wifi 11AC Router NC65 3.0.0.3749 and Netis Wifi 11AC Router NC63 3.0.0.3327 and 3.0.0.3503 and Netis Wifi 11AC Router NC21 3.0.0.3800, 3.0.0.3500 and 3.0.0.3329 and Netis Wifi Router MW5360 1.0.1.3442 and 1.0.1.3031 allows a remote attacker to obtain sensitive information via the mode_name, wl_link parameters of the skk_get.cgi component.
CVE-2024-53935: The com.callos14.callscreen.colorphone (aka iCall OS17 - Color Phone Flash) application through 4.3 for Android enables any application (with no permissions) to place phone calls without user interaction by sending a crafted intent via the com.callos14.callscreen.colorphone.DialerActivity component.
CVE-2024-54763: An access control issue in the component /login/hostinfo.cgi of ipTIME A2004 v12.17.0 allows attackers to obtain sensitive information without authentication.
CVE-2024-54764: An access control issue in the component /login/hostinfo2.cgi of ipTIME A2004 v12.17.0 allows attackers to obtain sensitive information without authentication.
CVE-2025-0246: When using an invalid protocol scheme, an attacker could spoof the address bar.  *Note: This issue only affected Android operating systems. Other operating systems are unaffected.* *Note: This issue is a different issue from CVE-2025-0244. This vulnerability affects Firefox < 134.