yahoo-inc/cve-impacts huggingface dataset:
CVE-2024-26635: In the Linux kernel, the following vulnerability has been resolved:llc: Drop support for ETH_P_TR_802_2.syzbot reported an uninit-value bug below. [0]llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2(0x0011), and syzbot abused the latter to trigger the bug.  write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)llc_conn_handler() initialises local variables {saddr,daddr}.macbased on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passesthem to __llc_lookup().However, the initialisation is done only when skb->protocol ishtons(ETH_P_802_2), otherwise, __llc_lookup_established() and__llc_lookup_listener() will read garbage.The missing initialisation existed prior to commit 211ed865108e("net: delete all instances of special processing for token ring").It removed the part to kick out the token ring stuff but forgot toclose the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().Let's remove llc_tr_packet_type and complete the deprecation.[0]:BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [inline] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6bLocal variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
Key phrases: sneak into llc_rcv().Let's remove llc_tr_packet_type and complete, uninit-value bug
CVE-2024-26637: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: rely on mac80211 debugfs handling for vifmac80211 started to delete debugfs entries in certain cases, causing aath11k to crash when it tried to delete the entries later. Fix this byrelying on mac80211 to delete the entries when appropriate and addingthem from the vif_add_debugfs handler.
Key phrases: crash
CVE-2024-26638: In the Linux kernel, the following vulnerability has been resolved:nbd: always initialize struct msghdr completelysyzbot complains that msg->msg_get_inq value can be uninitialized [1]struct msghdr got many new fields recently, we should always makesure their values is zero by default.[1] BUG: KMSAN: uninit-value in tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571  tcp_recvmsg+0x686/0xac0 net/ipv4/tcp.c:2571  inet_recvmsg+0x131/0x580 net/ipv4/af_inet.c:879  sock_recvmsg_nosec net/socket.c:1044 [inline]  sock_recvmsg+0x12b/0x1e0 net/socket.c:1066  __sock_xmit+0x236/0x5c0 drivers/block/nbd.c:538  nbd_read_reply drivers/block/nbd.c:732 [inline]  recv_work+0x262/0x3100 drivers/block/nbd.c:863  process_one_work kernel/workqueue.c:2627 [inline]  process_scheduled_works+0x104e/0x1e70 kernel/workqueue.c:2700  worker_thread+0xf45/0x1490 kernel/workqueue.c:2781  kthread+0x3ed/0x540 kernel/kthread.c:388  ret_from_fork+0x66/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242Local variable msg created at:  __sock_xmit+0x4c/0x5c0 drivers/block/nbd.c:513  nbd_read_reply drivers/block/nbd.c:732 [inline]  recv_work+0x262/0x3100 drivers/block/nbd.c:863CPU: 1 PID: 7465 Comm: kworker/u5:1 Not tainted 6.7.0-rc7-syzkaller-00041-gf016f7547aee #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023Workqueue: nbd5-recv recv_work
CVE-2024-26639: In the Linux kernel, the following vulnerability has been resolved:mm, kmsan: fix infinite recursion due to RCU critical sectionAlexander Potapenko writes in [1]: "For every memory access in the codeinstrumented by KMSAN we call kmsan_get_metadata() to obtain the metadatafor the memory being accessed.  For virtual memory the metadata pointersare stored in the corresponding `struct page`, therefore we need to callvirt_to_page() to get them.According to the comment in arch/x86/include/asm/page.h,virt_to_page(kaddr) returns a valid pointer iff virt_addr_valid(kaddr) istrue, so KMSAN needs to call virt_addr_valid() as well.To avoid recursion, kmsan_get_metadata() must not call instrumented code,therefore ./arch/x86/include/asm/kmsan.h forks parts ofarch/x86/mm/physaddr.c to check whether a virtual address is valid or not.But the introduction of rcu_read_lock() to pfn_valid() added instrumentedRCU API calls to virt_to_page_or_null(), which is called bykmsan_get_metadata(), so there is an infinite recursion now.  I do notthink it is correct to stop that recursion by doingkmsan_enter_runtime()/kmsan_exit_runtime() in kmsan_get_metadata(): thatwould prevent instrumented functions called from within the runtime fromtracking the shadow values, which might introduce false positives."Fix the issue by switching pfn_valid() to the _sched() variant ofrcu_read_lock/unlock(), which does not require calling into RCU.  Giventhe critical section in pfn_valid() is very small, this is a reasonabletrade-off (with preemptible RCU).KMSAN further needs to be careful to suppress calls into the scheduler,which would be another source of recursion.  This can be done by wrappingthe call to pfn_valid() into preempt_disable/enable_no_resched().  Thedownside is that this sacrifices breaking scheduling guarantees; however,a kernel compiled with KMSAN has already given up any performanceguarantees due to being heavily instrumented.Note, KMSAN code already disables tracing via Makefile, and since mmzone.his included, it is not necessary to use the notrace variant, which isgenerally preferred in all other cases.
Key phrases: obtain the metadatafor
CVE-2024-26640: In the Linux kernel, the following vulnerability has been resolved:tcp: add sanity checks to rx zerocopyTCP rx zerocopy intent is to map pages initially allocatedfrom NIC drivers, not pages owned by a fs.This patch adds to can_map_frag() these additional checks:- Page must not be a compound one.- page->mapping must be NULL.This fixes the panic reported by ZhangPeng.syzbot was able to loopback packets built with sendfile(),mapping pages owned by an ext4 file to TCP rx zerocopy.r3 = socket$inet_tcp(0x2, 0x1, 0x0)mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)r4 = socket$inet_tcp(0x2, 0x1, 0x0)bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\\\\x00',    0x181e42, 0x0)fallocate(r5, 0x0, 0x0, 0x85b8)sendfile(r4, r5, 0x0, 0x8ba0)getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,    &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,    0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40)r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\\\\x00',    0x181e42, 0x0)
CVE-2024-26642: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: disallow anonymous set with timeout flagAnonymous sets are never used with timeout from userspace, reject this.Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.
Key phrases: anonymous set
CVE-2024-26643: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeoutWhile the rhashtable set gc runs asynchronously, a race allows it tocollect elements from anonymous sets with timeouts while it is beingreleased from the commit path.Mingi Cho originally reported this issue in a different path in 6.1.xwith a pipapo set with low timeouts which is not possible upstream since7395dfacfff6 ("netfilter: nf_tables: use timestamp to check for setelement timeout").Fix this by setting on the dead flag for anonymous sets to skip async gcin this case.According to 08e4c8c5919f ("netfilter: nf_tables: mark newset as dead ontransaction abort"), Florian plans to accelerate abort path by releasingobjects via workqueue, therefore, this sets on the dead flag for abortpath too.
Key phrases: check for setelement timeout").Fix this by setting on, race
CVE-2024-26646: In the Linux kernel, the following vulnerability has been resolved:thermal: intel: hfi: Add syscore callbacks for system-wide PMThe kernel allocates a memory buffer and provides its location to thehardware, which uses it to update the HFI table. This allocation occursduring boot and remains constant throughout runtime.When resuming from hibernation, the restore kernel allocates a secondmemory buffer and reprograms the HFI hardware with the new location aspart of a normal boot. The location of the second memory buffer maydiffer from the one allocated by the image kernel.When the restore kernel transfers control to the image kernel, its HFIbuffer becomes invalid, potentially leading to memory corruption if thehardware writes to it (the hardware continues to use the buffer from therestore kernel).It is also possible that the hardware "forgets" the address of the memorybuffer when resuming from "deep" suspend. Memory corruption may also occurin such a scenario.To prevent the described memory corruption, disable HFI when preparing tosuspend or hibernate. Enable it when resuming.Add syscore callbacks to handle the package of the boot CPU (packages ofnon-boot CPUs are handled via CPU offline). Syscore ops always run on theboot CPU. Additionally, HFI only needs to be disabled during "deep" suspendand hibernation. Syscore ops only run in these cases.[ rjw: Comment adjustment, subject and changelog edits ]
Key phrases: memory corruption
CVE-2024-26647: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix late derefrence 'dsc' check in 'link_set_dsc_pps_packet()'In link_set_dsc_pps_packet(), 'struct display_stream_compressor *dsc'was dereferenced in a DC_LOGGER_INIT(dsc->ctx->logger); before the 'dsc'NULL pointer check.Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_dpms.c:905 link_set_dsc_pps_packet() warn: variable dereferenced before check 'dsc' (see line 903)
CVE-2024-26648: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix variable deferencing before NULL check in edp_setup_replay()In edp_setup_replay(), 'struct dc *dc' & 'struct dmub_replay *replay'was dereferenced before the pointer 'link' & 'replay' NULL check.Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_edp_panel_control.c:947 edp_setup_replay() warn: variable dereferenced before check 'link' (see line 933)
CVE-2024-26649: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix the null pointer when load rlc firmwareIf the RLC firmware is invalid because of wrong header size,the pointer to the rlc firmware is released in functionamdgpu_ucode_request. There will be a null pointer errorin subsequent use. So skip validation to fix it.
Key phrases: null pointer
CVE-2024-26650: In the Linux kernel, the following vulnerability has been resolved:platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probep2sb_bar() unhides P2SB device to get resources from the device. Itguards the operation by locking pci_rescan_remove_lock so that parallelrescans do not find the P2SB device. However, this lock causes deadlockwhen PCI bus rescan is triggered by /sys/bus/pci/rescan. The rescanlocks pci_rescan_remove_lock and probes PCI devices. When PCI devicescall p2sb_bar() during probe, it locks pci_rescan_remove_lock again.Hence the deadlock.To avoid the deadlock, do not lock pci_rescan_remove_lock in p2sb_bar().Instead, do the lock at fs_initcall. Introduce p2sb_cache_resources()for fs_initcall which gets and caches the P2SB resources. At p2sb_bar(),refer the cache and return to the caller.Before operating the device at P2SB DEVFN for resource cache, checkthat its device class is PCI_CLASS_MEMORY_OTHER 0x0580 that PCHspecifications define. This avoids unexpected operation to other devicesat the same DEVFN.Tested-by Klara Modin <klarasmodin@gmail.com>
Key phrases: get resources from the device
CVE-2024-26651: In the Linux kernel, the following vulnerability has been resolved:sr9800: Add check for usbnet_get_endpointsAdd check for usbnet_get_endpoints() and return the error if it failsin order to transfer the error.
CVE-2024-26652: In the Linux kernel, the following vulnerability has been resolved:net: pds_core: Fix possible double free in error handling pathWhen auxiliary_device_add() returns error and then callsauxiliary_device_uninit(), Callback function pdsc_auxbus_dev_releasecalls kfree(padev) to free memory. We shouldn't call kfree(padev)again in the error handling path.Fix this by cleaning up the redundant kfree() and puttingthe error handling back to where the errors happened.
Key phrases: double free
CVE-2024-26653: In the Linux kernel, the following vulnerability has been resolved:usb: misc: ljca: Fix double free in error handling pathWhen auxiliary_device_add() returns error and then callsauxiliary_device_uninit(), callback function ljca_auxdev_releasecalls kfree(auxdev->dev.platform_data) to free the parameter dataof the function ljca_new_client_device. The callers ofljca_new_client_device shouldn't call kfree() againin the error handling path to free the platform data.Fix this by cleaning up the redundant kfree() in all callers andadding kfree() the passed in platform_data on errors which happenbefore auxiliary_device_init() succeeds .
Key phrases: double free
CVE-2024-26654: In the Linux kernel, the following vulnerability has been resolved:ALSA: sh: aica: reorder cleanup operations to avoid UAF bugsThe dreamcastcard->timer could schedule the spu_dma_work and thespu_dma_work could also arm the dreamcastcard->timer.When the snd_pcm_substream is closing, the aica_channel will bedeallocated. But it could still be dereferenced in the workerthread. The reason is that del_timer() will return directlyregardless of whether the timer handler is running or not andthe worker could be rescheduled in the timer handler. As a result,the UAF bug will happen. The racy situation is shown below:      (Thread 1)                 |      (Thread 2)snd_aicapcm_pcm_close()          | ...                             |  run_spu_dma() //worker                                 |    mod_timer()  flush_work()                   |  del_timer()                    |  aica_period_elapsed() //timer  kfree(dreamcastcard->channel)  |    schedule_work()                                 |  run_spu_dma() //worker  ...                            |    dreamcastcard->channel-> //USEIn order to mitigate this bug and other possible corner cases,call mod_timer() conditionally in run_spu_dma(), then implementPCM sync_stop op to cancel both the timer and worker. The sync_stopop will be called from PCM core appropriately when needed.
Key phrases: uaf bugsthe
CVE-2024-26655: In the Linux kernel, the following vulnerability has been resolved:Fix memory leak in posix_clock_open()If the clk ops.open() function returns an error, we don't release thepccontext we allocated for this clock.Re-organize the code slightly to make it all more obvious.
Key phrases: memory leak
CVE-2024-26659: In the Linux kernel, the following vulnerability has been resolved:xhci: handle isoc Babble and Buffer Overrun events properlyxHCI 4.9 explicitly forbids assuming that the xHC has released itsownership of a multi-TRB TD when it reports an error on one of theearly TRBs. Yet the driver makes such assumption and releases the TD,allowing the remaining TRBs to be freed or overwritten by new TDs.The xHC should also report completion of the final TRB due to its IOCflag being set by us, regardless of prior errors. This event cannotbe recognized if the TD has already been freed earlier, resulting in"Transfer event TRB DMA ptr not part of current TD" error message.Fix this by reusing the logic for processing isoc Transaction Errors.This also handles hosts which fail to report the final completion.Fix transfer length reporting on Babble errors. They may be caused bydevice malfunction, no guarantee that the buffer has been filled.
Key phrases: be freed or overwritten by new TDs
CVE-2024-26660: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Implement bounds check for stream encoder creation in DCN301'stream_enc_regs' array is an array of dcn10_stream_enc_registersstructures. The array is initialized with four elements, correspondingto the four calls to stream_enc_regs() in the array initializer. Thismeans that valid indices for this array are 0, 1, 2, and 3.The error message 'stream_enc_regs' 4 <= 5 below, is indicating thatthere is an attempt to access this array with an index of 5, which isout of bounds. This could lead to undefined behaviorHere, eng_id is used as an index to access the stream_enc_regs array. Ifeng_id is 5, this would result in an out-of-bounds access on thestream_enc_regs array.Thus fixing Buffer overflow error in dcn301_stream_encoder_createreported by Smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5
Key phrases: out of bounds access, buffer overflow
CVE-2024-26661: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'In "u32 otg_inst = pipe_ctx->stream_res.tg->inst;"pipe_ctx->stream_res.tg could be NULL, it is relying on the caller toensure the tg is not NULL.
CVE-2024-26662: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()''panel_cntl' structure used to control the display panel could be null,dereferencing it could lead to a null pointer access.Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn21/dcn21_hwseq.c:269 dcn21_set_backlight_level() error: we previously assumed 'panel_cntl' could be null (see line 250)
Key phrases: null pointer access
CVE-2024-26663: In the Linux kernel, the following vulnerability has been resolved:tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()syzbot reported the following general protection fault [1]:general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087]...RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291...Call Trace: <TASK> tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972 genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline] genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bThe cause of this issue is that when tipc_nl_bearer_add() is called withthe TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is calledeven if the bearer is not UDP.tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes thatthe media_ptr field of the tipc_bearer has an udp_bearer type object, sothe function goes crazy for non-UDP bearers.This patch fixes the issue by checking the bearer type before callingtipc_udp_nl_bearer_add() in tipc_nl_bearer_add().
CVE-2024-26664: In the Linux kernel, the following vulnerability has been resolved:hwmon: (coretemp) Fix out-of-bounds memory accessFix a bug that pdata->cpu_map[] is set before out-of-bounds check.The problem might be triggered on systems with more than 128 cores perpackage.
Key phrases: out-of-bounds memory accessfix, out of bounds memory
CVE-2024-26665: In the Linux kernel, the following vulnerability has been resolved:tunnels: fix out of bounds access when building IPv6 PMTU errorIf the ICMPv6 error is built from a non-linear skb we get the followingsplat,  BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240  Read of size 4 at addr ffff88811d402c80 by task netperf/820  CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543  ...   kasan_report+0xd8/0x110   do_csum+0x220/0x240   csum_partial+0xc/0x20   skb_tunnel_check_pmtu+0xeb9/0x3280   vxlan_xmit_one+0x14c2/0x4080   vxlan_xmit+0xf61/0x5c00   dev_hard_start_xmit+0xfb/0x510   __dev_queue_xmit+0x7cd/0x32a0   br_dev_queue_push_xmit+0x39d/0x6a0Use skb_checksum instead of csum_partial who cannot deal with non-linearSKBs.
Key phrases: out of bounds access
CVE-2024-26666: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix RCU use in TDLS fast-xmitThis looks up the link under RCU protection, but isn'tguaranteed to actually have protection. Fix that.
CVE-2024-26667: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dpu: check for valid hw_pp in dpu_encoder_helper_phys_cleanupThe commit 8b45a26f2ba9 ("drm/msm/dpu: reserve cdm blocks for writebackin case of YUV output") introduced a smatch warning about anotherconditional block in dpu_encoder_helper_phys_cleanup() which had assumedhw_pp will always be valid which may not necessarily be true.Lets fix the other conditional block by making sure hw_pp is validbefore dereferencing it.Patchwork: https://patchwork.freedesktop.org/patch/574878/
CVE-2024-26668: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_limit: reject configurations that cause integer overflowReject bogus configs where internal token counter wraps around.This only occurs with very very large requests, such as 17gbyte/s.Its better to reject this rather than having incorrect ratelimit.
Key phrases: integer overflowreject, bogus configs
CVE-2024-26670: In the Linux kernel, the following vulnerability has been resolved:arm64: entry: fix ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOADCurrently the ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround isn'tquite right, as it is supposed to be applied after the last explicitmemory access, but is immediately followed by an LDR.The ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround is used tohandle Cortex-A520 erratum 2966298 and Cortex-A510 erratum 3117295,which are described in:* https://developer.arm.com/documentation/SDEN2444153/0600/?lang=en* https://developer.arm.com/documentation/SDEN1873361/1600/?lang=enIn both cases the workaround is described as:| If pagetable isolation is disabled, the context switch logic in the| kernel can be updated to execute the following sequence on affected| cores before exiting to EL0, and after all explicit memory accesses:|| 1. A non-shareable TLBI to any context and/or address, including|    unused contexts or addresses, such as a `TLBI VALE1 Xzr`.|| 2. A DSB NSH to guarantee completion of the TLBI.The important part being that the TLBI+DSB must be placed "after allexplicit memory accesses".Unfortunately, as-implemented, the TLBI+DSB is immediately followed byan LDR, as we have:| alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD| 	tlbi	vale1, xzr| 	dsb	nsh| alternative_else_nop_endif| alternative_if_not ARM64_UNMAP_KERNEL_AT_EL0| 	ldr	lr, [sp, #S_LR]| 	add	sp, sp, #PT_REGS_SIZE		// restore sp| 	eret| alternative_else_nop_endif|| [ ... KPTI exception return path ... ]This patch fixes this by reworking the logic to place the TLBI+DSBimmediately before the ERET, after all explicit memory accesses.The ERET is currently in a separate alternative block, and alternativescannot be nested. To account for this, the alternative block forARM64_UNMAP_KERNEL_AT_EL0 is replaced with a single alternative branchto skip the KPTI logic, with the new shape of the logic being:| alternative_insn "b .L_skip_tramp_exit_\\\\@", nop, ARM64_UNMAP_KERNEL_AT_EL0| 	[ ... KPTI exception return path ... ]| .L_skip_tramp_exit_\\\\@:|| 	ldr	lr, [sp, #S_LR]| 	add	sp, sp, #PT_REGS_SIZE		// restore sp|| alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD| 	tlbi	vale1, xzr| 	dsb	nsh| alternative_else_nop_endif| 	eretThe new structure means that the workaround is only applied when KPTI isnot in use; this is fine as noted in the documented implications of theerratum:| Pagetable isolation between EL0 and higher level ELs prevents the| issue from occurring.... and as per the workaround description quoted above, the workaroundis only necessary "If pagetable isolation is disabled".
CVE-2024-26671: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix IO hang from sbitmap wakeup raceIn blk_mq_mark_tag_wait(), __add_wait_queue() may be re-orderedwith the following blk_mq_get_driver_tag() in case of getting drivertag failure.Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observethe added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantimeblk_mq_mark_tag_wait() can't get driver tag successfully.This issue can be reproduced by running the following test in loop, andfio hang can be observed in < 30min when running it on my test VMin laptop.	modprobe -r scsi_debug	modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4	dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`	fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \\\\       		--runtime=100 --numjobs=40 --time_based --name=test \\\\        	--ioengine=libaioFix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), whichis just fine in case of running out of tag.
Key phrases: hang
CVE-2024-26672: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()'Fixes the below:drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() warn: variable dereferenced before check 'mca_funcs' (see line 368)357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev,				     enum amdgpu_mca_error_type type,358                                  int idx, struct mca_bank_entry *entry)359 {360         const struct amdgpu_mca_smu_funcs *mca_funcs =						adev->mca.mca_funcs;361         int count;362363         switch (type) {364         case AMDGPU_MCA_ERROR_TYPE_UE:365                 count = mca_funcs->max_ue_count;mca_funcs is dereferenced here.366                 break;367         case AMDGPU_MCA_ERROR_TYPE_CE:368                 count = mca_funcs->max_ce_count;mca_funcs is dereferenced here.369                 break;370         default:371                 return -EINVAL;372         }373374         if (idx >= count)375                 return -EINVAL;376377         if (mca_funcs && mca_funcs->mca_get_mca_entry)	        ^^^^^^^^^Checked too late!
CVE-2024-26673: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.- Disallow layer 4 protocol with no ports, since destination port is a  mandatory attribute for this object.
CVE-2024-26674: In the Linux kernel, the following vulnerability has been resolved:x86/lib: Revert to _ASM_EXTABLE_UA() for {get,put}_user() fixupsDuring memory error injection test on kernels >= v6.4, the kernel panicslike below. However, this issue couldn't be reproduced on kernels <= v6.3.  mce: [Hardware Error]: CPU 296: Machine Check Exception: f Bank 1: bd80000000100134  mce: [Hardware Error]: RIP 10:<ffffffff821b9776> {__get_user_nocheck_4+0x6/0x20}  mce: [Hardware Error]: TSC 411a93533ed ADDR 346a8730040 MISC 86  mce: [Hardware Error]: PROCESSOR 0:a06d0 TIME 1706000767 SOCKET 1 APIC 211 microcode 80001490  mce: [Hardware Error]: Run the above through 'mcelog --ascii'  mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel  Kernel panic - not syncing: Fatal local machine checkThe MCA code can recover from an in-kernel #MC if the fixup type isEX_TYPE_UACCESS, explicitly indicating that the kernel is attempting toaccess userspace memory. However, if the fixup type is EX_TYPE_DEFAULTthe only thing that is raised for an in-kernel #MC is a panic.ex_handler_uaccess() would warn if users gave a non-canonical addresses(with bit 63 clear) to {get, put}_user(), which was unexpected.Therefore, commit  b19b74bc99b1 ("x86/mm: Rework address range check in get_user() and put_user()")replaced _ASM_EXTABLE_UA() with _ASM_EXTABLE() for {get, put}_user()fixups. However, the new fixup type EX_TYPE_DEFAULT results in a panic.Commit  6014bc27561f ("x86-64: make access_ok() independent of LAM")added the check gp_fault_address_ok() right before the WARN_ONCE() inex_handler_uaccess() to not warn about non-canonical user addresses dueto LAM.With that in place, revert back to _ASM_EXTABLE_UA() for {get,put}_user()exception fixups in order to be able to handle in-kernel MCEs correctlyagain.  [ bp: Massage commit message. ]
Key phrases: memory error injection test
CVE-2024-26675: In the Linux kernel, the following vulnerability has been resolved:ppp_async: limit MRU to 64Ksyzbot triggered a warning [1] in __alloc_pages():WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K")Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)[1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543Modules linked in:CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023Workqueue: events_unbound flush_to_ldiscpstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537sp : ffff800093967580x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003fx5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0Call trace:  __alloc_pages+0x308/0x698 mm/page_alloc.c:4543  __alloc_pages_node include/linux/gfp.h:238 [inline]  alloc_pages_node include/linux/gfp.h:261 [inline]  __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926  __do_kmalloc_node mm/slub.c:3969 [inline]  __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001  kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590  __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651  __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715  netdev_alloc_skb include/linux/skbuff.h:3235 [inline]  dev_alloc_skb include/linux/skbuff.h:3248 [inline]  ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline]  ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341  tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390  tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37  receive_buf drivers/tty/tty_buffer.c:444 [inline]  flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494  process_one_work+0x694/0x1204 kernel/workqueue.c:2633  process_scheduled_works kernel/workqueue.c:2706 [inline]  worker_thread+0x938/0xef4 kernel/workqueue.c:2787  kthread+0x288/0x310 kernel/kthread.c:388  ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
CVE-2024-26677: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix delayed ACKs to not set the reference serial numberFix the construction of delayed ACKs to not set the reference serial numberas they can't be used as an RTT reference.
Key phrases: rxrpc, delayed acks
CVE-2024-26678: In the Linux kernel, the following vulnerability has been resolved:x86/efistub: Use 1:1 file:memory mapping for PE/COFF .compat sectionThe .compat section is a dummy PE section that contains the address ofthe 32-bit entrypoint of the 64-bit kernel image if it is bootable from32-bit firmware (i.e., CONFIG_EFI_MIXED=y)This section is only 8 bytes in size and is only referenced from theloader, and so it is placed at the end of the memory view of the image,to avoid the need for padding it to 4k, which is required for sectionsappearing in the middle of the image.Unfortunately, this violates the PE/COFF spec, and even if most EFIloaders will work correctly (including the Tianocore referenceimplementation), PE loaders do exist that reject such images, on thebasis that both the file and memory views of the file contents should bedescribed by the section headers in a monotonically increasing mannerwithout leaving any gaps.So reorganize the sections to avoid this issue. This results in a slightpadding overhead (< 4k) which can be avoided if desired by disablingCONFIG_EFI_MIXED (which is only needed in rare cases these days)
Key phrases: efistub
CVE-2024-26679: In the Linux kernel, the following vulnerability has been resolved:inet: read sk->sk_family once in inet_recv_error()inet_recv_error() is called without holding the socket lock.IPv6 socket could mutate to IPv4 with IPV6_ADDRFORMsocket option and trigger a KCSAN warning.
CVE-2024-2668: A vulnerability has been found in Campcodes Online Job Finder System 1.0 and classified as critical. This vulnerability affects unknown code of the file /admin/vacancy/controller.php. The manipulation of the argument id/CATEGORY leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-257368.
Key phrases: sql injection
CVE-2024-26680: In the Linux kernel, the following vulnerability has been resolved:net: atlantic: Fix DMA mapping for PTP hwts ringFunction aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytesfor PTP HWTS ring but then generic aq_ring_free() does not take thisinto account.Create and use a specific function to free HWTS ring to fix thisissue.Trace:[  215.351607] ------------[ cut here ]------------[  215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes][  215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360...[  215.581176] Call Trace:[  215.583632]  <TASK>[  215.585745]  ? show_trace_log_lvl+0x1c4/0x2df[  215.590114]  ? show_trace_log_lvl+0x1c4/0x2df[  215.594497]  ? debug_dma_free_coherent+0x196/0x210[  215.599305]  ? check_unmap+0xa6f/0x2360[  215.603147]  ? __warn+0xca/0x1d0[  215.606391]  ? check_unmap+0xa6f/0x2360[  215.610237]  ? report_bug+0x1ef/0x370[  215.613921]  ? handle_bug+0x3c/0x70[  215.617423]  ? exc_invalid_op+0x14/0x50[  215.621269]  ? asm_exc_invalid_op+0x16/0x20[  215.625480]  ? check_unmap+0xa6f/0x2360[  215.629331]  ? mark_lock.part.0+0xca/0xa40[  215.633445]  debug_dma_free_coherent+0x196/0x210[  215.638079]  ? __pfx_debug_dma_free_coherent+0x10/0x10[  215.643242]  ? slab_free_freelist_hook+0x11d/0x1d0[  215.648060]  dma_free_attrs+0x6d/0x130[  215.651834]  aq_ring_free+0x193/0x290 [atlantic][  215.656487]  aq_ptp_ring_free+0x67/0x110 [atlantic]...[  216.127540] ---[ end trace 6467e5964dd2640b ]---[  216.132160] DMA-API: Mapped at:[  216.132162]  debug_dma_alloc_coherent+0x66/0x2f0[  216.132165]  dma_alloc_attrs+0xf5/0x1b0[  216.132168]  aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic][  216.132193]  aq_ptp_ring_alloc+0x1bb/0x540 [atlantic][  216.132213]  aq_nic_init+0x4a1/0x760 [atlantic]
CVE-2024-26681: In the Linux kernel, the following vulnerability has been resolved:netdevsim: avoid potential loop in nsim_dev_trap_report_work()Many syzbot reports include the following trace [1]If nsim_dev_trap_report_work() can not grab the mutex,it should rearm itself at least one jiffie later.[1]Sending NMI from CPU 1 to CPUs 0:NMI backtrace for cpu 0CPU: 0 PID: 32383 Comm: kworker/0:2 Not tainted 6.8.0-rc2-syzkaller-00031-g861c0981648f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023Workqueue: events nsim_dev_trap_report_work RIP: 0010:bytes_is_nonzero mm/kasan/generic.c:89 [inline] RIP: 0010:memory_is_nonzero mm/kasan/generic.c:104 [inline] RIP: 0010:memory_is_poisoned_n mm/kasan/generic.c:129 [inline] RIP: 0010:memory_is_poisoned mm/kasan/generic.c:161 [inline] RIP: 0010:check_region_inline mm/kasan/generic.c:180 [inline] RIP: 0010:kasan_check_range+0x101/0x190 mm/kasan/generic.c:189Code: 07 49 39 d1 75 0a 45 3a 11 b8 01 00 00 00 7c 0b 44 89 c2 e8 21 ed ff ff 83 f0 01 5b 5d 41 5c c3 48 85 d2 74 4f 48 01 ea eb 09 <48> 83 c0 01 48 39 d0 74 41 80 38 00 74 f2 eb b6 41 bc 08 00 00 00RSP: 0018:ffffc90012dcf998 EFLAGS: 00000046RAX: fffffbfff258af1e RBX: fffffbfff258af1f RCX: ffffffff8168eda3RDX: fffffbfff258af1f RSI: 0000000000000004 RDI: ffffffff92c578f0RBP: fffffbfff258af1e R08: 0000000000000000 R09: fffffbfff258af1eR10: ffffffff92c578f3 R11: ffffffff8acbcbc0 R12: 0000000000000002R13: ffff88806db38400 R14: 1ffff920025b9f42 R15: ffffffff92c578e8FS:  0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000c00994e078 CR3: 000000002c250000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: <NMI> </NMI> <TASK>  instrument_atomic_read include/linux/instrumented.h:68 [inline]  atomic_read include/linux/atomic/atomic-instrumented.h:32 [inline]  queued_spin_is_locked include/asm-generic/qspinlock.h:57 [inline]  debug_spin_unlock kernel/locking/spinlock_debug.c:101 [inline]  do_raw_spin_unlock+0x53/0x230 kernel/locking/spinlock_debug.c:141  __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:150 [inline]  _raw_spin_unlock_irqrestore+0x22/0x70 kernel/locking/spinlock.c:194  debug_object_activate+0x349/0x540 lib/debugobjects.c:726  debug_work_activate kernel/workqueue.c:578 [inline]  insert_work+0x30/0x230 kernel/workqueue.c:1650  __queue_work+0x62e/0x11d0 kernel/workqueue.c:1802  __queue_delayed_work+0x1bf/0x270 kernel/workqueue.c:1953  queue_delayed_work_on+0x106/0x130 kernel/workqueue.c:1989  queue_delayed_work include/linux/workqueue.h:563 [inline]  schedule_delayed_work include/linux/workqueue.h:677 [inline]  nsim_dev_trap_report_work+0x9c0/0xc80 drivers/net/netdevsim/dev.c:842  process_one_work+0x886/0x15d0 kernel/workqueue.c:2633  process_scheduled_works kernel/workqueue.c:2706 [inline]  worker_thread+0x8b9/0x1290 kernel/workqueue.c:2787  kthread+0x2c6/0x3a0 kernel/kthread.c:388  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 </TASK>
CVE-2024-26682: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: improve CSA/ECSA connection refusalAs mentioned in the previous commit, we pretty quickly foundthat some APs have ECSA elements stuck in their probe response,so using that to not attempt to connect while CSA is happeningwe never connect to such an AP.Improve this situation by checking more carefully and ignoringthe ECSA if cfg80211 has previously detected the ECSA elementbeing stuck in the probe response.Additionally, allow connecting to an AP that's switching to achannel it's already using, unless it's using quiet mode. Inthis case, we may just have to adjust bandwidth later. If it'sactually switching channels, it's better not to try to connectin the middle of that.
Key phrases: an AP that's switching to achannel it
CVE-2024-26683: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: detect stuck ECSA element in probe respWe recently added some validation that we don't try toconnect to an AP that is currently in a channel switchprocess, since that might want the channel to be quietor we might not be able to connect in time to hear theswitching in a beacon. This was in commit c09c4f31998b("wifi: mac80211: don't connect to an AP while it's ina CSA process").However, we promptly got a report that this caused newconnection failures, and it turns out that the AP thatwe now cannot connect to is permanently advertising anextended channel switch announcement, even with quiet.The AP in question was an Asus RT-AC53, with firmware3.0.0.4.380_10760-g21a5898.As a first step, attempt to detect that we're dealingwith such a situation, so mac80211 can use this later.
CVE-2024-26684: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: xgmac: fix handling of DPP safety error for DMA channelsCommit 56e58d6c8a56 ("net: stmmac: Implement Safety Features inXGMAC core") checks and reports safety errors, but leaves theData Path Parity Errors for each channel in DMA unhandled at all, lead toa storm of interrupt.Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.
Key phrases: storm of interrupt
CVE-2024-26685: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix potential bug in end_buffer_async_writeAccording to a syzbot report, end_buffer_async_write(), which handles thecompletion of block device writes, may detect abnormal condition of thebuffer async_write flag and cause a BUG_ON failure when using nilfs2.Nilfs2 itself does not use end_buffer_async_write().  But, the async_writeflag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issuewith race condition of competition between segments for dirty blocks") asa means of resolving double list insertion of dirty blocks innilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and theresulting crash.This modification is safe as long as it is used for file data and b-treenode blocks where the page caches are independent.  However, it wasirrelevant and redundant to also introduce async_write for segment summaryand super root blocks that share buffers with the backing device.  Thisled to the possibility that the BUG_ON check in end_buffer_async_writewould fail as described above, if independent writebacks of the backingdevice occurred in parallel.The use of async_write for segment summary buffers has already beenremoved in a previous change.Fix this issue by removing the manipulation of the async_write flag forthe remaining super root block buffer.
Key phrases: race condition
CVE-2024-26686: In the Linux kernel, the following vulnerability has been resolved:fs/proc: do_task_stat: use sig->stats_lock to gather the threads/children statslock_task_sighand() can trigger a hard lockup.  If NR_CPUS threads calldo_task_stat() at the same time and the process has NR_THREADS, it willspin with irqs disabled O(NR_CPUS * NR_THREADS) time.Change do_task_stat() to use sig->stats_lock to gather the statisticsoutside of ->siglock protected section, in the likely case this code willrun lockless.
CVE-2024-26689: In the Linux kernel, the following vulnerability has been resolved:ceph: prevent use-after-free in encode_cap_msg()In fs/ceph/caps.c, in encode_cap_msg(), "use after free" error wascaught by KASAN at this line - 'ceph_buffer_get(arg->xattr_buf);'. Thisimplies before the refcount could be increment here, it was freed.In same file, in "handle_cap_grant()" refcount is decremented by thisline - 'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a raceoccurred and resource was freed by the latter line before the formerline could increment it.encode_cap_msg() is called by __send_cap() and __send_cap() is called byceph_check_caps() after calling __prep_cap(). __prep_cap() is wherearg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot wherethe refcount must be increased to prevent "use after free" error.
Key phrases: use-after-free, use after free
CVE-2024-2669: A vulnerability was found in Campcodes Online Job Finder System 1.0 and classified as critical. This issue affects some unknown processing of the file /admin/employee/controller.php of the component GET Parameter Handler. The manipulation of the argument EMPLOYEEID leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-257369 was assigned to this vulnerability.
Key phrases: sql injection
CVE-2024-26690: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: protect updates of 64-bit statistics countersAs explained by a comment in <linux/u64_stats_sync.h>, write side of structu64_stats_sync must ensure mutual exclusion, or one seqcount update couldbe lost on 32-bit platforms, thus blocking readers forever. Such lockupshave been observed in real world after stmmac_xmit() on one CPU raced withstmmac_napi_poll_tx() on another CPU.To fix the issue without introducing a new lock, split the statics intothree parts:1. fields updated only under the tx queue lock,2. fields updated only during NAPI poll,3. fields updated only from interrupt context,Updates to fields in the first two groups are already serialized throughother locks. It is sufficient to split the existing struct u64_stats_syncso that each group has its own.Note that tx_set_ic_bit is updated from both contexts. Split this counterso that each context gets its own, and calculate their sum to get the totalvalue in stmmac_get_ethtool_stats().For the third group, multiple interrupts may be processed by different CPUsat the same time, but interrupts on the same CPU will not nest. Move fieldsfrom this group to a newly created per-cpu struct stmmac_pcpu_stats.
CVE-2024-26691: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Fix circular locking dependencyThe rule inside kvm enforces that the vcpu->mutex is taken *inside*kvm->lock. The rule is violated by the pkvm_create_hyp_vm() which acquiresthe kvm->lock while already holding the vcpu->mutex lock fromkvm_vcpu_ioctl(). Avoid the circular locking dependency altogether byprotecting the hyp vm handle with the config_lock, much like we alreadydo for other forms of VM-scoped data.
CVE-2024-26692: In the Linux kernel, the following vulnerability has been resolved:smb: Fix regression in writes when non-standard maximum write size negotiatedThe conversion to netfs in the 6.3 kernel caused a regression whenmaximum write size is set by the server to an unexpected value which isnot a multiple of 4096 (similarly if the user overrides the maximumwrite size by setting mount parm "wsize", but sets it to a value thatis not a multiple of 4096).  When negotiated write size is not amultiple of 4096 the netfs code can skip the end of the finalpage when doing large sequential writes, causing data corruption.This section of code is being rewritten/removed due to a largenetfs change, but until that point (ie for the 6.3 kernel until now)we can not support non-standard maximum write sizes.Add a warning if a user specifies a wsize on mount that is nota multiple of 4096 (and round down), also add a change where weround down the maximum write size if the server negotiates a valuethat is not a multiple of 4096 (we also have to check to make sure thatwe do not round it down to zero).
Key phrases: regression