yahoo-inc/cve-impacts huggingface dataset:
CVE-2023-52458: In the Linux kernel, the following vulnerability has been resolved:block: add check that partition length needs to be aligned with block sizeBefore calling add partition or resize partition, there is no checkon whether the length is aligned with the logical block size.If the logical block size of the disk is larger than 512 bytes,then the partition size maybe not the multiple of the logical block size,and when the last sector is read, bio_truncate() will adjust the bio size,resulting in an IO error if the size of the read command is smaller thanthe logical block size.If integrity data is supported, this will alsoresult in a null pointer dereference when calling bio_integrity_free.
Key phrases: io error, null pointer dereference, integrity
CVE-2023-52459: In the Linux kernel, the following vulnerability has been resolved:media: v4l: async: Fix duplicated list deletionThe list deletion call dropped here is already called from thehelper function in the line before. Having a second list_del()call results in either a warning (with CONFIG_DEBUG_LIST=y):list_del corruption, c46c8198->next is LIST_POISON1 (00000100)If CONFIG_DEBUG_LIST is disabled the operation results in akernel error due to NULL pointer dereference.
Key phrases: null pointer dereference
CVE-2023-5246: Authentication Bypass by Capture-replay in SICK Flexi Soft Gateways with Partnumbers 1044073, 1127717, 1130282, 1044074, 1121597, 1099832, 1051432, 1127487, 1069070, 1112296, 1044072, 1121596, 1099830 allows an unauthenticated remote attacker to potentially impact the availability, integrity and confidentiality of the gateways via an authentication bypass by capture-replay.
Key phrases: Bypass by Capture-replay in SICK Flexi Soft Gateways, bypass by capture-replay, Authentication Bypass, potentially impact the availability, authentication bypass, integrity, confidentiality
CVE-2023-52460: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix NULL pointer dereference at hibernateDuring hibernate sequence the source context might not have a clk_mgr.So don't use it to look for DML2 support.
Key phrases: null pointer dereference
CVE-2023-52461: In the Linux kernel, the following vulnerability has been resolved:drm/sched: Fix bounds limiting when given a malformed entityIf we're given a malformed entity in drm_sched_entity_init()--shouldn'thappen, but we verify--with out-of-bounds priority value, we set it to anallowed value. Fix the expression which sets this limit.
Key phrases: malformed entity
CVE-2023-52462: In the Linux kernel, the following vulnerability has been resolved:bpf: fix check for attempt to corrupt spilled pointerWhen register is spilled onto a stack as a 1/2/4-byte register, we setslot_type[BPF_REG_SIZE - 1] (plus potentially few more below it,depending on actual spill size). So to check if some stack slot hasspilled register we need to consult slot_type[7], not slot_type[0].To avoid the need to remember and double-check this in the future, justuse is_spilled_reg() helper.
CVE-2023-52464: In the Linux kernel, the following vulnerability has been resolved:EDAC/thunderx: Fix possible out-of-bounds string accessEnabling -Wstringop-overflow globally exposes a warning for a common bugin the usage of strncat():  drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr':  drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=]   1136 |                 strncat(msg, other, OCX_MESSAGE_SIZE);        |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   ...   1145 |                                 strncat(msg, other, OCX_MESSAGE_SIZE);   ...   1150 |                                 strncat(msg, other, OCX_MESSAGE_SIZE);   ...Apparently the author of this driver expected strncat() to behave theway that strlcat() does, which uses the size of the destination bufferas its third argument rather than the length of the source buffer. Theresult is that there is no check on the size of the allocated buffer.Change it to strlcat().  [ bp: Trim compiler output, fixup commit message. ]
CVE-2023-52465: In the Linux kernel, the following vulnerability has been resolved:power: supply: Fix null pointer dereference in smb2_probedevm_kasprintf and devm_kzalloc return a pointer to dynamicallyallocated memory which can be NULL upon failure.
Key phrases: null pointer dereference
CVE-2023-52467: In the Linux kernel, the following vulnerability has been resolved:mfd: syscon: Fix null pointer dereference in of_syscon_register()kasprintf() returns a pointer to dynamically allocated memorywhich can be NULL upon failure.
Key phrases: null pointer dereference
CVE-2023-52468: In the Linux kernel, the following vulnerability has been resolved:class: fix use-after-free in class_register()The lock_class_key is still registered and can be found inlock_keys_hash hlist after subsys_private is freed in errorhandler path.A task who iterate over the lock_keys_hashlater may cause use-after-free.So fix that up and unregisterthe lock_class_key before kfree(cp).On our platform, a driver fails to kset_register because ofcreating duplicate filename '/class/xxx'.With Kasan enabled,it prints a invalid-access bug report.KASAN bug report:BUG: KASAN: invalid-access in lockdep_register_key+0x19c/0x1bcWrite of size 8 at addr 15ffff808b8c0368 by task modprobe/252Pointer tag: [15], memory tag: [fe]CPU: 7 PID: 252 Comm: modprobe Tainted: G        W 6.6.0-mainline-maybe-dirty #1Call trace:dump_backtrace+0x1b0/0x1e4show_stack+0x2c/0x40dump_stack_lvl+0xac/0xe0print_report+0x18c/0x4d8kasan_report+0xe8/0x148__hwasan_store8_noabort+0x88/0x98lockdep_register_key+0x19c/0x1bcclass_register+0x94/0x1ecinit_module+0xbc/0xf48 [rfkill]do_one_initcall+0x17c/0x72cdo_init_module+0x19c/0x3f8...Memory state around the buggy address:ffffff808b8c0100: 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8affffff808b8c0200: 8a 8a 8a 8a 8a 8a 8a 8a fe fe fe fe fe fe fe fe>ffffff808b8c0300: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe                                     ^ffffff808b8c0400: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03As CONFIG_KASAN_GENERIC is not set, Kasan reports invalid-accessnot use-after-free here.In this case, modprobe is manipulatingthe corrupted lock_keys_hash hlish where lock_class_key is alreadyfreed before.It's worth noting that this only can happen if lockdep is enabled,which is not true for normal system.
Key phrases: use-after-free, use after free
CVE-2023-52469: In the Linux kernel, the following vulnerability has been resolved:drivers/amd/pm: fix a use-after-free in kv_parse_power_tableWhen ps allocated by kzalloc equals to NULL, kv_parse_power_tablefrees adev->pm.dpm.ps that allocated before. However, after the controlflow goes through the following call chains:kv_parse_power_table  |-> kv_dpm_init        |-> kv_dpm_sw_init	      |-> kv_dpm_finiThe adev->pm.dpm.ps is used in the for loop of kv_dpm_fini after itsfirst free in kv_parse_power_table and causes a use-after-free bug.
Key phrases: use-after-free, use-after-free bug, use after free
CVE-2023-5247: Malicious Code Execution Vulnerability due to External Control of File Name or Path in multiple Mitsubishi Electric FA Engineering Software Products allows a malicious attacker to execute a malicious code by having legitimate users open a specially crafted project file, which could result in information disclosure, tampering and deletion, or a denial-of-service (DoS) condition.
Key phrases: execute a malicious code by having legitimate users, malicious code execution, external control of file name or path, information disclosure, deletion, denial-of-service (dos) condition, denial of service
CVE-2023-52470: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: check the alloc_workqueue return value in radeon_crtc_init()check the alloc_workqueue return value in radeon_crtc_init()to avoid null-ptr-deref.
Key phrases: null-ptr-deref
CVE-2023-52471: In the Linux kernel, the following vulnerability has been resolved:ice: Fix some null pointer dereference issues in ice_ptp.cdevm_kasprintf() returns a pointer to dynamically allocated memorywhich can be NULL upon failure.
Key phrases: ice, null pointer dereference
CVE-2023-52472: In the Linux kernel, the following vulnerability has been resolved:crypto: rsa - add a check for allocation failureStatic checkers insist that the mpi_alloc() allocation can fail so adda check to prevent a NULL dereference.  Small allocations like thiscan't actually fail in current kernels, but adding a check is verysimple and makes the static checkers happy.
Key phrases: allocation failurestatic, null dereference
CVE-2023-52473: In the Linux kernel, the following vulnerability has been resolved:thermal: core: Fix NULL pointer dereference in zone registration error pathIf device_register() in thermal_zone_device_register_with_trips()returns an error, the tz variable is set to NULL and subsequentlydereferenced in kfree(tz->tzp).Commit adc8749b150c ("thermal/drivers/core: Use put_device() ifdevice_register() fails") added the tz = NULL assignment in question toavoid a possible double-free after dropping the reference to the zonedevice.  However, after commit 4649620d9404 ("thermal: core: Makethermal_zone_device_unregister() return after freeing the zone"), thatassignment has become redundant, because dropping the reference to thezone device does not cause the zone object to be freed any more.Drop it to address the NULL pointer dereference.
Key phrases: null pointer dereference, double free
CVE-2023-52474: In the Linux kernel, the following vulnerability has been resolved:IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requestshfi1 user SDMA request processing has two bugs that can cause datacorruption for user SDMA requests that have multiple payload iovecswhere an iovec other than the tail iovec does not run up to the pageboundary for the buffer pointed to by that iovec.aHere are the specific bugs:1. user_sdma_txadd() does not use struct user_sdma_iovec->iov.iov_len.   Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec   to the packet, even if some of those bytes are past   iovec->iov.iov_len and are thus not intended to be in the packet.2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the   next iovec in user_sdma_request->iovs when the current iovec   is not PAGE_SIZE and does not contain enough data to complete the   packet. The transmitted packet will contain the wrong data from the   iovec pages.This has not been an issue with SDMA packets from hfi1 Verbs or PSM2because they only produce iovecs that end short of PAGE_SIZE as the tailiovec of an SDMA request.Fixing these bugs exposes other bugs with the SDMA pin cache(struct mmu_rb_handler) that get in way of supporting user SDMA requestswith multiple payload iovecs whose buffers do not end at PAGE_SIZE. Sothis commit fixes those issues as well.Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovecpayload user SDMA requests can hit:1. Overlapping memory ranges in mmu_rb_handler will result in duplicate   pinnings.2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node),   the mmu_rb code (1) removes the existing entry under a lock, (2)   releases that lock, pins the new pages, (3) then reacquires the lock   to insert the extended mmu_rb_node.   If someone else comes in and inserts an overlapping entry between (2)   and (3), insert in (3) will fail.   The failure path code in this case unpins _all_ pages in either the   original mmu_rb_node or the new mmu_rb_node that was inserted between   (2) and (3).3. In hfi1_mmu_rb_remove_unless_exact(), mmu_rb_node->refcount is   incremented outside of mmu_rb_handler->lock. As a result, mmu_rb_node   could be evicted by another thread that gets mmu_rb_handler->lock and   checks mmu_rb_node->refcount before mmu_rb_node->refcount is   incremented.4. Related to #2 above, SDMA request submission failure path does not   check mmu_rb_node->refcount before freeing mmu_rb_node object.   If there are other SDMA requests in progress whose iovecs have   pointers to the now-freed mmu_rb_node(s), those pointers to the   now-freed mmu_rb nodes will be dereferenced when those SDMA requests   complete.
Key phrases: datacorruption
CVE-2023-52475: In the Linux kernel, the following vulnerability has been resolved:Input: powermate - fix use-after-free in powermate_config_completesyzbot has found a use-after-free bug [1] in the powermate driver. Thishappens when the device is disconnected, which leads to a memory free fromthe powermate_device struct.  When an asynchronous control messagecompletes after the kfree and its callback is invoked, the lock does notexist anymore and hence the bug.Use usb_kill_urb() on pm->config to cancel any in-progress requests upondevice disconnection.[1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e
Key phrases: use-after-free, use after free
CVE-2023-52476: In the Linux kernel, the following vulnerability has been resolved:perf/x86/lbr: Filter vsyscall addressesWe found that a panic can occur when a vsyscall is made while LBR samplingis active. If the vsyscall is interrupted (NMI) for perf sampling, thiscall sequence can occur (most recent at top):    __insn_get_emulate_prefix()    insn_get_emulate_prefix()    insn_get_prefixes()    insn_get_opcode()    decode_branch_type()    get_branch_type()    intel_pmu_lbr_filter()    intel_pmu_handle_irq()    perf_event_nmi_handler()Within __insn_get_emulate_prefix() at frame 0, a macro is called:    peek_nbyte_next(insn_byte_t, insn, i)Within this macro, this dereference occurs:    (insn)->next_byteInspecting registers at this point, the value of the next_byte field is theaddress of the vsyscall made, for example the location of the vsyscallversion of gettimeofday() at 0xffffffffff600000. The access to an addressin the vsyscall region will trigger an oops due to an unhandled page fault.To fix the bug, filtering for vsyscalls can be done whendetermining the branch type. This patch will returna "none" branch if a kernel address if found to lie in thevsyscall region.
Key phrases: perf lbr
CVE-2023-52477: In the Linux kernel, the following vulnerability has been resolved:usb: hub: Guard against accesses to uninitialized BOS descriptorsMany functions in drivers/usb/core/hub.c and drivers/usb/core/hub.haccess fields inside udev->bos without checking if it was allocated andinitialized. If usb_get_bos_descriptor() fails for whateverreason, udev->bos will be NULL and those accesses will result in acrash:BUG: kernel NULL pointer dereference, address: 0000000000000018PGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP NOPTICPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1>Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021Workqueue: usb_hub_wq hub_eventRIP: 0010:hub_port_reset+0x193/0x788Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0Call Trace:hub_event+0x73f/0x156e? hub_activate+0x5b7/0x68fprocess_one_work+0x1a2/0x487worker_thread+0x11a/0x288kthread+0x13a/0x152? process_one_work+0x487/0x487? kthread_associate_blkcg+0x70/0x70ret_from_fork+0x1f/0x30Fall back to a default behavior if the BOS descriptor isn't accessibleand skip all the functionalities that depend on it: LPM support checks,Super Speed capabilitiy checks, U1/U2 states setup.
CVE-2023-52479: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix uaf in smb20_oplock_break_ackdrop reference after use opinfo.
Key phrases: uaf
CVE-2023-52480: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix race condition between session lookup and expire Thread A                        +  Thread B ksmbd_session_lookup            |  smb2_sess_setup   sess = xa_load                |                                 |                                 |    xa_erase(&conn->sessions, sess->id);                                 |                                 |    ksmbd_session_destroy(sess) --> kfree(sess)                                 |   // UAF!                       |   sess->last_active = jiffies   |                                 +This patch add rwsem to fix race condition between ksmbd_session_lookupand ksmbd_expire_session.
Key phrases: race condition
CVE-2023-52481: In the Linux kernel, the following vulnerability has been resolved:arm64: errata: Add Cortex-A520 speculative unprivileged load workaroundImplement the workaround for ARM Cortex-A520 erratum 2966298. On anaffected Cortex-A520 core, a speculatively executed unprivileged loadmight leak data from a privileged load via a cache side channel. Theissue only exists for loads within a translation regime with the sametranslation (e.g. same ASID and VMID). Therefore, the issue only affectsthe return to EL0.The workaround is to execute a TLBI before returning to EL0 after allloads of privileged data. A non-shareable TLBI to any address issufficient.The workaround isn't necessary if page table isolation (KPTI) isenabled, but for simplicity it will be. Page table isolation shouldnormally be disabled for Cortex-A520 as it supports the CSV3 featureand the E0PD feature (used when KASLR is enabled).
Key phrases: cache side channel
CVE-2023-52482: In the Linux kernel, the following vulnerability has been resolved:x86/srso: Add SRSO mitigation for Hygon processorsAdd mitigation for the speculative return stack overflow vulnerabilitywhich exists on Hygon processors too.
Key phrases: speculative return stack overflow
CVE-2023-52483: In the Linux kernel, the following vulnerability has been resolved:mctp: perform route lookups under a RCU read-side lockOur current route lookups (mctp_route_lookup and mctp_route_lookup_null)traverse the net's route list without the RCU read lock held. This meansthe route lookup is subject to preemption, resulting in an potentialgrace period expiry, and so an eventual kfree() while we still have theroute pointer.Add the proper read-side critical section locks around the routelookups, preventing premption and a possible parallel kfree.The remaining net->mctp.routes accesses are already under arcu_read_lock, or protected by the RTNL for updates.Based on an analysis from Sili Luo <rootlab@huawei.com>, whereintroducing a delay in the route lookup could cause a UAF onsimultaneous sendmsg() and route deletion.
Key phrases: uaf
CVE-2023-52484: In the Linux kernel, the following vulnerability has been resolved:iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_rangeWhen running an SVA case, the following soft lockup is triggered:--------------------------------------------------------------------watchdog: BUG: soft lockup - CPU#244 stuck for 26s!pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50sp : ffff8000d83ef290x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bcx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfax5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000ax2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001Call trace: arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 __arm_smmu_tlb_inv_range+0x118/0x254 arm_smmu_tlb_inv_range_asid+0x6c/0x130 arm_smmu_mm_invalidate_range+0xa0/0xa4 __mmu_notifier_invalidate_range_end+0x88/0x120 unmap_vmas+0x194/0x1e0 unmap_region+0xb4/0x144 do_mas_align_munmap+0x290/0x490 do_mas_munmap+0xbc/0x124 __vm_munmap+0xa8/0x19c __arm64_sys_munmap+0x28/0x50 invoke_syscall+0x78/0x11c el0_svc_common.constprop.0+0x58/0x1c0 do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8--------------------------------------------------------------------Note that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamedto "arm_smmu_mm_arch_invalidate_secondary_tlbs", yet the problem remains.The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variableprotoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occurto SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is calledtypically next to MMU tlb flush function, e.g.	tlb_flush_mmu_tlbonly {		tlb_flush {			__flush_tlb_range {				// check MAX_TLBI_OPS			}		}		mmu_notifier_arch_invalidate_secondary_tlbs {			arm_smmu_mm_arch_invalidate_secondary_tlbs {				// does not check MAX_TLBI_OPS			}		}	}Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in anSVA case SMMU uses the CPU page table, so it makes sense to align with thetlbflush code. Then, replace per-page TLBI commands with a single per-asidTLBI command, if the request size hits this threshold.
CVE-2023-52485: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Wake DMCUB before sending a command[Why]We can hang in place trying to send commands when the DMCUB isn'tpowered on.[How]For functions that execute within a DC context or DC lock we canwrap the direct calls to dm_execute_dmub_cmd/list with code thatexits idle power optimizations and reallows once we're done withthe command submission on success.For DM direct submissions the DM will need to manage the enter/exitsequencing manually.We cannot invoke a DMCUB command directly within the DM executionhelper or we can deadlock.
Key phrases: hang
CVE-2023-52486: In the Linux kernel, the following vulnerability has been resolved:drm: Don't unref the same fb many times by mistake due to deadlock handlingIf we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()we proceed to unref the fb and then retry the whole thing from the top.But we forget to reset the fb pointer back to NULL, and so if we thenget another error during the retry, before the fb lookup, we proceedthe unref the same fb again without having gotten another reference.The end result is that the fb will (eventually) end up being freedwhile it's still in use.Reset fb to NULL once we've unreffed it to avoid doing it againuntil we've done another fb lookup.This turned out to be pretty easy to hit on a DG2 when doing asyncflips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom Isaw that drm_closefb() simply got stuck in a busy loop while walkingthe framebuffer list. Fortunately I was able to convince it to oopsinstead, and from there it was easier to track down the culprit.
Key phrases: convince
CVE-2023-52488: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFOThe SC16IS7XX IC supports a burst mode to access the FIFOs where theinitial register address is sent ($00), followed by all the FIFO datawithout having to resend the register address each time. In this mode, theIC doesn't increment the register address for each R/W byte.The regmap_raw_read() and regmap_raw_write() are functions which canperform IO over multiple registers. They are currently used to read/writefrom/to the FIFO, and although they operate correctly in this burst mode onthe SPI bus, they would corrupt the regmap cache if it was not disabledmanually. The reason is that when the R/W size is more than 1 byte, thesefunctions assume that the register address is incremented and handle thecache accordingly.Convert FIFO R/W functions to use the regmap _noinc_ versions in order toremove the manual cache control which was a workaround when using the_raw_ versions. FIFO registers are properly declared as volatile socache will not be used/updated for FIFO accesses.
CVE-2023-5249: Use After Free vulnerability in Arm Ltd Bifrost GPU Kernel Driver, Arm Ltd Valhall GPU Kernel Driver allows a local non-privileged user to make improper memory processing operations to exploit a software race condition. If the systems memory is carefully prepared by the user, then this in turn cause a use-after-free.This issue affects Bifrost GPU Kernel Driver: from r35p0 through r40p0; Valhall GPU Kernel Driver: from r35p0 through r40p0.
Key phrases: make improper memory processing operations to exploit a, use after free, software race condition
CVE-2023-52490: In the Linux kernel, the following vulnerability has been resolved:mm: migrate: fix getting incorrect page mapping during page migrationWhen running stress-ng testing, we found below kernel crash after a few hours:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000pc : dentry_name+0xd8/0x224lr : pointer+0x22c/0x370sp : ffff800025f134c0......Call trace:  dentry_name+0xd8/0x224  pointer+0x22c/0x370  vsnprintf+0x1ec/0x730  vscnprintf+0x2c/0x60  vprintk_store+0x70/0x234  vprintk_emit+0xe0/0x24c  vprintk_default+0x3c/0x44  vprintk_func+0x84/0x2d0  printk+0x64/0x88  __dump_page+0x52c/0x530  dump_page+0x14/0x20  set_migratetype_isolate+0x110/0x224  start_isolate_page_range+0xc4/0x20c  offline_pages+0x124/0x474  memory_block_offline+0x44/0xf4  memory_subsys_offline+0x3c/0x70  device_offline+0xf0/0x120  ......After analyzing the vmcore, I found this issue is caused by page migration.The scenario is that, one thread is doing page migration, and we will use thetarget page's ->mapping field to save 'anon_vma' pointer between page unmap andpage move, and now the target page is locked and refcount is 1.Currently, there is another stress-ng thread performing memory hotplug,attempting to offline the target page that is being migrated. It discovers thatthe refcount of this target page is 1, preventing the offline operation, thusproceeding to dump the page. However, page_mapping() of the target page mayreturn an incorrect file mapping to crash the system in dump_mapping(), sincethe target page->mapping only saves 'anon_vma' pointer without settingPAGE_MAPPING_ANON flag.There are seveval ways to fix this issue:(1) Setting the PAGE_MAPPING_ANON flag for target page's ->mapping when saving'anon_vma', but this can confuse PageAnon() for PFN walkers, since the targetpage has not built mappings yet.(2) Getting the page lock to call page_mapping() in __dump_page() to avoid crashingthe system, however, there are still some PFN walkers that call page_mapping()without holding the page lock, such as compaction.(3) Using target page->private field to save the 'anon_vma' pointer and 2 bitspage state, just as page->mapping records an anonymous page, which can removethe page_mapping() impact for PFN walkers and also seems a simple way.So I choose option 3 to fix this issue, and this can also fix other potentialissues for PFN walkers, such as compaction.
Key phrases: crash, crash system
CVE-2023-52491: In the Linux kernel, the following vulnerability has been resolved:media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_runIn mtk_jpeg_probe, &jpeg->job_timeout_work is bound withmtk_jpeg_job_timeout_work.In mtk_jpeg_dec_device_run, if error happens inmtk_jpeg_set_dec_dst, it will finally start the worker whilemark the job as finished by invoking v4l2_m2m_job_finish.There are two methods to trigger the bug. If we remove themodule, it which will call mtk_jpeg_remove to make cleanup.The possible sequence is as follows, which will cause ause-after-free bug.CPU0                  CPU1mtk_jpeg_dec_...    |  start worker	    |                    |mtk_jpeg_job_timeout_workmtk_jpeg_remove     |  v4l2_m2m_release  |    kfree(m2m_dev); |                    |                    | v4l2_m2m_get_curr_priv                    |   m2m_dev->curr_ctx //useIf we close the file descriptor, which will call mtk_jpeg_release,it will have a similar sequence.Fix this bug by starting timeout worker only if started jpegdec workersuccessfully. Then v4l2_m2m_job_finish will only be called ineither mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.
Key phrases: use after free bug
CVE-2023-52492: In the Linux kernel, the following vulnerability has been resolved:dmaengine: fix NULL pointer in channel unregistration function__dma_async_device_channel_register() can fail. In case of failure,chan->local is freed (with free_percpu()), and chan->local is nullified.When dma_async_device_unregister() is called (because of managed API orintentionally by DMA controller driver), channels are unconditionallyunregistered, leading to this NULL pointer:[    1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0[...][    1.484499] Call trace:[    1.486930]  device_del+0x40/0x394[    1.490314]  device_unregister+0x20/0x7c[    1.494220]  __dma_async_device_channel_unregister+0x68/0xc0Look at dma_async_device_register() function error path, channel deviceunregistration is done only if chan->local is not NULL.Then add the same condition at the beginning of__dma_async_device_channel_unregister() function, to avoid NULL pointerissue whatever the API used to reach this function.
CVE-2023-52493: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Drop chan lock before queuing buffersEnsure read and write locks for the channel are not taken in succession bydropping the read lock from parse_xfer_event() such that a callback givento client can potentially queue buffers and acquire the write lock in thatprocess. Any queueing of buffers should be done without channel read lockacquired as it can result in multiple locks and a soft lockup.[mani: added fixes tag and cc'ed stable]
Key phrases: soft lockup
CVE-2023-52494: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Add alignment check for event ring read pointerThough we do check the event ring read pointer by "is_valid_ring_ptr"to make sure it is in the buffer range, but there is another risk thepointer may be not aligned.  Since we are expecting event ring elementsare 128 bits(struct mhi_ring_element) aligned, an unaligned read pointercould lead to multiple issues like DoS or ring buffer memory corruption.So add a alignment check for event ring read pointer.
Key phrases: dos
CVE-2023-52495: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: pmic_glink_altmode: fix port sanity checkThe PMIC GLINK altmode driver currently supports at most two ports.Fix the incomplete port sanity check on notifications to avoidaccessing and corrupting memory beyond the port array if we ever get anotification for an unsupported port.
Key phrases: incomplete port sanity check, corrupt memory
CVE-2023-52497: In the Linux kernel, the following vulnerability has been resolved:erofs: fix lz4 inplace decompressionCurrently EROFS can map another compressed buffer for inplacedecompression, that was used to handle the cases that some pages ofcompressed data are actually not in-place I/O.However, like most simple LZ77 algorithms, LZ4 expects the compresseddata is arranged at the end of the decompressed buffer and itexplicitly uses memmove() to handle overlapping:  __________________________________________________________ |_ direction of decompression --> ____ |_ compressed data _|Although EROFS arranges compressed data like this, it typically maps twoindividual virtual buffers so the relative order is uncertain.Previously, it was hardly observed since LZ4 only uses memmove() forshort overlapped literals and x86/arm64 memmove implementations seem tocompletely cover it up and they don't have this issue.  Juhyung reportedthat EROFS data corruption can be found on a new Intel x86 processor.After some analysis, it seems that recent x86 processors with the newFSRM feature expose this issue with "rep movsb".Let's strictly use the decompressed buffer for lz4 inplacedecompression for now.  Later, as an useful improvement, we could tryto tie up these two buffers together in the correct order.
Key phrases: data corruption
CVE-2023-52498: In the Linux kernel, the following vulnerability has been resolved:PM: sleep: Fix possible deadlocks in core system-wide PM codeIt is reported that in low-memory situations the system-wide resume corecode deadlocks, because async_schedule_dev() executes its argumentfunction synchronously if it cannot allocate memory (and not only inthat case) and that function attempts to acquire a mutex that is alreadyheld.  Executing the argument function synchronously from withindpm_async_fn() may also be problematic for ordering reasons (it maycause a consumer device's resume callback to be invoked before arequisite supplier device's one, for example).Address this by changing the code in question to useasync_schedule_dev_nocall() for scheduling the asynchronousexecution of device suspend and resume functions and to directlyrun them synchronously if async_schedule_dev_nocall() returns false.
CVE-2023-52499: In the Linux kernel, the following vulnerability has been resolved:powerpc/47x: Fix 47x syscall return crashEddie reported that newer kernels were crashing during boot on his 476FSP2 system:  kernel tried to execute user page (b7ee2000) - exploit attempt? (uid: 0)  BUG: Unable to handle kernel instruction fetch  Faulting instruction address: 0xb7ee2000  Oops: Kernel access of bad area, sig: 11 [#1]  BE PAGE_SIZE=4K FSP-2  Modules linked in:  CPU: 0 PID: 61 Comm: mount Not tainted 6.1.55-d23900f.ppcnf-fsp2 #1  Hardware name: ibm,fsp2 476fpe 0x7ff520c0 FSP-2  NIP: b7ee2000 LR: 8c008000 CTR: 00000000  REGS: bffebd83 TRAP: 0400 Not tainted (6.1.55-d23900f.ppcnf-fs p2)  MSR: 00000030 <IR,DR> CR: 00001000 XER: 20000000  GPR00: c00110ac bffebe63 bffebe7e bffebe88 8c008000 00001000 00000d12 b7ee2000  GPR08: 00000033 00000000 00000000 c139df10 48224824 1016c314 10160000 00000000  GPR16: 10160000 10160000 00000008 00000000 10160000 00000000 10160000 1017f5b0  GPR24: 1017fa50 1017f4f0 1017fa50 1017f740 1017f630 00000000 00000000 1017f4f0  NIP [b7ee2000] 0xb7ee2000  LR [8c008000] 0x8c008000  Call Trace:  Instruction dump:  XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX  XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX  ---[ end trace 0000000000000000 ]---The problem is in ret_from_syscall where the check foricache_44x_need_flush is done. When the flush is needed the code jumpsout-of-line to do the flush, and then intends to jump back to continuethe syscall return.However the branch back to label 1b doesn't return to the correctlocation, instead branching back just prior to the return to userspace,causing bogus register values to be used by the rfi.The breakage was introduced by commit 6f76a01173cc("powerpc/syscall: implement system call entry/exit logic in C for PPC32") whichinadvertently removed the "1" label and reused it elsewhere.Fix it by adding named local labels in the correct locations. Note thatthe return label needs to be outside the ifdef so that CONFIG_PPC_47x=ncompiles.
Key phrases: crash
CVE-2023-5250: The Grid Plus plugin for WordPress is vulnerable to Local File Inclusion in versions up to, and including, 1.3.2 via a shortcode attribute. This allows subscriber-level, and above, attackers to include and execute arbitrary files on the server, allowing the execution of any PHP code in those files. This can be used to bypass access controls, obtain sensitive data, or achieve code execution in cases where PHP files with arbitrary content can be uploaded and included. This is limited to .php files.
Key phrases: execute arbitrary files, bypass access controls, obtain sensitive data, include and execute arbitrary files on the server, local file inclusion, code execution
CVE-2023-52500: In the Linux kernel, the following vulnerability has been resolved:scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG commandTags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freedwhen we receive the response.
CVE-2023-52501: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Do not attempt to read past "commit"When iterating over the ring buffer while the ring buffer is active, thewriter can corrupt the reader. There's barriers to help detect this andhandle it, but that code missed the case where the last event was at thevery end of the page and has only 4 bytes left.The checks to detect the corruption by the writer to reads needs to see thelength of the event. If the length in the first 4 bytes is zero then thelength is stored in the second 4 bytes. But if the writer is in the processof updating that code, there's a small window where the length in the first4 bytes could be zero even though the length is only 4 bytes. That willcause rb_event_length() to read the next 4 bytes which could happen to be off theallocated page.To protect against this, fail immediately if the next event pointer isless than 8 bytes from the end of the commit (last byte of data), as allevents must be a minimum of 8 bytes anyway.
Key phrases: ring-buffer
CVE-2023-52502: In the Linux kernel, the following vulnerability has been resolved:net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.Getting a reference on the socket found in a lookup whileholding a lock should happen before releasing the lock.nfc_llcp_sock_get_sn() has a similar problem.Finally nfc_llcp_recv_snl() needs to make sure the socketfound by nfc_llcp_sock_from_sn() does not disappear.
Key phrases: uaf
CVE-2023-52503: In the Linux kernel, the following vulnerability has been resolved:tee: amdtee: fix use-after-free vulnerability in amdtee_close_sessionThere is a potential race condition in amdtee_close_session that maycause use-after-free in amdtee_open_session. For instance, if a sessionhas refcount == 1, and one thread tries to free this session via:    kref_put(&sess->refcount, destroy_session);the reference count will get decremented, and the next step would be tocall destroy_session(). However, if in another thread,amdtee_open_session() is called before destroy_session() has completedexecution, alloc_session() may return 'sess' that will be freed uplater in destroy_session() leading to use-after-free inamdtee_open_session.To fix this issue, treat decrement of sess->refcount and removal of'sess' from session list in destroy_session() as a critical section, sothat it is executed atomically.
Key phrases: use-after-free, use after free, race condition
CVE-2023-52504: In the Linux kernel, the following vulnerability has been resolved:x86/alternatives: Disable KASAN in apply_alternatives()Fei has reported that KASAN triggers during apply_alternatives() ona 5-level paging machine:	BUG: KASAN: out-of-bounds in rcu_is_watching()	Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0	...	__asan_load4()	rcu_is_watching()	trace_hardirqs_on()	text_poke_early()	apply_alternatives()	...On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on__VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().KASAN gets confused when apply_alternatives() patches theKASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_STARTstatic, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.Fix it for real by disabling KASAN while the kernel is patching alternatives.[ mingo: updated the changelog ]
CVE-2023-52505: In the Linux kernel, the following vulnerability has been resolved:phy: lynx-28g: serialize concurrent phy_set_mode_ext() calls to shared registersThe protocol converter configuration registers PCC8, PCCC, PCCD(implemented by the driver), as well as others, control protocolconverters from multiple lanes (each represented as a differentstruct phy). So, if there are simultaneous calls to phy_set_mode_ext()to lanes sharing the same PCC register (either for the "old" or for the"new" protocol), corruption of the values programmed to hardware ispossible, because lynx_28g_rmw() has no locking.Add a spinlock in the struct lynx_28g_priv shared by all lanes, and takethe global spinlock from the phy_ops :: set_mode() implementation. Thereare no other callers which modify PCC registers.
CVE-2023-52507: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: assert requested protocol is validThe protocol is used in a bit mask to determine if the protocol issupported. Assert the provided protocol is less than the maximumdefined so it doesn't potentially perform a shift-out-of-bounds andprovide a clearer error for undefined protocols vs unsupported ones.
Key phrases: shift-out-of-bounds
CVE-2023-52508: In the Linux kernel, the following vulnerability has been resolved:nvme-fc: Prevent null pointer dereference in nvme_fc_io_getuuid()The nvme_fc_fcp_op structure describing an AEN operation is initialized with anull request structure pointer. An FC LLDD may make a call tonvme_fc_io_getuuid passing a pointer to an nvmefc_fcp_req for an AEN operation.Add validation of the request structure pointer before dereference.
Key phrases: null pointer dereference
CVE-2023-52509: In the Linux kernel, the following vulnerability has been resolved:ravb: Fix use-after-free issue in ravb_tx_timeout_work()The ravb_stop() should call cancel_work_sync(). Otherwise,ravb_tx_timeout_work() is possible to use the freed priv afterravb_remove() was called like below:CPU0			CPU1			ravb_tx_timeout()ravb_remove()unregister_netdev()free_netdev(ndev)// free priv			ravb_tx_timeout_work()			// use privunregister_netdev() will call .ndo_stop() so that ravb_stop() iscalled. And, after phy_stop() is called, netif_carrier_off()is also called. So that .ndo_tx_timeout() will not be calledafter phy_stop().
Key phrases: use-after-free issue, use after free
CVE-2023-5251: The Grid Plus plugin for WordPress is vulnerable to unauthorized modification of data and loss of data due to a missing capability check on the 'grid_plus_save_layout_callback' and 'grid_plus_delete_callback' functions in versions up to, and including, 1.3.2. This makes it possible for authenticated attackers with subscriber privileges or above, to add, update or delete grid layout.
Key phrases: unauthorized modification of data, loss of data, missing capability check
CVE-2023-52510: In the Linux kernel, the following vulnerability has been resolved:ieee802154: ca8210: Fix a potential UAF in ca8210_probeIf of_clk_add_provider() fails in ca8210_register_ext_clock(),it calls clk_unregister() to release priv->clk and returns anerror. However, the caller ca8210_probe() then calls ca8210_remove(),where priv->clk is freed again in ca8210_unregister_ext_clock(). Inthis case, a use-after-free may happen in the second time we callclk_unregister().Fix this by removing the first clk_unregister(). Also, priv->clk couldbe an error code on failure of clk_register_fixed_rate(). UseIS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().
Key phrases: uaf, use-after-free, use after free
CVE-2023-52511: In the Linux kernel, the following vulnerability has been resolved:spi: sun6i: reduce DMA RX transfer width to single byteThrough empirical testing it has been determined that sometimes RX SPItransfers with DMA enabled return corrupted data. This is down to singleor even multiple bytes lost during DMA transfer from SPI peripheral tomemory. It seems the RX FIFO within the SPI peripheral can becomeconfused when performing bus read accesses wider than a single byte to itduring an active SPI transfer.This patch reduces the width of individual DMA read accesses to theRX FIFO to a single byte to mitigate that issue.
CVE-2023-52512: In the Linux kernel, the following vulnerability has been resolved:pinctrl: nuvoton: wpcm450: fix out of bounds writeWrite into 'pctrl->gpio_bank' happens before the check for GPIO indexvalidity, so out of bounds write may happen.Found by Linux Verification Center (linuxtesting.org) with SVACE.
Key phrases: out of bounds writewrite
CVE-2023-52513: In the Linux kernel, the following vulnerability has been resolved:RDMA/siw: Fix connection failure handlingIn case immediate MPA request processing fails, the newlycreated endpoint unlinks the listening endpoint and isready to be dropped. This special case was not handledcorrectly by the code handling the later TCP socket close,causing a NULL dereference crash in siw_cm_work_handler()when dereferencing a NULL listener. We now also cancelthe useless MPA timeout, if immediate MPA requestprocessing fails.This patch furthermore simplifies MPA processing in general:Scheduling a useless TCP socket read in sk_data_ready() upcallis now surpressed, if the socket is already moved out ofTCP_ESTABLISHED state.
Key phrases: null dereference crash
CVE-2023-52515: In the Linux kernel, the following vulnerability has been resolved:RDMA/srp: Do not call scsi_done() from srp_abort()After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handlercallback, it performs one of the following actions:* Call scsi_queue_insert().* Call scsi_finish_command().* Call scsi_eh_scmd_add().Hence, SCSI abort handlers must not call scsi_done(). Otherwise allthe above actions would trigger a use-after-free. Hence remove thescsi_done() call from srp_abort(). Keep the srp_free_req() callbefore returning SUCCESS because we may not see the command again ifSUCCESS is returned.
Key phrases: use-after-free, use after free
CVE-2023-52517: In the Linux kernel, the following vulnerability has been resolved:spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drainPreviously the transfer complete IRQ immediately drained to RX FIFO toread any data remaining in FIFO to the RX buffer. This behaviour iscorrect when dealing with SPI in interrupt mode. However in DMA mode thetransfer complete interrupt still fires as soon as all bytes to betransferred have been stored in the FIFO. At that point data in the FIFOstill needs to be picked up by the DMA engine. Thus the drain procedureand DMA engine end up racing to read from RX FIFO, corrupting any dataread. Additionally the RX buffer pointer is never adjusted according toDMA progress in DMA mode, thus calling the RX FIFO drain procedure in DMAmode is a bug.Fix corruptions in DMA RX mode by draining RX FIFO only in interrupt mode.Also wait for completion of RX DMA when in DMA mode before returning toensure all data has been copied to the supplied memory buffer.
CVE-2023-52518: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_codec: Fix leaking content of local_codecsThe following memory leak can be observed when the controller supportscodecs which are stored in local_codecs list but the elements are neverfreed:unreferenced object 0xffff88800221d840 (size 32):  comm "kworker/u3:0", pid 36, jiffies 4294898739 (age 127.060s)  hex dump (first 32 bytes):    f8 d3 02 03 80 88 ff ff 80 d8 21 02 80 88 ff ff  ..........!.....    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................  backtrace:    [<ffffffffb324f557>] __kmalloc+0x47/0x120    [<ffffffffb39ef37d>] hci_codec_list_add.isra.0+0x2d/0x160    [<ffffffffb39ef643>] hci_read_codec_capabilities+0x183/0x270    [<ffffffffb39ef9ab>] hci_read_supported_codecs+0x1bb/0x2d0    [<ffffffffb39f162e>] hci_read_local_codecs_sync+0x3e/0x60    [<ffffffffb39ff1b3>] hci_dev_open_sync+0x943/0x11e0    [<ffffffffb396d55d>] hci_power_on+0x10d/0x3f0    [<ffffffffb30c99b4>] process_one_work+0x404/0x800    [<ffffffffb30ca134>] worker_thread+0x374/0x670    [<ffffffffb30d9108>] kthread+0x188/0x1c0    [<ffffffffb304db6b>] ret_from_fork+0x2b/0x50    [<ffffffffb300206a>] ret_from_fork_asm+0x1a/0x30
Key phrases: memory leak