xamxte/cve-to-cwe huggingface dataset:
CVE-2024-47855: util/JSONTokener.java in JSON-lib before 3.1.0 mishandles an unbalanced comment string.
CVE-2024-47211: In OpenStack Ironic before 21.4.4, 22.x and 23.x before 23.0.3, 23.x and 24.x before 24.1.3, and 25.x and 26.x before 26.1.0, there is a lack of checksum validation of supplied image_source URLs when configured to convert images to a raw format for streaming.
CVE-2024-34662: Improper access control in ActivityManager prior to SMR Oct-2024 Release 1 in select Android 12, 13 and SMR Sep-2024 Release 1 in select Android 14 allows local attackers to execute privileged behaviors.
CVE-2024-35288: Nitro PDF Pro before 13.70.8.82 and 14.x before 14.26.1.0 allows Local Privilege Escalation in the MSI Installer because custom actions occur unsafely in repair mode. CertUtil is run in a conhost.exe window, and there is a mechanism allowing CTRL+o to launch cmd.exe as NT AUTHORITY\SYSTEM.
CVE-2024-47659: In the Linux kernel, the following vulnerability has been resolved:  smack: tcp: ipv4, fix incorrect labeling  Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write.  Here is a scenario how to see this:  * Take two machines, let's call them C and S,    with active Smack in the default state    (no settings, no rules, no labeled hosts, only builtin labels)  * At S, add Smack rule 'foo bar w'    (labels 'foo' and 'bar' are instantiated at S at this moment)  * At S, at label 'bar', launch a program    that listens for incoming tcp/ipv4 connections  * From C, at label 'foo', connect to the listener at S.    (label 'foo' is instantiated at C at this moment)    Connection succeedes and works.  * Send some data in both directions. * Collect network traffic of this connection.  All packets in both directions are labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized, and even without ever being known at C.  If anybody cares: exactly the same happens with DCCP.  This behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no explanation was provided.  I changed returned packes label into the 'bar', to bring it into line with the Smack documentation claims.
CVE-2024-47665: In the Linux kernel, the following vulnerability has been resolved:  i3c: mipi-i3c-hci: Error out instead on BUG_ON() in IBI DMA setup  Definitely condition dma_get_cache_alignment * defined value > 256 during driver initialization is not reason to BUG_ON(). Turn that to graceful error out with -EINVAL.
CVE-2024-47671: In the Linux kernel, the following vulnerability has been resolved:  USB: usbtmc: prevent kernel-usb-infoleak  The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.
CVE-2024-47498: An Unimplemented or Unsupported Feature in UI vulnerability in the CLI of Juniper Networks Junos OS Evolved on QFX5000 Series allows an unauthenticated, adjacent attacker to cause a Denial-of-Service (DoS).  Several configuration statements meant to enforce limits on MAC learning and moves can be configured but do not take effect. This can lead to control plane overload situations which will severely impact the ability of the device to processes legitimate traffic.    This issue affects Junos OS Evolved on QFX5000 Series:      *  All versions before 21.4R3-S8-EVO,   *  22.2-EVO versions before 22.2R3-S5-EVO,    *  22.4-EVO versions before 22.4R3-EVO,   *  23.2-EVO versions before 23.2R2-EVO.
CVE-2024-21241: Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.39 and prior, 8.4.2 and prior and  9.0.1 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
CVE-2024-21286: Vulnerability in the PeopleSoft Enterprise ELM Enterprise Learning Management product of Oracle PeopleSoft (component: Enterprise Learning Management).   The supported version that is affected is 9.2. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise ELM Enterprise Learning Management.  Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in PeopleSoft Enterprise ELM Enterprise Learning Management, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of PeopleSoft Enterprise ELM Enterprise Learning Management accessible data as well as  unauthorized read access to a subset of PeopleSoft Enterprise ELM Enterprise Learning Management accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N).
CVE-2024-44337: The package `github.com/gomarkdown/markdown` is a Go library for parsing Markdown text and rendering as HTML. Prior to pseudoversion `v0.0.0-20240729232818-a2a9c4f`, which corresponds with commit `a2a9c4f76ef5a5c32108e36f7c47f8d310322252`, there was a logical problem in the paragraph function of the parser/block.go file, which allowed a remote attacker to cause a denial of service (DoS) condition by providing a tailor-made input that caused an infinite loop, causing the program to hang and consume resources indefinitely. Submit `a2a9c4f76ef5a5c32108e36f7c47f8d310322252` contains fixes to this problem.
CVE-2024-9958: Inappropriate implementation in PictureInPicture in Google Chrome prior to 130.0.6723.58 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)
CVE-2024-49400: Tacquito prior to commit 07b49d1358e6ec0b5aa482fcd284f509191119e2 was not properly performing regex matches on authorized commands and arguments. Configured allowed commands/arguments were intended to require a match on the entire string, but instead only enforced a match on a sub-string. That would have potentially allowed unauthorized commands to be executed.
CVE-2024-37404: Improper Input Validation in the admin portal of Ivanti Connect Secure before 22.7R2.1 and 9.1R18.9, or Ivanti Policy Secure before 22.7R1.1 allows a remote authenticated attacker to achieve remote code execution.
CVE-2024-47703: In the Linux kernel, the following vulnerability has been resolved:  bpf, lsm: Add check for BPF LSM return value  A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic.  This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer.  Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.
CVE-2024-47710: In the Linux kernel, the following vulnerability has been resolved:  sock_map: Add a cond_resched() in sock_hash_free()  Several syzbot soft lockup reports all have in common sock_hash_free()  If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.
CVE-2024-47715: In the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: mt7915: fix oops on non-dbdc mt7986  mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE.  Commit 0335c034e726 ("wifi: mt76: fix race condition related to checking tx queue fill status") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices:   Unable to handle kernel read from unreadable memory at virtual address 0000000000000024  Mem abort info:    ESR = 0x0000000096000005    EC = 0x25: DABT (current EL), IL = 32 bits    SET = 0, FnV = 0    EA = 0, S1PTW = 0    FSC = 0x05: level 1 translation fault  Data abort info:    ISV = 0, ISS = 0x00000005    CM = 0, WnR = 0  user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000  [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000  Internal error: Oops: 0000000096000005 [#1] SMP  Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ...  CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0  Hardware name: ZyXEL EX5700 (Telenor) (DT)  pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)  pc : mt76_wcid_cleanup+0x84/0x22c [mt76]  lr : mt76_wcid_cleanup+0x64/0x22c [mt76]  sp : ffffffc00a803700  x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00  x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001  x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8  x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000  x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0  x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000  x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28  x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000  x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001  x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024  Call trace:   mt76_wcid_cleanup+0x84/0x22c [mt76]   __mt76_sta_remove+0x70/0xbc [mt76]   mt76_sta_state+0x8c/0x1a4 [mt76]   mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e]   drv_sta_state+0x144/0x274 [mac80211]   sta_info_move_state+0x1cc/0x2a4 [mac80211]   sta_set_sinfo+0xaf8/0xc24 [mac80211]   sta_info_destroy_addr_bss+0x4c/0x6c [mac80211]    ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211]   cfg80211_check_station_change+0x1360/0x4710 [cfg80211]   genl_family_rcv_msg_doit+0xb4/0x110   genl_rcv_msg+0xd0/0x1bc   netlink_rcv_skb+0x58/0x120   genl_rcv+0x34/0x50   netlink_unicast+0x1f0/0x2ec   netlink_sendmsg+0x198/0x3d0   ____sys_sendmsg+0x1b0/0x210   ___sys_sendmsg+0x80/0xf0   __sys_sendmsg+0x44/0xa0   __arm64_sys_sendmsg+0x20/0x30   invoke_syscall.constprop.0+0x4c/0xe0   do_el0_svc+0x40/0xd0   el0_svc+0x14/0x4c   el0t_64_sync_handler+0x100/0x110   el0t_64_sync+0x15c/0x160  Code: d2800002 910092c0 52800023 f9800011 (885f7c01)  ---[ end trace 7e42dd9a39ed2281 ]---  Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.
CVE-2024-47740: In the Linux kernel, the following vulnerability has been resolved:  f2fs: Require FMODE_WRITE for atomic write ioctls  The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true.  There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways:   - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can    truncate an inode to size 0  - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert    changes another process concurrently made to a file  Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.
CVE-2024-49885: In the Linux kernel, the following vulnerability has been resolved:  mm, slub: avoid zeroing kmalloc redzone  Since commit 946fa0dbf2d8 ("mm/slub: extend redzone check to extra allocated kmalloc space than requested"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone.  Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone.  These issues lead to the following BUG report with "slub_debug=FUZ init_on_free=1":  [    0.000000] ============================================================================= [    0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [    0.000000] ----------------------------------------------------------------------------- [    0.000000] [    0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [    0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [    0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [    0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [    0.000000] [    0.000000] Redzone  ffff000010032850: cc cc cc cc cc cc cc cc                          ........ [    0.000000] Object   ffff000010032858: cc cc cc cc cc cc cc cc                          ........ [    0.000000] Redzone  ffff000010032860: cc cc cc cc cc cc cc cc                          ........ [    0.000000] Padding  ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00              ............ [    0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [    0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [    0.000000] Call trace: [    0.000000]  dump_backtrace+0x90/0xe8 [    0.000000]  show_stack+0x18/0x24 [    0.000000]  dump_stack_lvl+0x74/0x8c [    0.000000]  dump_stack+0x18/0x24 [    0.000000]  print_trailer+0x150/0x218 [    0.000000]  check_object+0xe4/0x454 [    0.000000]  free_to_partial_list+0x2f8/0x5ec  To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area.  When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.
CVE-2024-49887: In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to don't panic system for no free segment fault injection  f2fs: fix to don't panic system for no free segment fault injection  syzbot reports a f2fs bug as below:  F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace:  __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167  f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline]  f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195  f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799  f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903  vfs_fallocate+0x553/0x6c0 fs/open.c:334  do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886  __do_sys_ioctl fs/ioctl.c:905 [inline]  __se_sys_ioctl+0x81/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  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836  The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.
CVE-2024-49902: In the Linux kernel, the following vulnerability has been resolved:  jfs: check if leafidx greater than num leaves per dmap tree  syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf.  Shaggy: Modified sanity check to apply to control pages as well as leaf pages.
CVE-2024-49937: In the Linux kernel, the following vulnerability has been resolved:  wifi: cfg80211: Set correct chandef when starting CAC  When starting CAC in a mode other than AP mode, it return a "WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]" caused by the chandef.chan being null at the end of CAC.  Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC.   Call Trace:   ? show_regs.part.0+0x14/0x16   ? __warn+0x67/0xc0   ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]   ? report_bug+0xa7/0x130   ? exc_overflow+0x30/0x30   ? handle_bug+0x27/0x50   ? exc_invalid_op+0x18/0x60   ? handle_exception+0xf6/0xf6   ? exc_overflow+0x30/0x30   ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]   ? exc_overflow+0x30/0x30   ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]   ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211]   ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211]   ? process_one_work+0x165/0x280   ? worker_thread+0x120/0x3f0   ? kthread+0xc2/0xf0   ? process_one_work+0x280/0x280   ? kthread_complete_and_exit+0x20/0x20   ? ret_from_fork+0x19/0x24  [shorten subject, remove OCB, reorder cases to match previous list]
CVE-2024-49944: In the Linux kernel, the following vulnerability has been resolved:  sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start  In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason.  Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL.    KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]   RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617   Call Trace:    <TASK>    __sys_listen_socket net/socket.c:1883 [inline]    __sys_listen+0x1b7/0x230 net/socket.c:1894    __do_sys_listen net/socket.c:1902 [inline]
CVE-2024-49948: In the Linux kernel, the following vulnerability has been resolved:  net: add more sanity checks to qdisc_pkt_len_init()  One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len.  virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes.  It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes.  - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8  virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size.  We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.
CVE-2024-49951: In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: MGMT: Fix possible crash on mgmt_index_removed  If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace:  0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth]  So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.
CVE-2024-49971: In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Increase array size of dummy_boolean  [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN.  [HOW] Increase dummy_boolean's array size to 3.  This fixes 2 OVERRUN issues reported by Coverity.
CVE-2024-49972: In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Deallocate DML memory if allocation fails  [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL.  [How] Deallocate memory if DML memory allocation fails.
CVE-2024-49973: In the Linux kernel, the following vulnerability has been resolved:  r8169: add tally counter fields added with RTL8125  RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.
CVE-2024-49974: In the Linux kernel, the following vulnerability has been resolved:  NFSD: Limit the number of concurrent async COPY operations  Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector.  Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit.  An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy.  If there is need to make the mechanism more sophisticated, we can visit that in future patches.
CVE-2024-49999: In the Linux kernel, the following vulnerability has been resolved:  afs: Fix the setting of the server responding flag  In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete).  This means that op->server might be NULL, but we don't check that before attempting to set the server flag.
CVE-2024-50010: In the Linux kernel, the following vulnerability has been resolved:  exec: don't WARN for racy path_noexec check  Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 ("exec: move S_ISREG() check earlier") 0fd338b2d2cd ("exec: move path_noexec() check earlier")  Instead of being removed said checks are WARN_ON'ed instead, which has some debug value.  However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag.  One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for.  Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular.  Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN.  Reword the commentary and do small tidy ups while here.  [brauner: keep redundant path_noexec() check]
CVE-2024-50012: In the Linux kernel, the following vulnerability has been resolved:  cpufreq: Avoid a bad reference count on CPU node  In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented.  Address this by declaring the variable with the __free(device_node) cleanup attribute.