yahoo-inc/cve-impacts huggingface dataset:
CVE-2024-26693: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: fix a crash when we run out of stationsA DoS tool that injects loads of authentication frames made our APcrash. The iwl_mvm_is_dup() function couldn't find the per-queuedup_data which was not allocated.The root cause for that is that we ran out of stations in the firmwareand we didn't really add the station to the firmware, yet we didn'treturn an error to mac80211.Mac80211 was thinking that we have the station and because of that,sta_info::uploaded was set to 1. This allowedieee80211_find_sta_by_ifaddr() to return a valid station object, butthat ieee80211_sta didn't have any iwl_mvm_sta object initialized andthat caused the crash mentioned earlier when we got Rx on that station.
Key phrases: dos tool, crash
CVE-2024-26694: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: fix double-free bugThe storage for the TLV PC register data wasn't done like allthe other storage in the drv->fw area, which is cleared at theend of deallocation. Therefore, the freeing must also be donedifferently, explicitly NULL'ing it out after the free, sinceotherwise there's a nasty double-free bug here if a file failsto load after this has been parsed, and we get another freelater (e.g. because no other file exists.) Fix that by addingthe missing NULL assignment.
Key phrases: double-free bugthe, double free
CVE-2024-26696: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()Syzbot reported a hang issue in migrate_pages_batch() called by mbind()and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.While migrate_pages_batch() locks a folio and waits for the writeback tocomplete, the log writer thread that should bring the writeback tocompletion picks up the folio being written back innilfs_lookup_dirty_data_buffers() that it calls for subsequent logcreation and was trying to lock the folio.  Thus causing a deadlock.In the first place, it is unexpected that folios/pages in the middle ofwriteback will be updated and become dirty.  Nilfs2 adds a checksum toverify the validity of the log being written and uses it for recovery atmount, so data changes during writeback are suppressed.  Since this isbroken, an unclean shutdown could potentially cause recovery to fail.Investigation revealed that the root cause is that the wait for writebackcompletion in nilfs_page_mkwrite() is conditional, and if the backingdevice does not require stable writes, data may be modified withoutwaiting.Fix these issues by making nilfs_page_mkwrite() wait for writeback tofinish regardless of the stable write requirement of the backing device.
Key phrases: hang
CVE-2024-26697: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix data corruption in dsync block recovery for small block sizesThe helper function nilfs_recovery_copy_block() ofnilfs_recovery_dsync_blocks(), which recovers data from logs created bydata sync writes during a mount after an unclean shutdown, incorrectlycalculates the on-page offset when copying repair data to the file's pagecache.  In environments where the block size is smaller than the pagesize, this flaw can cause data corruption and leak uninitialized memorybytes during the recovery process.Fix these issues by correcting this byte offset calculation on the page.
Key phrases: data corruption
CVE-2024-26698: In the Linux kernel, the following vulnerability has been resolved:hv_netvsc: Fix race condition between netvsc_probe and netvsc_removeIn commit ac5047671758 ("hv_netvsc: Disable NAPI before closing theVMBus channel"), napi_disable was getting called for all channels,including all subchannels without confirming if they are enabled or not.This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()has finished running but nvdev->subchan_work has not started yet.netvsc_subchan_work() -> rndis_set_subchannel() has not created thesub-channels and because of that netvsc_sc_open() is not running.netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for whichnetvsc_subchan_work did not run.netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPIcannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear theNAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does theopposite.Now during netvsc_device_remove(), when napi_disable is called for thosesubchannels, napi_disable gets stuck on infinite msleep.This fix addresses this problem by ensuring that napi_disable() is notgetting called for non-enabled NAPI struct.But netif_napi_del() is still necessary for these non-enabled NAPI structfor cleanup purpose.Call trace:[  654.559417] task:modprobe        state:D stack:    0 pid: 2321 ppid:  1091 flags:0x00004002[  654.568030] Call Trace:[  654.571221]  <TASK>[  654.573790]  __schedule+0x2d6/0x960[  654.577733]  schedule+0x69/0xf0[  654.581214]  schedule_timeout+0x87/0x140[  654.585463]  ? __bpf_trace_tick_stop+0x20/0x20[  654.590291]  msleep+0x2d/0x40[  654.593625]  napi_disable+0x2b/0x80[  654.597437]  netvsc_device_remove+0x8a/0x1f0 [hv_netvsc][  654.603935]  rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc][  654.611101]  ? do_wait_intr+0xb0/0xb0[  654.615753]  netvsc_remove+0x7c/0x120 [hv_netvsc][  654.621675]  vmbus_remove+0x27/0x40 [hv_vmbus]
Key phrases: race condition, hang
CVE-2024-26699: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix array-index-out-of-bounds in dcn35_clkmgr[Why]There is a potential memory access violation whileiterating through array of dcn35 clks.[How]Limit iteration per array size.
Key phrases: array-index-out-of-bounds, memory access violation
CVE-2024-2670: A vulnerability was found in Campcodes Online Job Finder System 1.0. It has been classified as critical. Affected is an unknown function of the file /admin/vacancy/index.php. The manipulation of the argument id leads to sql injection. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. VDB-257370 is the identifier assigned to this vulnerability.
Key phrases: sql injection
CVE-2024-26702: In the Linux kernel, the following vulnerability has been resolved:iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRCRecently, we encounter kernel crash in function rm3100_common_probecaused by out of bound access of array rm3100_samp_rates (because ofunderlying hardware failures). Add boundary check to prevent out ofbound access.
Key phrases: out of bound access, crash
CVE-2024-26704: In the Linux kernel, the following vulnerability has been resolved:ext4: fix double-free of blocks due to wrong extents moved_lenIn ext4_move_extents(), moved_len is only updated when all moves aresuccessfully executed, and only discards orig_inode and donor_inodepreallocations when moved_len is not zero. When the loop fails to exitafter successfully moving some extents, moved_len is not updated andremains at 0, so it does not discard the preallocations.If the moved extents overlap with the preallocated extents, theoverlapped extents are freed twice in ext4_mb_release_inode_pa() andext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4:Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free isincremented twice. Hence when trim is executed, a zero-division bug istriggered in mb_update_avg_fragment_size() because bb_free is not zeroand bb_fragments is zero.Therefore, update move_len after each extent move to avoid the issue.
Key phrases: double free
CVE-2024-26705: In the Linux kernel, the following vulnerability has been resolved:parisc: BTLB: Fix crash when setting up BTLB at CPU bringupWhen using hotplug and bringing up a 32-bit CPU, ask the firmware about theBTLB information to set up the static (block) TLB entries.For that write access to the static btlb_info struct is needed, butsince it is marked __ro_after_init the kernel segfaults with missingwrite permissions.Fix the crash by dropping the __ro_after_init annotation.
Key phrases: crash
CVE-2024-26706: In the Linux kernel, the following vulnerability has been resolved:parisc: Fix random data corruption from exception handlerThe current exception handler implementation, which assists when accessinguser space memory, may exhibit random data corruption if the compiler decidesto use a different register than the specified register %r29 (defined inASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose anotherregister, the fault handler will nevertheless store -EFAULT into %r29 and thustrash whatever this register is used for.Looking at the assembly I found that this happens sometimes in emulate_ldd().To solve the issue, the easiest solution would be if it somehow ispossible to tell the fault handler which register is used to hold the errorcode. Using %0 or %1 in the inline assembly is not posssible as it will showup as e.g. %r29 (with the "%r" prefix), which the GNU assembler can notconvert to an integer.This patch takes another, better and more flexible approach:We extend the __ex_table (which is out of the execution path) by one 32-word.In this word we tell the compiler to insert the assembler instruction"or %r0,%r0,%reg", where %reg references the register which the compilerchoosed for the error return code.In case of an access failure, the fault handler finds the __ex_table entry andcan examine the opcode. The used register is encoded in the lowest 5 bits, andthe fault handler can then store -EFAULT into this register.Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORTconfig option any longer.
Key phrases: parisc, random data corruption
CVE-2024-26707: In the Linux kernel, the following vulnerability has been resolved:net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()Syzkaller reported [1] hitting a warning after failing to allocateresources for skb in hsr_init_skb(). Since a WARN_ONCE() call willnot help much in this case, it might be prudent to switch tonetdev_warn_once(). At the very least it will suppress syzkallerreports such as [1].Just in case, use netdev_warn_once() in send_prp_supervision_frame()for similar reasons.[1]HSR: Could not send supervision frameWARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294...Call Trace: <IRQ> hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700 expire_timers kernel/time/timer.c:1751 [inline] __run_timers+0x764/0xb20 kernel/time/timer.c:2022 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035 __do_softirq+0x21a/0x8de kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [inline] __irq_exit_rcu kernel/softirq.c:632 [inline] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649...This issue is also found in older kernels (at least up to 5.10).
CVE-2024-26708: In the Linux kernel, the following vulnerability has been resolved:mptcp: really cope with fastopen raceFastopen and PM-trigger subflow shutdown can race, as reported bysyzkaller.In my first attempt to close such race, I missed the fact thatthe subflow status can change again before the subflow_state_changecallback is invoked.Address the issue additionally copying with all the states directlyreachable from TCP_FIN_WAIT1.
Key phrases: fastopen racefastopen
CVE-2024-26709: In the Linux kernel, the following vulnerability has been resolved:powerpc/iommu: Fix the missing iommu_group_put() during platform domain attachThe function spapr_tce_platform_iommu_attach_dev() is missing to calliommu_group_put() when the domain is already set. This refcount leakshows up with BUG_ON() during DLPAR remove operation as:  KernelBug: Kernel bug in state 'None': kernel BUG at arch/powerpc/platforms/pseries/iommu.c:100!  Oops: Exception in kernel mode, sig: 5 [#1]  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=8192 NUMA pSeries  <snip>  Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_016) hv:phyp pSeries  NIP:  c0000000000ff4d4 LR: c0000000000ff4cc CTR: 0000000000000000  REGS: c0000013aed5f840 TRAP: 0700   Tainted: G          I         (6.8.0-rc3-autotest-g99bd3cb0d12e)  MSR:  8000000000029033 <SF,EE,ME,IR,DR,RI,LE>  CR: 44002402  XER: 20040000  CFAR: c000000000a0d170 IRQMASK: 0  ...  NIP iommu_reconfig_notifier+0x94/0x200  LR  iommu_reconfig_notifier+0x8c/0x200  Call Trace:    iommu_reconfig_notifier+0x8c/0x200 (unreliable)    notifier_call_chain+0xb8/0x19c    blocking_notifier_call_chain+0x64/0x98    of_reconfig_notify+0x44/0xdc    of_detach_node+0x78/0xb0    ofdt_write.part.0+0x86c/0xbb8    proc_reg_write+0xf4/0x150    vfs_write+0xf8/0x488    ksys_write+0x84/0x140    system_call_exception+0x138/0x330    system_call_vectored_common+0x15c/0x2ecThe patch adds the missing iommu_group_put() call.
Key phrases: refcount leakshows
CVE-2024-2671: A vulnerability was found in Campcodes Online Job Finder System 1.0. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file /admin/user/index.php. The manipulation of the argument id leads to sql injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-257371.
Key phrases: sql injection
CVE-2024-26710: In the Linux kernel, the following vulnerability has been resolved:powerpc/kasan: Limit KASAN thread size increase to 32KBKASAN is seen to increase stack usage, to the point that it was reportedto lead to stack overflow on some 32-bit machines (see link).To avoid overflows the stack size was doubled for KASAN builds incommit 3e8635fb2e07 ("powerpc/kasan: Force thread size increase withKASAN").However with a 32KB stack size to begin with, the doubling leads to a64KB stack, which causes build errors:  arch/powerpc/kernel/switch.S:249: Error: operand out of range (0x000000000000fe50 is not between 0xffffffffffff8000 and 0x0000000000007fff)Although the asm could be reworked, in practice a 32KB stack seemssufficient even for KASAN builds - the additional usage seems to be inthe 2-3KB range for a 64-bit KASAN build.So only increase the stack for KASAN if the stack size is < 32KB.
Key phrases: stack overflow
CVE-2024-26711: In the Linux kernel, the following vulnerability has been resolved:iio: adc: ad4130: zero-initialize clock init dataThe clk_init_data struct does not have all its membersinitialized, causing issues when trying to expose the internalclock on the CLK pin.Fix this by zero-initializing the clk_init_data struct.
CVE-2024-26712: In the Linux kernel, the following vulnerability has been resolved:powerpc/kasan: Fix addr error caused by page alignmentIn kasan_init_region, when k_start is not page aligned, at the begin offor loop, k_cur = k_start & PAGE_MASK is less than k_start, and then`va = block + k_cur - k_start` is less than block, the addr va is invalid,because the memory address space from va to block is not alloced bymemblock_alloc, which will not be reserved by memblock_reserve later, itwill be used by other places.As a result, memory overwriting occurs.for example:int __init __weak kasan_init_region(void *start, size_t size){[...]	/* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */	block = memblock_alloc(k_end - k_start, PAGE_SIZE);	[...]	for (k_cur = k_start & PAGE_MASK; k_cur < k_end; k_cur += PAGE_SIZE) {		/* at the begin of for loop		 * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400)		 * va(dcd96c00) is less than block(dcd97000), va is invalid		 */		void *va = block + k_cur - k_start;		[...]	}[...]}Therefore, page alignment is performed on k_start beforememblock_alloc() to ensure the validity of the VA address.
Key phrases: memory overwriting, memory overwrite
CVE-2024-26713: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries/iommu: Fix iommu initialisation during DLPAR addWhen a PCI device is dynamically added, the kernel oopses with a NULLpointer dereference:  BUG: Kernel NULL pointer dereference on read at 0x00000030  Faulting instruction address: 0xc0000000006bbe5c  Oops: Kernel access of bad area, sig: 11 [#1]  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries  Modules linked in: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs xsk_diag bonding nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod fuse  CPU: 17 PID: 2685 Comm: drmgr Not tainted 6.7.0-203405+ #66  Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries  NIP:  c0000000006bbe5c LR: c000000000a13e68 CTR: c0000000000579f8  REGS: c00000009924f240 TRAP: 0300   Not tainted  (6.7.0-203405+)  MSR:  8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 24002220  XER: 20040006  CFAR: c000000000a13e64 DAR: 0000000000000030 DSISR: 40000000 IRQMASK: 0  ...  NIP sysfs_add_link_to_group+0x34/0x94  LR  iommu_device_link+0x5c/0x118  Call Trace:   iommu_init_device+0x26c/0x318 (unreliable)   iommu_device_link+0x5c/0x118   iommu_init_device+0xa8/0x318   iommu_probe_device+0xc0/0x134   iommu_bus_notifier+0x44/0x104   notifier_call_chain+0xb8/0x19c   blocking_notifier_call_chain+0x64/0x98   bus_notify+0x50/0x7c   device_add+0x640/0x918   pci_device_add+0x23c/0x298   of_create_pci_dev+0x400/0x884   of_scan_pci_dev+0x124/0x1b0   __of_scan_bus+0x78/0x18c   pcibios_scan_phb+0x2a4/0x3b0   init_phb_dynamic+0xb8/0x110   dlpar_add_slot+0x170/0x3b8 [rpadlpar_io]   add_slot_store.part.0+0xb4/0x130 [rpadlpar_io]   kobj_attr_store+0x2c/0x48   sysfs_kf_write+0x64/0x78   kernfs_fop_write_iter+0x1b0/0x290   vfs_write+0x350/0x4a0   ksys_write+0x84/0x140   system_call_exception+0x124/0x330   system_call_vectored_common+0x15c/0x2ecCommit a940904443e4 ("powerpc/iommu: Add iommu_ops to report capabilitiesand allow blocking domains") broke DLPAR add of PCI devices.The above added iommu_device structure to pci_controller. Duringsystem boot, PCI devices are discovered and this newly added iommu_devicestructure is initialized by a call to iommu_device_register().During DLPAR add of a PCI device, a new pci_controller structure isallocated but there are no calls made to iommu_device_register()interface.Fix is to register the iommu device during DLPAR add as well.[mpe: Trim oops and tweak some change log wording]
Key phrases: pci_controller
CVE-2024-26714: In the Linux kernel, the following vulnerability has been resolved:interconnect: qcom: sc8180x: Mark CO0 BCM keepaliveThe CO0 BCM needs to be up at all times, otherwise some hardware (likethe UFS controller) loses its connection to the rest of the SoC,resulting in a hang of the platform, accompanied by a spectacularlogspam.Mark it as keepalive to prevent such cases.
Key phrases: hang
CVE-2024-26715: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspendIn current scenario if Plug-out and Plug-In performed continuouslythere could be a chance while checking for dwc->gadget_driver indwc3_gadget_suspend, a NULL pointer dereference may occur.Call Stack:	CPU1:                           CPU2:	gadget_unbind_driver            dwc3_suspend_common	dwc3_gadget_stop                dwc3_gadget_suspend                                        dwc3_disconnect_gadgetCPU1 basically clears the variable and CPU2 checks the variable.Consider CPU1 is running and right before gadget_driver is clearedand in parallel CPU2 executes dwc3_gadget_suspend where it findsdwc->gadget_driver which is not NULL and resumes execution and thenCPU1 completes execution. CPU2 executes dwc3_disconnect_gadget whereit checks dwc->gadget_driver is already NULL because of which theNULL pointer deference occur.
Key phrases: null pointer dereference
CVE-2024-26716: In the Linux kernel, the following vulnerability has been resolved:usb: core: Prevent null pointer dereference in update_port_device_stateCurrently, the function update_port_device_state gets the usb_hub fromudev->parent by calling usb_hub_to_struct_hub.However, in case the actconfig or the maxchild is 0, the usb_hub wouldbe NULL and upon further accessing to get port_dev would result in nullpointer dereference.Fix this by introducing an if check after the usb_hub is populated.
Key phrases: null pointer dereference, nullpointer dereference
CVE-2024-26717: In the Linux kernel, the following vulnerability has been resolved:HID: i2c-hid-of: fix NULL-deref on failed power upA while back the I2C HID implementation was split in an ACPI and OFpart, but the new OF driver never initialises the client pointer whichis dereferenced on power-up failures.
Key phrases: null-deref
CVE-2024-26718: In the Linux kernel, the following vulnerability has been resolved:dm-crypt, dm-verity: disable taskletsTasklets have an inherent problem with memory corruption. The functiontasklet_action_common calls tasklet_trylock, then it calls the taskletcallback and then it calls tasklet_unlock. If the tasklet callback freesthe structure that contains the tasklet or if it calls some code that mayfree it, tasklet_unlock will write into free memory.The commits 8e14f610159d and d9a02e016aaf try to fix it for dm-crypt, butit is not a sufficient fix and the data corruption can still happen [1].There is no fix for dm-verity and dm-verity will write into free memorywith every tasklet-processed bio.There will be atomic workqueues implemented in the kernel 6.9 [2]. Theywill have better interface and they will not suffer from the memorycorruption problem.But we need something that stops the memory corruption now and that can bebackported to the stable kernels. So, I'm proposing this commit thatdisables tasklets in both dm-crypt and dm-verity. This commit doesn'tremove the tasklet support, because the tasklet code will be reused whenatomic workqueues will be implemented.[1] https://lore.kernel.org/all/d390d7ee-f142-44d3-822a-87949e14608b@suse.de/T/[2] https://lore.kernel.org/lkml/20240130091300.2968534-1-tj@kernel.org/
Key phrases: memory corruption, data corruption
CVE-2024-26719: In the Linux kernel, the following vulnerability has been resolved:nouveau: offload fence uevents work to workqueueThis should break the deadlock between the fctx lock and the irq lock.This offloads the processing off the work from the irq into a workqueue.
CVE-2024-2672: A vulnerability was found in Campcodes Online Job Finder System 1.0. It has been rated as critical. Affected by this issue is some unknown functionality of the file /admin/user/controller.php. The manipulation of the argument UESRID leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-257372.
Key phrases: sql injection
CVE-2024-26720: In the Linux kernel, the following vulnerability has been resolved:mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again(struct dirty_throttle_control *)->thresh is an unsigned long, but ispassed as the u32 divisor argument to div_u64().  On architectures whereunsigned long is 64 bytes, the argument will be implicitly truncated.Use div64_u64() instead of div_u64() so that the value used in the "isthis a safe division" check is the same as the divisor.Also, remove redundant cast of the numerator to u64, as that should happenimplicitly.This would be difficult to exploit in memcg domain, given the ratio-basedarithmetic domain_drity_limits() uses, but is much easier in globalwriteback domain with a BDI_CAP_STRICTLIMIT-backing device, using e.g. vm.dirty_bytes=(1<<32)*PAGE_SIZE so that dtc->thresh == (1<<32)
Key phrases: divide-by-zero
CVE-2024-26721: In the Linux kernel, the following vulnerability has been resolved:drm/i915/dsc: Fix the macro that calculates DSCC_/DSCA_ PPS reg addressCommit bd077259d0a9 ("drm/i915/vdsc: Add function to read any PPSregister") defines a new macro to calculate the DSC PPS registeraddresses with PPS number as an input. This macro correctly calculatesthe addresses till PPS 11 since the addresses increment by 4. So in thatcase the following macro works correctly to give correct registeraddress:_MMIO(_DSCA_PPS_0 + (pps) * 4)However after PPS 11, the register address for PPS 12 increments by 12because of RC Buffer memory allocation in between. Because of thisdiscontinuity in the address space, the macro calculates wrong addressesfor PPS 12 - 16 resulting into incorrect DSC PPS parameter valueread/writes causing DSC corruption.This fixes it by correcting this macro to add the offset of 12 for PPS>=12.v3: Add correct paranthesis for pps argument (Jani Nikula)(cherry picked from commit 6074be620c31dc2ae11af96a1a5ea95580976fb5)
Key phrases: dsc corruption
CVE-2024-26722: In the Linux kernel, the following vulnerability has been resolved:ASoC: rt5645: Fix deadlock in rt5645_jack_detect_work()There is a path in rt5645_jack_detect_work(), where rt5645->jd_mutexis left locked forever. That may lead to deadlockwhen rt5645_jack_detect_work() is called for the second time.Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-26723: In the Linux kernel, the following vulnerability has been resolved:lan966x: Fix crash when adding interface under a lagThere is a crash when adding one of the lan966x interfaces under a laginterface. The issue can be reproduced like this:ip link add name bond0 type bond miimon 100 mode balance-xorip link set dev eth0 master bond0The reason is because when adding a interface under the lag it would gothrough all the ports and try to figure out which other ports are underthat lag interface. And the issue is that lan966x can have ports that areNULL pointer as they are not probed. So then iterating over these portsit would just crash as they are NULL pointers.The fix consists in actually checking for NULL pointers before accessingsomething from the ports. Like we do in other places.
Key phrases: crash
CVE-2024-26726: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't drop extent_map for free space inode on write errorWhile running the CI for an unrelated change I hit the following panicwith generic/648 on btrfs_holes_spacecache.assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385------------[ cut here ]------------kernel BUG at fs/btrfs/extent_io.c:1385!invalid opcode: 0000 [#1] PREEMPT SMP NOPTICPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G        W          6.8.0-rc2+ #1RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0Call Trace: <TASK> extent_write_cache_pages+0x2ac/0x8f0 extent_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_cache+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813/0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76This happens because we fail to write out the free space cache in oneinstance, come back around and attempt to write it again.  However onthe second pass through we go to call btrfs_get_extent() on the inode toget the extent mapping.  Because this is a new block group, and with thefree space inode we always search the commit root to avoid deadlockingwith the tree, we find nothing and return a EXTENT_MAP_HOLE for therequested range.This happens because the first time we try to write the space cache outwe hit an error, and on an error we drop the extent mapping.  This isnormal for normal files, but the free space cache inode is special.  Wealways expect the extent map to be correct.  Thus the second timethrough we end up with a bogus extent map.Since we're deprecating this feature, the most straightforward way tofix this is to simply skip dropping the extent map range for this failedrange.I shortened the test by using error injection to stress the area to makeit easier to reproduce.  With this patch in place we no longer panicwith my error injection test.
CVE-2024-26727: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not ASSERT() if the newly created subvolume already got read[BUG]There is a syzbot crash, triggered by the ASSERT() during subvolumecreation: assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319 ------------[ cut here ]------------ kernel BUG at fs/btrfs/disk-io.c:1319! invalid opcode: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60  <TASK>  btrfs_get_new_fs_root+0xd3/0xf0  create_subvol+0xd02/0x1650  btrfs_mksubvol+0xe95/0x12b0  __btrfs_ioctl_snap_create+0x2f9/0x4f0  btrfs_ioctl_snap_create+0x16b/0x200  btrfs_ioctl+0x35f0/0x5cf0  __x64_sys_ioctl+0x19d/0x210  do_syscall_64+0x3f/0xe0  entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace 0000000000000000 ]---[CAUSE]During create_subvol(), after inserting root item for the newly createdsubvolume, we would trigger btrfs_get_new_fs_root() to get thebtrfs_root of that subvolume.The idea here is, we have preallocated an anonymous device number forthe subvolume, thus we can assign it to the new subvolume.But there is really nothing preventing things like backref walk to readthe new subvolume.If that happens before we call btrfs_get_new_fs_root(), the subvolumewould be read out, with a new anonymous device number assigned already.In that case, we would trigger ASSERT(), as we really expect no one toread out that subvolume (which is not yet accessible from the fs).But things like backref walk is still possible to trigger the read onthe subvolume.Thus our assumption on the ASSERT() is not correct in the first place.[FIX]Fix it by removing the ASSERT(), and just free the @anon_dev, reset itto 0, and continue.If the subvolume tree is read out by something else, it should havealready get a new anon_dev assigned thus we only need to free thepreallocated one.
Key phrases: crash
CVE-2024-26729: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix potential null pointer dereference in dc_dmub_srvFixes potential null pointer dereference warnings in thedc_dmub_srv_cmd_list_queue_execute() and dc_dmub_srv_is_hw_pwr_up()functions.In both functions, the 'dc_dmub_srv' variable was being dereferencedbefore it was checked for null. This could lead to a null pointerdereference if 'dc_dmub_srv' is null. The fix is to check if'dc_dmub_srv' is null before dereferencing it.Thus moving the null checks for 'dc_dmub_srv' to the beginning of thefunctions to ensure that 'dc_dmub_srv' is not null when it isdereferenced.Found by smatch & thus fixing the below:drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:133 dc_dmub_srv_cmd_list_queue_execute() warn: variable dereferenced before check 'dc_dmub_srv' (see line 128)drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_is_hw_pwr_up() warn: variable dereferenced before check 'dc_dmub_srv' (see line 1164)
Key phrases: null pointer dereference
CVE-2024-2673: A vulnerability classified as critical has been found in Campcodes Online Job Finder System 1.0. This affects an unknown part of the file /admin/login.php. The manipulation of the argument user_email leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-257373 was assigned to this vulnerability.
Key phrases: sql injection
CVE-2024-26730: In the Linux kernel, the following vulnerability has been resolved:hwmon: (nct6775) Fix access to temperature configuration registersThe number of temperature configuration registers doesnot always match the total number of temperature registers.This can result in access errors reported if KASAN is enabled.BUG: KASAN: global-out-of-bounds in nct6775_probe+0x5654/0x6fe9 nct6775_core
CVE-2024-26731: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()syzbot reported the following NULL pointer dereference issue [1]:  BUG: kernel NULL pointer dereference, address: 0000000000000000  [...]  RIP: 0010:0x0  [...]  Call Trace:   <TASK>   sk_psock_verdict_data_ready+0x232/0x340 net/core/skmsg.c:1230   unix_stream_sendmsg+0x9b4/0x1230 net/unix/af_unix.c:2293   sock_sendmsg_nosec net/socket.c:730 [inline]   __sock_sendmsg+0x221/0x270 net/socket.c:745   ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584   ___sys_sendmsg net/socket.c:2638 [inline]   __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667   do_syscall_64+0xf9/0x240   entry_SYSCALL_64_after_hwframe+0x6f/0x77If sk_psock_verdict_data_ready() and sk_psock_stop_verdict() are calledconcurrently, psock->saved_data_ready can be NULL, causing the above issue.This patch fixes this issue by calling the appropriate data ready functionusing the sk_psock_data_ready() helper and protecting it from concurrencywith sk->sk_callback_lock.
Key phrases: bpf, null pointer dereference
CVE-2024-26734: In the Linux kernel, the following vulnerability has been resolved:devlink: fix possible use-after-free and memory leaks in devlink_init()The pernet operations structure for the subsystem must be registeredbefore registering the generic netlink family.Make an unregister in case of unsuccessful registration.
Key phrases: use-after-free, memory leaks, use after free
CVE-2024-26735: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix possible use-after-free and null-ptr-derefThe pernet operations structure for the subsystem must be registeredbefore registering the generic netlink family.
Key phrases: use-after-free, null-ptr-derefthe, use after free
CVE-2024-26736: In the Linux kernel, the following vulnerability has been resolved:afs: Increase buffer size in afs_update_volume_status()The max length of volume->vid value is 20 characters.So increase idbuf[] size up to 24 to avoid overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.[DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()]
Key phrases: overflow
CVE-2024-26737: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancelThe following race is possible between bpf_timer_cancel_and_freeand bpf_timer_cancel. It will lead a UAF on the timer->timer.bpf_timer_cancel();	spin_lock();	t = timer->time;	spin_unlock();					bpf_timer_cancel_and_free();						spin_lock();						t = timer->timer;						timer->timer = NULL;						spin_unlock();						hrtimer_cancel(&t->timer);						kfree(t);	/* UAF on t */	hrtimer_cancel(&t->timer);In bpf_timer_cancel_and_free, this patch frees the timer->timerafter a rcu grace period. This requires a rcu_head additionto the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init,this does not need a kfree_rcu because it is still under thespin_lock and timer->timer has not been visible by others yet.In bpf_timer_cancel, rcu_read_lock() is added because this helpercan be used in a non rcu critical section context (e.g. froma sleepable bpf prog). Other timer->timer usages in helpers.chave been audited, bpf_timer_cancel() is the only place wheretimer->timer is used outside of the spin_lock.Another solution considered is to mark a t->flag in bpf_timer_canceland clear it after hrtimer_cancel() is done.  In bpf_timer_cancel_and_free,it busy waits for the flag to be cleared before kfree(t). This patchgoes with a straight forward solution and frees timer->timer aftera rcu grace period.
Key phrases: uaf
CVE-2024-26738: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries/iommu: DLPAR add doesn't completely initialize pci_controllerWhen a PCI device is dynamically added, the kernel oopses with a NULLpointer dereference:  BUG: Kernel NULL pointer dereference on read at 0x00000030  Faulting instruction address: 0xc0000000006bbe5c  Oops: Kernel access of bad area, sig: 11 [#1]  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries  Modules linked in: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs xsk_diag bonding nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod fuse  CPU: 17 PID: 2685 Comm: drmgr Not tainted 6.7.0-203405+ #66  Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries  NIP:  c0000000006bbe5c LR: c000000000a13e68 CTR: c0000000000579f8  REGS: c00000009924f240 TRAP: 0300   Not tainted  (6.7.0-203405+)  MSR:  8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 24002220  XER: 20040006  CFAR: c000000000a13e64 DAR: 0000000000000030 DSISR: 40000000 IRQMASK: 0  ...  NIP sysfs_add_link_to_group+0x34/0x94  LR  iommu_device_link+0x5c/0x118  Call Trace:   iommu_init_device+0x26c/0x318 (unreliable)   iommu_device_link+0x5c/0x118   iommu_init_device+0xa8/0x318   iommu_probe_device+0xc0/0x134   iommu_bus_notifier+0x44/0x104   notifier_call_chain+0xb8/0x19c   blocking_notifier_call_chain+0x64/0x98   bus_notify+0x50/0x7c   device_add+0x640/0x918   pci_device_add+0x23c/0x298   of_create_pci_dev+0x400/0x884   of_scan_pci_dev+0x124/0x1b0   __of_scan_bus+0x78/0x18c   pcibios_scan_phb+0x2a4/0x3b0   init_phb_dynamic+0xb8/0x110   dlpar_add_slot+0x170/0x3b8 [rpadlpar_io]   add_slot_store.part.0+0xb4/0x130 [rpadlpar_io]   kobj_attr_store+0x2c/0x48   sysfs_kf_write+0x64/0x78   kernfs_fop_write_iter+0x1b0/0x290   vfs_write+0x350/0x4a0   ksys_write+0x84/0x140   system_call_exception+0x124/0x330   system_call_vectored_common+0x15c/0x2ecCommit a940904443e4 ("powerpc/iommu: Add iommu_ops to report capabilitiesand allow blocking domains") broke DLPAR add of PCI devices.The above added iommu_device structure to pci_controller. Duringsystem boot, PCI devices are discovered and this newly added iommu_devicestructure is initialized by a call to iommu_device_register().During DLPAR add of a PCI device, a new pci_controller structure isallocated but there are no calls made to iommu_device_register()interface.Fix is to register the iommu device during DLPAR add as well.
Key phrases: pci_controller
CVE-2024-26739: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_mirred: don't override retval if we already lost the skbIf we're redirecting the skb, and haven't called tcf_mirred_forward(),yet, we need to tell the core to drop the skb by setting the retcodeto SHOT. If we have called tcf_mirred_forward(), however, the skbis out of our hands and returning SHOT will lead to UaF.Move the retval override to the error path which actually need it.
Key phrases: uaf
CVE-2024-2674: A vulnerability classified as critical was found in Campcodes Online Job Finder System 1.0. This vulnerability affects unknown code of the file /admin/employee/index.php. The manipulation of the argument id leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. VDB-257374 is the identifier assigned to this vulnerability.
Key phrases: sql injection
CVE-2024-26740: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_mirred: use the backlog for mirred ingressThe test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlogfor nested calls to mirred ingress") hangs our testing VMs every 10 or soruns, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported bylockdep.The problem as previously described by Davide (see Link) is thatif we reverse flow of traffic with the redirect (egress -> ingress)we may reach the same socket which generated the packet. And we maystill be holding its socket lock. The common solution to such deadlocksis to put the packet in the Rx backlog, rather than run the Rx pathinline. Do that for all egress -> ingress reversals, not just oncewe started to nest mirred calls.In the past there was a concern that the backlog indirection willlead to loss of error reporting / less accurate stats. But the currentworkaround does not seem to address the issue.
Key phrases: hang
CVE-2024-26742: In the Linux kernel, the following vulnerability has been resolved:scsi: smartpqi: Fix disable_managed_interruptsCorrect blk-mq registration issue with module parameterdisable_managed_interrupts enabled.When we turn off the default PCI_IRQ_AFFINITY flag, the driver needs toregister with blk-mq using blk_mq_map_queues(). The driver is currentlycalling blk_mq_pci_map_queues() which results in a stack trace and possiblyundefined behavior.Stack Trace:[    7.860089] scsi host2: smartpqi[    7.871934] WARNING: CPU: 0 PID: 238 at block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0[    7.889231] Modules linked in: sd_mod t10_pi sg uas smartpqi(+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse[    7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 Not tainted 4.18.0-372.88.1.el8_6_smartpqi_test.x86_64 #1[    7.944336] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 03/08/2022[    7.963026] Workqueue: events work_for_cpu_fn[    7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0[    7.978278] Code: 48 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 57 49 89 ff 41 56 41 55 41 54[    7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216[    7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000010[    7.978284] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310[    7.978286] RBP: 0000000000000000 R08: ffffa95fc3707d38 R09: ffff91929b81ac00[    7.978287] R10: 0000000000000001 R11: ffffa95fc3707ac0 R12: 0000000000000000[    7.978288] R13: ffff9190c32d4000 R14: 00000000ffffffff R15: ffff9190c4c950a8[    7.978290] FS:  0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000[    7.978292] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033[    8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0[    8.172816] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[    8.172817] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[    8.172818] PKRU: 55555554[    8.172819] Call Trace:[    8.172823]  blk_mq_alloc_tag_set+0x12e/0x310[    8.264339]  scsi_add_host_with_dma.cold.9+0x30/0x245[    8.279302]  pqi_ctrl_init+0xacf/0xc8e [smartpqi][    8.294085]  ? pqi_pci_probe+0x480/0x4c8 [smartpqi][    8.309015]  pqi_pci_probe+0x480/0x4c8 [smartpqi][    8.323286]  local_pci_probe+0x42/0x80[    8.337855]  work_for_cpu_fn+0x16/0x20[    8.351193]  process_one_work+0x1a7/0x360[    8.364462]  ? create_worker+0x1a0/0x1a0[    8.379252]  worker_thread+0x1ce/0x390[    8.392623]  ? create_worker+0x1a0/0x1a0[    8.406295]  kthread+0x10a/0x120[    8.418428]  ? set_kthread_struct+0x50/0x50[    8.431532]  ret_from_fork+0x1f/0x40[    8.444137] ---[ end trace 1bf0173d39354506 ]---
CVE-2024-26744: In the Linux kernel, the following vulnerability has been resolved:RDMA/srpt: Support specifying the srpt_service_guid parameterMake loading ib_srpt with this parameter set work. The current behavior isthat setting that parameter while loading the ib_srpt kernel moduletriggers the following kernel crash:BUG: kernel NULL pointer dereference, address: 0000000000000000Call Trace: <TASK> parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 entry_SYSCALL_64_after_hwframe+0x6e/0x76
Key phrases: null pointer dereference
CVE-2024-26747: In the Linux kernel, the following vulnerability has been resolved:usb: roles: fix NULL pointer issue when put module's referenceIn current design, usb role class driver will get usb_role_switch parent'smodule reference after the user get usb_role_switch device and put thereference after the user put the usb_role_switch device. However, theparent device of usb_role_switch may be removed before the user put theusb_role_switch. If so, then, NULL pointer issue will be met when the userput the parent module's reference.This will save the module pointer in structure of usb_role_switch. Then,we don't need to find module by iterating long relations.
Key phrases: null pointer issue
CVE-2024-26748: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: fix memory double free when handle zero packet829  if (request->complete) {830          spin_unlock(&priv_dev->lock);831          usb_gadget_giveback_request(&priv_ep->endpoint,832                                    request);833          spin_lock(&priv_dev->lock);834  }835836  if (request->buf == priv_dev->zlp_buf)837      cdns3_gadget_ep_free_request(&priv_ep->endpoint, request);Driver append an additional zero packet request when queue a packet, whichlength mod max packet size is 0. When transfer complete, run to line 831,usb_gadget_giveback_request() will free this requestion. 836 condition istrue, so cdns3_gadget_ep_free_request() free this request again.Log:[ 1920.140696][  T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3][ 1920.140696][  T150][ 1920.151837][  T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):[ 1920.159082][  T150]  cdns3_gadget_giveback+0x134/0x2c0 [cdns3][ 1920.164988][  T150]  cdns3_transfer_completed+0x438/0x5f8 [cdns3]Add check at line 829, skip call usb_gadget_giveback_request() if it isadditional zero length packet request. Needn't callusb_gadget_giveback_request() because it is allocated in this driver.
Key phrases: memory double free, use after free
CVE-2024-26749: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: fixed memory use after free at cdns3_gadget_ep_disable()  ...  cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request);  list_del_init(&priv_req->list);  ...'priv_req' actually free at cdns3_gadget_ep_free_request(). Butlist_del_init() use priv_req->list after it.[ 1542.642868][  T534] BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xd4[ 1542.642868][  T534][ 1542.653162][  T534] Use-after-free read at 0x000000009ed0ba99 (in kfence-#3):[ 1542.660311][  T534]  __list_del_entry_valid+0x10/0xd4[ 1542.665375][  T534]  cdns3_gadget_ep_disable+0x1f8/0x388 [cdns3][ 1542.671571][  T534]  usb_ep_disable+0x44/0xe4[ 1542.675948][  T534]  ffs_func_eps_disable+0x64/0xc8[ 1542.680839][  T534]  ffs_func_set_alt+0x74/0x368[ 1542.685478][  T534]  ffs_func_disable+0x18/0x28Move list_del_init() before cdns3_gadget_ep_free_request() to resolve thisproblem.
Key phrases: memory use after free
CVE-2024-2675: A vulnerability, which was classified as critical, has been found in Campcodes Online Job Finder System 1.0. This issue affects some unknown processing of the file /admin/company/index.php. The manipulation of the argument id leads to sql injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-257375.
Key phrases: sql injection
CVE-2024-26751: In the Linux kernel, the following vulnerability has been resolved:ARM: ep93xx: Add terminator to gpiod_lookup_tableWithout the terminator, if a con_id is passed to gpio_find() thatdoes not exist in the lookup table the function will not stop loopingcorrectly, and eventually cause an oops.
Key phrases: oops