xamxte/cve-to-cwe huggingface dataset:
CVE-2024-43897: In the Linux kernel, the following vulnerability has been resolved:  net: drop bad gso csum_start and offset in virtio_net_hdr  Tighten csum_start and csum_offset checks in virtio_net_hdr_to_skb for GSO packets.  The function already checks that a checksum requested with VIRTIO_NET_HDR_F_NEEDS_CSUM is in skb linear. But for GSO packets this might not hold for segs after segmentation.  Syzkaller demonstrated to reach this warning in skb_checksum_help   offset = skb_checksum_start_offset(skb);  ret = -EINVAL;  if (WARN_ON_ONCE(offset >= skb_headlen(skb)))  By injecting a TSO packet:  WARNING: CPU: 1 PID: 3539 at net/core/dev.c:3284 skb_checksum_help+0x3d0/0x5b0  ip_do_fragment+0x209/0x1b20 net/ipv4/ip_output.c:774  ip_finish_output_gso net/ipv4/ip_output.c:279 [inline]  __ip_finish_output+0x2bd/0x4b0 net/ipv4/ip_output.c:301  iptunnel_xmit+0x50c/0x930 net/ipv4/ip_tunnel_core.c:82  ip_tunnel_xmit+0x2296/0x2c70 net/ipv4/ip_tunnel.c:813  __gre_xmit net/ipv4/ip_gre.c:469 [inline]  ipgre_xmit+0x759/0xa60 net/ipv4/ip_gre.c:661  __netdev_start_xmit include/linux/netdevice.h:4850 [inline]  netdev_start_xmit include/linux/netdevice.h:4864 [inline]  xmit_one net/core/dev.c:3595 [inline]  dev_hard_start_xmit+0x261/0x8c0 net/core/dev.c:3611  __dev_queue_xmit+0x1b97/0x3c90 net/core/dev.c:4261  packet_snd net/packet/af_packet.c:3073 [inline]  The geometry of the bad input packet at tcp_gso_segment:  [   52.003050][ T8403] skb len=12202 headroom=244 headlen=12093 tailroom=0 [   52.003050][ T8403] mac=(168,24) mac_len=24 net=(192,52) trans=244 [   52.003050][ T8403] shinfo(txflags=0 nr_frags=1 gso(size=1552 type=3 segs=0)) [   52.003050][ T8403] csum(0x60000c7 start=199 offset=1536 ip_summed=3 complete_sw=0 valid=0 level=0)  Mitigate with stricter input validation.  csum_offset: for GSO packets, deduce the correct value from gso_type. This is already done for USO. Extend it to TSO. Let UFO be: udp[46]_ufo_fragment ignores these fields and always computes the checksum in software.  csum_start: finding the real offset requires parsing to the transport header. Do not add a parser, use existing segmentation parsing. Thanks to SKB_GSO_DODGY, that also catches bad packets that are hw offloaded. Again test both TSO and USO. Do not test UFO for the above reason, and do not test UDP tunnel offload.  GSO packet are almost always CHECKSUM_PARTIAL. USO packets may be CHECKSUM_NONE since commit 10154dbded6d6 ("udp: Allow GSO transmit from devices with no checksum offload"), but then still these fields are initialized correctly in udp4_hwcsum/udp6_hwcsum_outgoing. So no need to test for ip_summed == CHECKSUM_PARTIAL first.  This revises an existing fix mentioned in the Fixes tag, which broke small packets with GSO offload, as detected by kselftests.
CVE-2024-43914: In the Linux kernel, the following vulnerability has been resolved:  md/raid5: avoid BUG_ON() while continue reshape after reassembling  Currently, mdadm support --revert-reshape to abort the reshape while reassembling, as the test 07revert-grow. However, following BUG_ON() can be triggerred by the test:  kernel BUG at drivers/md/raid5.c:6278! invalid opcode: 0000 [#1] PREEMPT SMP PTI irq event stamp: 158985 CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94 RIP: 0010:reshape_request+0x3f1/0xe60 Call Trace:  <TASK>  raid5_sync_request+0x43d/0x550  md_do_sync+0xb7a/0x2110  md_thread+0x294/0x2b0  kthread+0x147/0x1c0  ret_from_fork+0x59/0x70  ret_from_fork_asm+0x1a/0x30  </TASK>  Root cause is that --revert-reshape update the raid_disks from 5 to 4, while reshape position is still set, and after reassembling the array, reshape position will be read from super block, then during reshape the checking of 'writepos' that is caculated by old reshape position will fail.  Fix this panic the easy way first, by converting the BUG_ON() to WARN_ON(), and stop the reshape if checkings fail.  Noted that mdadm must fix --revert-shape as well, and probably md/raid should enhance metadata validation as well, however this means reassemble will fail and there must be user tools to fix the wrong metadata.
CVE-2024-44931: In the Linux kernel, the following vulnerability has been resolved:  gpio: prevent potential speculation leaks in gpio_device_get_desc()  Userspace may trigger a speculative read of an address outside the gpio descriptor array. Users can do that by calling gpio_ioctl() with an offset out of range. Offset is copied from user and then used as an array index to get the gpio descriptor without sanitization in gpio_device_get_desc().  This change ensures that the offset is sanitized by using array_index_nospec() to mitigate any possibility of speculative information leaks.  This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.
CVE-2024-44942: In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC  syzbot reports a f2fs bug as below:  ------------[ cut here ]------------ kernel BUG at fs/f2fs/inline.c:258! CPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0 RIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258 Call Trace:  f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834  f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline]  __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline]  f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315  do_writepages+0x35b/0x870 mm/page-writeback.c:2612  __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650  writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941  wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117  wb_do_writeback fs/fs-writeback.c:2264 [inline]  wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304  process_one_work kernel/workqueue.c:3254 [inline]  process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335  worker_thread+0x86d/0xd70 kernel/workqueue.c:3416  kthread+0x2f2/0x390 kernel/kthread.c:388  ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244  The root cause is: inline_data inode can be fuzzed, so that there may be valid blkaddr in its direct node, once f2fs triggers background GC to migrate the block, it will hit f2fs_bug_on() during dirty page writeback.  Let's add sanity check on F2FS_INLINE_DATA flag in inode during GC, so that, it can forbid migrating inline_data inode's data block for fixing.
CVE-2024-8105: A vulnerability related to the use an insecure Platform Key (PK) has been discovered. An attacker with the compromised PK private key can create malicious UEFI software that is signed with a trusted key that has been compromised.
CVE-2021-4442: In the Linux kernel, the following vulnerability has been resolved:  tcp: add sanity tests to TCP_QUEUE_SEQ  Qingyu Li reported a syzkaller bug where the repro changes RCV SEQ _after_ restoring data in the receive queue.  mprotect(0x4aa000, 12288, PROT_READ)    = 0 mmap(0x1ffff000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x1ffff000 mmap(0x20000000, 16777216, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x20000000 mmap(0x21000000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x21000000 socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 3 setsockopt(3, SOL_TCP, TCP_REPAIR, [1], 4) = 0 connect(3, {sa_family=AF_INET6, sin6_port=htons(0), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "::1", &sin6_addr), sin6_scope_id=0}, 28) = 0 setsockopt(3, SOL_TCP, TCP_REPAIR_QUEUE, [1], 4) = 0 sendmsg(3, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="0x0000000000000003\0\0", iov_len=20}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 20 setsockopt(3, SOL_TCP, TCP_REPAIR, [0], 4) = 0 setsockopt(3, SOL_TCP, TCP_QUEUE_SEQ, [128], 4) = 0 recvfrom(3, NULL, 20, 0, NULL, NULL)    = -1 ECONNRESET (Connection reset by peer)  syslog shows: [  111.205099] TCP recvmsg seq # bug 2: copied 80, seq 0, rcvnxt 80, fl 0 [  111.207894] WARNING: CPU: 1 PID: 356 at net/ipv4/tcp.c:2343 tcp_recvmsg_locked+0x90e/0x29a0  This should not be allowed. TCP_QUEUE_SEQ should only be used when queues are empty.  This patch fixes this case, and the tx path as well.
CVE-2024-3673: The Web Directory Free WordPress plugin before 1.7.3 does not validate a parameter before using it in an include(), which could lead to Local File Inclusion issues.
CVE-2022-48944: In the Linux kernel, the following vulnerability has been resolved:  sched: Fix yet more sched_fork() races  Where commit 4ef0c5c6b5ba ("kernel/sched: Fix sched_fork() access an invalid sched_task_group") fixed a fork race vs cgroup, it opened up a race vs syscalls by not placing the task on the runqueue before it gets exposed through the pidhash.  Commit 13765de8148f ("sched/fair: Fix fault in reweight_entity") is trying to fix a single instance of this, instead fix the whole class of issues, effectively reverting this commit.
CVE-2024-34637: Improper access control in WindowManagerService prior to SMR Sep-2024 Release 1 in Android 12, and SMR Jun-2024 Release 1 in Android 13 and Android 14 allows local attackers to bypass restrictions on starting services from the background.
CVE-2024-34640: Improper access control vulnerability in BGProtectManager prior to SMR Sep-2024 Release 1 allows local attackers to bypass restriction of process expiration.
CVE-2024-34641: Improper Export of Android Application Components in FeliCaTest prior to SMR Sep-2024 Release 1 allows local attackers to enable NFC configuration.
CVE-2024-34643: Improper access control in key input related function in Dressroom prior to SMR Sep-2024 Release 1 allows local attackers to access protected data. User interaction is required for triggering this vulnerability.
CVE-2024-34644: Improper access control in item selection related in Dressroom prior to SMR Sep-2024 Release 1 allows local attackers to access protected data. User interaction is required for triggering this vulnerability.
CVE-2024-34645: Improper input validation in ThemeCenter prior to SMR Sep-2024 Release 1 allows physical attackers to install privileged applications.
CVE-2024-34646: Improper access control in DualDarManagerProxy prior to SMR Sep-2024 Release 1 allows local attackers to cause local permanent denial of service.
CVE-2024-34647: Incorrect use of privileged API in DualDarManagerProxy prior to SMR Sep-2024 Release 1 allows local attackers to access privileged APIs related to knox without proper license.
CVE-2024-34649: Improper access control in new Dex Mode in multitasking framework prior to SMR Sep-2024 Release 1 allows physical attackers to temporarily access an unlocked screen.
CVE-2024-34654: Improper Export of android application component in My Files prior to SMR Sep-2024 Release 1 allows local attackers to access files with My Files' privilege.
CVE-2024-34655: Incorrect use of privileged API in UniversalCredentialManager prior to SMR Sep-2024 Release 1 allows local attackers to access privileged API related to UniversalCredentialManager.
CVE-2024-7786: The Sensei LMS  WordPress plugin before 4.24.2 does not properly protect some its REST API routes, allowing unauthenticated attackers to leak email templates.
CVE-2024-44950: In the Linux kernel, the following vulnerability has been resolved:  serial: sc16is7xx: fix invalid FIFO access with special register set  When enabling access to the special register set, Receiver time-out and RHR interrupts can happen. In this case, the IRQ handler will try to read from the FIFO thru the RHR register at address 0x00, but address 0x00 is mapped to DLL register, resulting in erroneous FIFO reading.  Call graph example:     sc16is7xx_startup(): entry     sc16is7xx_ms_proc(): entry     sc16is7xx_set_termios(): entry     sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set     sc16is7xx_port_irq() entry            --> IIR is 0x0C     sc16is7xx_handle_rx() entry     sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is                                mapped to DLL (LCR=LCR_CONF_MODE_A)     sc16is7xx_set_baud(): exit --> Restore access to general register set  Fix the problem by claiming the efr_lock mutex when accessing the Special register set.
CVE-2024-44963: In the Linux kernel, the following vulnerability has been resolved:  btrfs: do not BUG_ON() when freeing tree block after error  When freeing a tree block, at btrfs_free_tree_block(), if we fail to create a delayed reference we don't deal with the error and just do a BUG_ON(). The error most likely to happen is -ENOMEM, and we have a comment mentioning that only -ENOMEM can happen, but that is not true, because in case qgroups are enabled any error returned from btrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returned from btrfs_search_slot() for example) can be propagated back to btrfs_free_tree_block().  So stop doing a BUG_ON() and return the error to the callers and make them abort the transaction to prevent leaking space. Syzbot was triggering this, likely due to memory allocation failure injection.
CVE-2024-44967: In the Linux kernel, the following vulnerability has been resolved:  drm/mgag200: Bind I2C lifetime to DRM device  Managed cleanup with devm_add_action_or_reset() will release the I2C adapter when the underlying Linux device goes away. But the connector still refers to it, so this cleanup leaves behind a stale pointer in struct drm_connector.ddc.  Bind the lifetime of the I2C adapter to the connector's lifetime by using DRM's managed release. When the DRM device goes away (after the Linux device) DRM will first clean up the connector and then clean up the I2C adapter.
CVE-2024-44970: In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: SHAMPO, Fix invalid WQ linked list unlink  When all the strides in a WQE have been consumed, the WQE is unlinked from the WQ linked list (mlx5_wq_ll_pop()). For SHAMPO, it is possible to receive CQEs with 0 consumed strides for the same WQE even after the WQE is fully consumed and unlinked. This triggers an additional unlink for the same wqe which corrupts the linked list.  Fix this scenario by accepting 0 sized consumed strides without unlinking the WQE again.
CVE-2024-44976: In the Linux kernel, the following vulnerability has been resolved:  ata: pata_macio: Fix DMA table overflow  Kolbjørn and Jonáš reported that their 32-bit PowerMacs were crashing in pata-macio since commit 09fe2bfa6b83 ("ata: pata_macio: Fix max_segment_size with PAGE_SIZE == 64K").  For example:    kernel BUG at drivers/ata/pata_macio.c:544!   Oops: Exception in kernel mode, sig: 5 [#1]   BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 DEBUG_PAGEALLOC PowerMac   ...   NIP pata_macio_qc_prep+0xf4/0x190   LR  pata_macio_qc_prep+0xfc/0x190   Call Trace:     0xc1421660 (unreliable)     ata_qc_issue+0x14c/0x2d4     __ata_scsi_queuecmd+0x200/0x53c     ata_scsi_queuecmd+0x50/0xe0     scsi_queue_rq+0x788/0xb1c     __blk_mq_issue_directly+0x58/0xf4     blk_mq_plug_issue_direct+0x8c/0x1b4     blk_mq_flush_plug_list.part.0+0x584/0x5e0     __blk_flush_plug+0xf8/0x194     __submit_bio+0x1b8/0x2e0     submit_bio_noacct_nocheck+0x230/0x304     btrfs_work_helper+0x200/0x338     process_one_work+0x1a8/0x338     worker_thread+0x364/0x4c0     kthread+0x100/0x104     start_kernel_thread+0x10/0x14  That commit increased max_segment_size to 64KB, with the justification that the SCSI core was already using that size when PAGE_SIZE == 64KB, and that there was existing logic to split over-sized requests.  However with a sufficiently large request, the splitting logic causes each sg to be split into two commands in the DMA table, leading to overflow of the DMA table, triggering the BUG_ON().  With default settings the bug doesn't trigger, because the request size is limited by max_sectors_kb == 1280, however max_sectors_kb can be increased, and apparently some distros do that by default using udev rules.  Fix the bug for 4KB kernels by reverting to the old max_segment_size.  For 64KB kernels the sg_tablesize needs to be halved, to allow for the possibility that each sg will be split into two.
CVE-2024-44980: In the Linux kernel, the following vulnerability has been resolved:  drm/xe: Fix opregion leak  Being part o the display, ideally the setup and cleanup would be done by display itself. However this is a bigger refactor that needs to be done on both i915 and xe. For now, just fix the leak:  unreferenced object 0xffff8881a0300008 (size 192):   comm "modprobe", pid 4354, jiffies 4295647021   hex dump (first 32 bytes):     00 00 87 27 81 88 ff ff 18 80 9b 00 00 c9 ff ff  ...'............     18 81 9b 00 00 c9 ff ff 00 00 00 00 00 00 00 00  ................   backtrace (crc 99260e31):     [<ffffffff823ce65b>] kmemleak_alloc+0x4b/0x80     [<ffffffff81493be2>] kmalloc_trace_noprof+0x312/0x3d0     [<ffffffffa1345679>] intel_opregion_setup+0x89/0x700 [xe]     [<ffffffffa125bfaf>] xe_display_init_noirq+0x2f/0x90 [xe]     [<ffffffffa1199ec3>] xe_device_probe+0x7a3/0xbf0 [xe]     [<ffffffffa11f3713>] xe_pci_probe+0x333/0x5b0 [xe]     [<ffffffff81af6be8>] local_pci_probe+0x48/0xb0     [<ffffffff81af8778>] pci_device_probe+0xc8/0x280     [<ffffffff81d09048>] really_probe+0xf8/0x390     [<ffffffff81d0937a>] __driver_probe_device+0x8a/0x170     [<ffffffff81d09503>] driver_probe_device+0x23/0xb0     [<ffffffff81d097b7>] __driver_attach+0xc7/0x190     [<ffffffff81d0628d>] bus_for_each_dev+0x7d/0xd0     [<ffffffff81d0851e>] driver_attach+0x1e/0x30     [<ffffffff81d07ac7>] bus_add_driver+0x117/0x250  (cherry picked from commit 6f4e43a2f771b737d991142ec4f6d4b7ff31fbb4)
CVE-2024-44984: In the Linux kernel, the following vulnerability has been resolved:  bnxt_en: Fix double DMA unmapping for XDP_REDIRECT  Remove the dma_unmap_page_attrs() call in the driver's XDP_REDIRECT code path.  This should have been removed when we let the page pool handle the DMA mapping.  This bug causes the warning:  WARNING: CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100 CPU: 7 PID: 59 Comm: ksoftirqd/7 Tainted: G        W          6.8.0-1010-gcp #11-Ubuntu Hardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024 RIP: 0010:iommu_dma_unmap_page+0xd5/0x100 Code: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 RSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c R10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000 R13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002 FS:  0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0 ? show_regs+0x6d/0x80 ? __warn+0x89/0x150 ? iommu_dma_unmap_page+0xd5/0x100 ? report_bug+0x16a/0x190 ? handle_bug+0x51/0xa0 ? exc_invalid_op+0x18/0x80 ? iommu_dma_unmap_page+0xd5/0x100 ? iommu_dma_unmap_page+0x35/0x100 dma_unmap_page_attrs+0x55/0x220 ? bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f bnxt_rx_xdp+0x237/0x520 [bnxt_en] bnxt_rx_pkt+0x640/0xdd0 [bnxt_en] __bnxt_poll_work+0x1a1/0x3d0 [bnxt_en] bnxt_poll+0xaa/0x1e0 [bnxt_en] __napi_poll+0x33/0x1e0 net_rx_action+0x18a/0x2f0
CVE-2024-44988: In the Linux kernel, the following vulnerability has been resolved:  net: dsa: mv88e6xxx: Fix out-of-bound access  If an ATU violation was caused by a CPU Load operation, the SPID could be larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array).
CVE-2024-44991: In the Linux kernel, the following vulnerability has been resolved:  tcp: prevent concurrent execution of tcp_sk_exit_batch  Its possible that two threads call tcp_sk_exit_batch() concurrently, once from the cleanup_net workqueue, once from a task that failed to clone a new netns.  In the latter case, error unwinding calls the exit handlers in reverse order for the 'failed' netns.  tcp_sk_exit_batch() calls tcp_twsk_purge(). Problem is that since commit b099ce2602d8 ("net: Batch inet_twsk_purge"), this function picks up twsk in any dying netns, not just the one passed in via exit_batch list.  This means that the error unwind of setup_net() can "steal" and destroy timewait sockets belonging to the exiting netns.  This allows the netns exit worker to proceed to call  WARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount));  without the expected 1 -> 0 transition, which then splats.  At same time, error unwind path that is also running inet_twsk_purge() will splat as well:  WARNING: .. at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 ...  refcount_dec include/linux/refcount.h:351 [inline]  inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70  inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221  inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304  tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522  ops_exit_list+0x128/0x180 net/core/net_namespace.c:178  setup_net+0x714/0xb40 net/core/net_namespace.c:375  copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508  create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110  ... because refcount_dec() of tw_refcount unexpectedly dropped to 0.  This doesn't seem like an actual bug (no tw sockets got lost and I don't see a use-after-free) but as erroneous trigger of debug check.  Add a mutex to force strict ordering: the task that calls tcp_twsk_purge() blocks other task from doing final _dec_and_test before mutex-owner has removed all tw sockets of dying netns.
CVE-2024-45001: In the Linux kernel, the following vulnerability has been resolved:  net: mana: Fix RX buf alloc_size alignment and atomic op panic  The MANA driver's RX buffer alloc_size is passed into napi_build_skb() to create SKB. skb_shinfo(skb) is located at the end of skb, and its alignment is affected by the alloc_size passed into napi_build_skb(). The size needs to be aligned properly for better performance and atomic operations. Otherwise, on ARM64 CPU, for certain MTU settings like 4000, atomic operations may panic on the skb_shinfo(skb)->dataref due to alignment fault.  To fix this bug, add proper alignment to the alloc_size calculation.  Sample panic info: [  253.298819] Unable to handle kernel paging request at virtual address ffff000129ba5cce [  253.300900] Mem abort info: [  253.301760]   ESR = 0x0000000096000021 [  253.302825]   EC = 0x25: DABT (current EL), IL = 32 bits [  253.304268]   SET = 0, FnV = 0 [  253.305172]   EA = 0, S1PTW = 0 [  253.306103]   FSC = 0x21: alignment fault Call trace:  __skb_clone+0xfc/0x198  skb_clone+0x78/0xe0  raw6_local_deliver+0xfc/0x228  ip6_protocol_deliver_rcu+0x80/0x500  ip6_input_finish+0x48/0x80  ip6_input+0x48/0xc0  ip6_sublist_rcv_finish+0x50/0x78  ip6_sublist_rcv+0x1cc/0x2b8  ipv6_list_rcv+0x100/0x150  __netif_receive_skb_list_core+0x180/0x220  netif_receive_skb_list_internal+0x198/0x2a8  __napi_poll+0x138/0x250  net_rx_action+0x148/0x330  handle_softirqs+0x12c/0x3a0
CVE-2024-45007: In the Linux kernel, the following vulnerability has been resolved:  char: xillybus: Don't destroy workqueue from work item running on it  Triggered by a kref decrement, destroy_workqueue() may be called from within a work item for destroying its own workqueue. This illegal situation is averted by adding a module-global workqueue for exclusive use of the offending work item. Other work items continue to be queued on per-device workqueues to ensure performance.
CVE-2024-45008: In the Linux kernel, the following vulnerability has been resolved:  Input: MT - limit max slots  syzbot is reporting too large allocation at input_mt_init_slots(), for num_slots is supplied from userspace using ioctl(UI_DEV_CREATE).  Since nobody knows possible max slots, this patch chose 1024.
CVE-2024-6846: The Chatbot with ChatGPT WordPress plugin before 2.4.5 does not validate access on some REST routes, allowing for an unauthenticated user to purge error and chat logs
CVE-2024-34155: Calling any of the Parse functions on Go source code which contains deeply nested literals can cause a panic due to stack exhaustion.