{"schema_version":"1.7.2","id":"OESA-2024-1392","modified":"2024-04-12T11:07:37Z","published":"2024-04-12T11:07:37Z","upstream":["CVE-2020-36777","CVE-2020-36780","CVE-2020-36784","CVE-2021-46904","CVE-2021-46924","CVE-2021-46926","CVE-2021-46928","CVE-2021-46934","CVE-2021-46935","CVE-2021-46952","CVE-2021-46989","CVE-2021-47086","CVE-2021-47112","CVE-2021-47113","CVE-2021-47114","CVE-2021-47122","CVE-2023-52443","CVE-2023-52469","CVE-2023-52476","CVE-2023-52502","CVE-2023-52509","CVE-2023-52599","CVE-2023-52600","CVE-2023-52601","CVE-2023-52602","CVE-2023-52603","CVE-2024-23307","CVE-2024-24855","CVE-2024-26597","CVE-2024-26600","CVE-2024-26606","CVE-2024-26622","CVE-2024-26625"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: dvbdev: Fix memory leak in dvb_media_device_free()\r\n\r\ndvb_media_device_free() is leaking memory. Free `dvbdev-\u0026gt;adapter-\u0026gt;conn`\nbefore setting it to NULL, as documented in include/media/media-device.h:\n\u0026quot;The media_entity instance itself must be freed explicitly by the driver\nif required.\u0026quot;(CVE-2020-36777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: sprd: fix reference leak when pm_runtime_get_sync fails\r\n\r\nThe PM reference count is not expected to be incremented on\nreturn in sprd_i2c_master_xfer() and sprd_i2c_remove().\r\n\r\nHowever, pm_runtime_get_sync will increment the PM reference\ncount even failed. Forgetting to putting operation will result\nin a reference leak here.\r\n\r\nReplace it with pm_runtime_resume_and_get to keep usage\ncounter balanced.(CVE-2020-36780)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: cadence: fix reference leak when pm_runtime_get_sync fails\r\n\r\nThe PM reference count is not expected to be incremented on\nreturn in functions cdns_i2c_master_xfer and cdns_reg_slave.\r\n\r\nHowever, pm_runtime_get_sync will increment pm usage counter\neven failed. Forgetting to putting operation will result in a\nreference leak here.\r\n\r\nReplace it with pm_runtime_resume_and_get to keep usage\ncounter balanced.(CVE-2020-36784)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hso: fix null-ptr-deref during tty device unregistration\r\n\r\nMultiple ttys try to claim the same the minor number causing a double\nunregistration of the same device. The first unregistration succeeds\nbut the next one results in a null-ptr-deref.\r\n\r\nThe get_free_serial_index() function returns an available minor number\nbut doesn\u0026apos;t assign it immediately. The assignment is done by the caller\nlater. But before this assignment, calls to get_free_serial_index()\nwould return the same minor number.\r\n\r\nFix this by modifying get_free_serial_index to assign the minor number\nimmediately after one is found to be and rename it to obtain_minor()\nto better reflect what it does. Similary, rename set_serial_by_index()\nto release_minor() and modify it to free up the minor number of the\ngiven hso_serial. Every obtain_minor() should have corresponding\nrelease_minor() call.(CVE-2021-46904)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFC: st21nfca: Fix memory leak in device probe and remove\r\n\r\n\u0026apos;phy-\u0026gt;pending_skb\u0026apos; is alloced when device probe, but forgot to free\nin the error handling path and remove path, this cause memory leak\nas follows:\r\n\r\nunreferenced object 0xffff88800bc06800 (size 512):\n  comm \u0026quot;8\u0026quot;, pid 11775, jiffies 4295159829 (age 9.032s)\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [\u0026lt;00000000d66c09ce\u0026gt;] __kmalloc_node_track_caller+0x1ed/0x450\n    [\u0026lt;00000000c93382b3\u0026gt;] kmalloc_reserve+0x37/0xd0\n    [\u0026lt;000000005fea522c\u0026gt;] __alloc_skb+0x124/0x380\n    [\u0026lt;0000000019f29f9a\u0026gt;] st21nfca_hci_i2c_probe+0x170/0x8f2\r\n\r\nFix it by freeing \u0026apos;pending_skb\u0026apos; in error and remove.(CVE-2021-46924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: hda: intel-sdw-acpi: harden detection of controller\r\n\r\nThe existing code currently sets a pointer to an ACPI handle before\nchecking that it\u0026apos;s actually a SoundWire controller. This can lead to\nissues where the graph walk continues and eventually fails, but the\npointer was set already.\r\n\r\nThis patch changes the logic so that the information provided to\nthe caller is set when a controller is found.(CVE-2021-46926)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nparisc: Clear stale IIR value on instruction access rights trap\r\n\r\nWhen a trap 7 (Instruction access rights) occurs, this means the CPU\ncouldn\u0026apos;t execute an instruction due to missing execute permissions on\nthe memory region.  In this case it seems the CPU didn\u0026apos;t even fetched\nthe instruction from memory and thus did not store it in the cr19 (IIR)\nregister before calling the trap handler. So, the trap handler will find\nsome random old stale value in cr19.\r\n\r\nThis patch simply overwrites the stale IIR value with a constant magic\n\u0026quot;bad food\u0026quot; value (0xbaadf00d), in the hope people don\u0026apos;t start to try to\nunderstand the various random IIR values in trap 7 dumps.(CVE-2021-46928)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: validate user data in compat ioctl\r\n\r\nWrong user data may cause warning in i2c_transfer(), ex: zero msgs.\nUserspace should not be able to trigger warnings, so this patch adds\nvalidation checks for user data in compact ioctl to prevent reported\nwarnings(CVE-2021-46934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: fix async_free_space accounting for empty parcels\r\n\r\nIn 4.13, commit 74310e06be4d (\u0026quot;android: binder: Move buffer out of area shared with user space\u0026quot;)\nfixed a kernel structure visibility issue. As part of that patch,\nsizeof(void *) was used as the buffer size for 0-length data payloads so\nthe driver could detect abusive clients sending 0-length asynchronous\ntransactions to a server by enforcing limits on async_free_size.\r\n\r\nUnfortunately, on the \u0026quot;free\u0026quot; side, the accounting of async_free_space\ndid not add the sizeof(void *) back. The result was that up to 8-bytes of\nasync_free_space were leaked on every async transaction of 8-bytes or\nless.  These small transactions are uncommon, so this accounting issue\nhas gone undetected for several years.\r\n\r\nThe fix is to use \u0026quot;buffer_size\u0026quot; (the allocated buffer size) instead of\n\u0026quot;size\u0026quot; (the logical buffer size) when updating the async_free_space\nduring the free operation. These are the same except for this\ncorner case of asynchronous transactions with payloads \u0026lt; 8 bytes.(CVE-2021-46935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNFS: fs_context: validate UDP retrans to prevent shift out-of-bounds\r\n\r\nFix shift out-of-bounds in xprt_calc_majortimeo(). This is caused\nby a garbage timeout (retrans) mount option being passed to nfs mount,\nin this case from syzkaller.\r\n\r\nIf the protocol is XPRT_TRANSPORT_UDP, then \u0026apos;retrans\u0026apos; is a shift\nvalue for a 64-bit long integer, so \u0026apos;retrans\u0026apos; cannot be \u0026gt;= 64.\nIf it is \u0026gt;= 64, fail the mount and return an error.(CVE-2021-46952)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhfsplus: prevent corruption in shrinking truncate\r\n\r\nI believe there are some issues introduced by commit 31651c607151\n(\u0026quot;hfsplus: avoid deadlock on file truncation\u0026quot;)\r\n\r\nHFS+ has extent records which always contains 8 extents.  In case the\nfirst extent record in catalog file gets full, new ones are allocated from\nextents overflow file.\r\n\r\nIn case shrinking truncate happens to middle of an extent record which\nlocates in extents overflow file, the logic in hfsplus_file_truncate() was\nchanged so that call to hfs_brec_remove() is not guarded any more.\r\n\r\nRight action would be just freeing the extents that exceed the new size\ninside extent record by calling hfsplus_free_extents(), and then check if\nthe whole extent record should be removed.  However since the guard\n(blk_cnt \u0026gt; start) is now after the call to hfs_brec_remove(), this has\nunfortunate effect that the last matching extent record is removed\nunconditionally.\r\n\r\nTo reproduce this issue, create a file which has at least 10 extents, and\nthen perform shrinking truncate into middle of the last extent record, so\nthat the number of remaining extents is not under or divisible by 8.  This\ncauses the last extent record (8 extents) to be removed totally instead of\ntruncating into middle of it.  Thus this causes corruption, and lost data.\r\n\r\nFix for this is simply checking if the new truncated end is below the\nstart of this extent record, making it safe to remove the full extent\nrecord.  However call to hfs_brec_remove() can\u0026apos;t be moved to it\u0026apos;s previous\nplace since we\u0026apos;re dropping -\u0026gt;tree_lock and it can cause a race condition\nand the cached info being invalidated possibly corrupting the node data.\r\n\r\nAnother issue is related to this one.  When entering into the block\n(blk_cnt \u0026gt; start) we are not holding the -\u0026gt;tree_lock.  We break out from\nthe loop not holding the lock, but hfs_find_exit() does unlock it.  Not\nsure if it\u0026apos;s possible for someone else to take the lock under our feet,\nbut it can cause hard to debug errors and premature unlocking.  Even if\nthere\u0026apos;s no real risk of it, the locking should still always be kept in\nbalance.  Thus taking the lock now just before the check.(CVE-2021-46989)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nphonet/pep: refuse to enable an unbound pipe\r\n\r\nThis ioctl() implicitly assumed that the socket was already bound to\na valid local socket name, i.e. Phonet object. If the socket was not\nbound, two separate problems would occur:\r\n\r\n1) We\u0026apos;d send an pipe enablement request with an invalid source object.\n2) Later socket calls could BUG on the socket unexpectedly being\n   connected yet not bound to a valid object.(CVE-2021-47086)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nx86/kvm: Teardown PV features on boot CPU as well\r\n\r\nVarious PV features (Async PF, PV EOI, steal time) work through memory\nshared with hypervisor and when we restore from hibernation we must\nproperly teardown all these features to make sure hypervisor doesn\u0026apos;t\nwrite to stale locations after we jump to the previously hibernated kernel\n(which can try to place anything there). For secondary CPUs the job is\nalready done by kvm_cpu_down_prepare(), register syscore ops to do\nthe same for boot CPU.(CVE-2021-47112)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: abort in rename_exchange if we fail to insert the second ref\r\n\r\nError injection stress uncovered a problem where we\u0026apos;d leave a dangling\ninode ref if we failed during a rename_exchange.  This happens because\nwe insert the inode ref for one side of the rename, and then for the\nother side.  If this second inode ref insert fails we\u0026apos;ll leave the first\none dangling and leave a corrupt file system behind.  Fix this by\naborting if we did the insert for the first inode ref.(CVE-2021-47113)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: fix data corruption by fallocate\r\n\r\nWhen fallocate punches holes out of inode size, if original isize is in\nthe middle of last cluster, then the part from isize to the end of the\ncluster will be zeroed with buffer write, at that time isize is not yet\nupdated to match the new size, if writeback is kicked in, it will invoke\nocfs2_writepage()-\u0026gt;block_write_full_page() where the pages out of inode\nsize will be dropped.  That will cause file corruption.  Fix this by\nzero out eof blocks when extending the inode size.\r\n\r\nRunning the following command with qemu-image 4.2.1 can get a corrupted\ncoverted image file easily.\r\n\r\n    qemu-img convert -p -t none -T none -f qcow2 $qcow_image \\\n             -O qcow2 -o compat=1.1 $qcow_image.conv\r\n\r\nThe usage of fallocate in qemu is like this, it first punches holes out\nof inode size, then extend the inode size.\r\n\r\n    fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0\n    fallocate(11, 0, 2276196352, 65536) = 0\r\n\r\nv1: https://www.spinics.net/lists/linux-fsdevel/msg193999.html\nv2: https://lore.kernel.org/linux-fsdevel/20210525093034.GB4112@quack2.suse.cz/T/(CVE-2021-47114)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: caif: fix memory leak in caif_device_notify\r\n\r\nIn case of caif_enroll_dev() fail, allocated\nlink_support won\u0026apos;t be assigned to the corresponding\nstructure. So simply free allocated pointer in case\nof error(CVE-2021-47122)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: avoid crash when parsed profile name is empty\r\n\r\nWhen processing a packed profile in unpack_profile() described like\r\n\r\n \u0026quot;profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}\u0026quot;\r\n\r\na string \u0026quot;:samba-dcerpcd\u0026quot; is unpacked as a fully-qualified name and then\npassed to aa_splitn_fqname().\r\n\r\naa_splitn_fqname() treats \u0026quot;:samba-dcerpcd\u0026quot; as only containing a namespace.\nThus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later\naa_alloc_profile() crashes as the new profile name is NULL now.\r\n\r\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014\nRIP: 0010:strlen+0x1e/0xa0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? strlen+0x1e/0xa0\n aa_policy_init+0x1bb/0x230\n aa_alloc_profile+0xb1/0x480\n unpack_profile+0x3bc/0x4960\n aa_unpack+0x309/0x15e0\n aa_replace_profiles+0x213/0x33c0\n policy_update+0x261/0x370\n profile_replace+0x20e/0x2a0\n vfs_write+0x2af/0xe00\n ksys_write+0x126/0x250\n do_syscall_64+0x46/0xf0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\n \u0026lt;/TASK\u0026gt;\n---[ end trace 0000000000000000 ]---\nRIP: 0010:strlen+0x1e/0xa0\r\n\r\nIt seems such behaviour of aa_splitn_fqname() is expected and checked in\nother places where it is called (e.g. aa_remove_profiles). Well, there\nis an explicit comment \u0026quot;a ns name without a following profile is allowed\u0026quot;\ninside.\r\n\r\nAFAICS, nothing can prevent unpacked \u0026quot;name\u0026quot; to be in form like\n\u0026quot;:samba-dcerpcd\u0026quot; - it is passed from userspace.\r\n\r\nDeny the whole profile set replacement in such case and inform user with\nEPROTO and an explaining message.\r\n\r\nFound by Linux Verification Center (linuxtesting.org).(CVE-2023-52443)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers/amd/pm: fix a use-after-free in kv_parse_power_table\r\n\r\nWhen ps allocated by kzalloc equals to NULL, kv_parse_power_table\nfrees adev-\u0026gt;pm.dpm.ps that allocated before. However, after the control\nflow goes through the following call chains:\r\n\r\nkv_parse_power_table\n  |-\u0026gt; kv_dpm_init\n        |-\u0026gt; kv_dpm_sw_init\n\t      |-\u0026gt; kv_dpm_fini\r\n\r\nThe adev-\u0026gt;pm.dpm.ps is used in the for loop of kv_dpm_fini after its\nfirst free in kv_parse_power_table and causes a use-after-free bug.(CVE-2023-52469)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/x86/lbr: Filter vsyscall addresses\r\n\r\nWe found that a panic can occur when a vsyscall is made while LBR sampling\nis active. If the vsyscall is interrupted (NMI) for perf sampling, this\ncall sequence can occur (most recent at top):\r\n\r\n    __insn_get_emulate_prefix()\n    insn_get_emulate_prefix()\n    insn_get_prefixes()\n    insn_get_opcode()\n    decode_branch_type()\n    get_branch_type()\n    intel_pmu_lbr_filter()\n    intel_pmu_handle_irq()\n    perf_event_nmi_handler()\r\n\r\nWithin __insn_get_emulate_prefix() at frame 0, a macro is called:\r\n\r\n    peek_nbyte_next(insn_byte_t, insn, i)\r\n\r\nWithin this macro, this dereference occurs:\r\n\r\n    (insn)-\u0026gt;next_byte\r\n\r\nInspecting registers at this point, the value of the next_byte field is the\naddress of the vsyscall made, for example the location of the vsyscall\nversion of gettimeofday() at 0xffffffffff600000. The access to an address\nin the vsyscall region will trigger an oops due to an unhandled page fault.\r\n\r\nTo fix the bug, filtering for vsyscalls can be done when\ndetermining the branch type. This patch will return\na \u0026quot;none\u0026quot; branch if a kernel address if found to lie in the\nvsyscall region.(CVE-2023-52476)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()\r\n\r\nSili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.\r\n\r\nGetting a reference on the socket found in a lookup while\nholding a lock should happen before releasing the lock.\r\n\r\nnfc_llcp_sock_get_sn() has a similar problem.\r\n\r\nFinally nfc_llcp_recv_snl() needs to make sure the socket\nfound by nfc_llcp_sock_from_sn() does not disappear.(CVE-2023-52502)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nravb: Fix use-after-free issue in ravb_tx_timeout_work()\r\n\r\nThe ravb_stop() should call cancel_work_sync(). Otherwise,\nravb_tx_timeout_work() is possible to use the freed priv after\nravb_remove() was called like below:\r\n\r\nCPU0\t\t\tCPU1\n\t\t\travb_tx_timeout()\nravb_remove()\nunregister_netdev()\nfree_netdev(ndev)\n// free priv\n\t\t\travb_tx_timeout_work()\n\t\t\t// use priv\r\n\r\nunregister_netdev() will call .ndo_stop() so that ravb_stop() is\ncalled. And, after phy_stop() is called, netif_carrier_off()\nis also called. So that .ndo_tx_timeout() will not be called\nafter phy_stop().(CVE-2023-52509)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix array-index-out-of-bounds in diNewExt\r\n\r\n[Syz report]\nUBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2\nindex -878706688 is out of range for type \u0026apos;struct iagctl[128]\u0026apos;\nCPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106\n ubsan_epilogue lib/ubsan.c:217 [inline]\n __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348\n diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360\n diAllocExt fs/jfs/jfs_imap.c:1949 [inline]\n diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666\n diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587\n ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56\n jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225\n vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106\n do_mkdirat+0x264/0x3a0 fs/namei.c:4129\n __do_sys_mkdir fs/namei.c:4149 [inline]\n __se_sys_mkdir fs/namei.c:4147 [inline]\n __x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\nRIP: 0033:0x7fcb7e6a0b57\nCode: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053\nRAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57\nRDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140\nRBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\r\n\r\n[Analysis]\nWhen the agstart is too large, it can cause agno overflow.\r\n\r\n[Fix]\nAfter obtaining agno, if the value is invalid, exit the subsequent process.\r\n\r\n\nModified the test from agno \u0026gt; MAXAG to agno \u0026gt;= MAXAG based on linux-next\nreport by kernel test robot (Dan Carpenter).(CVE-2023-52599)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix uaf in jfs_evict_inode\r\n\r\nWhen the execution of diMount(ipimap) fails, the object ipimap that has been\nreleased may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs\nwhen rcu_core() calls jfs_free_node().\r\n\r\nTherefore, when diMount(ipimap) fails, sbi-\u0026gt;ipimap should not be initialized as\nipimap.(CVE-2023-52600)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix array-index-out-of-bounds in dbAdjTree\r\n\r\nCurrently there is a bound check missing in the dbAdjTree while\naccessing the dmt_stree. To add the required check added the bool is_ctl\nwhich is required to determine the size as suggest in the following\ncommit.\nhttps://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/(CVE-2023-52601)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\njfs: fix slab-out-of-bounds Read in dtSearch\r\n\r\nCurrently while searching for current page in the sorted entry table\nof the page there is a out of bound access. Added a bound check to fix\nthe error.\r\n\r\nDave:\nSet return code to -EIO(CVE-2023-52602)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUBSAN: array-index-out-of-bounds in dtSplitRoot\r\n\r\nSyzkaller reported the following issue:\r\n\r\noop0: detected capacity change from 0 to 32768\r\n\r\nUBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9\nindex -2 is out of range for type \u0026apos;struct dtslot [128]\u0026apos;\nCPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106\n ubsan_epilogue lib/ubsan.c:151 [inline]\n __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283\n dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971\n dtSplitUp fs/jfs/jfs_dtree.c:985 [inline]\n dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863\n jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270\n vfs_mkdir+0x3b3/0x590 fs/namei.c:4013\n do_mkdirat+0x279/0x550 fs/namei.c:4038\n __do_sys_mkdirat fs/namei.c:4053 [inline]\n __se_sys_mkdirat fs/namei.c:4051 [inline]\n __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7fcdc0113fd9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9\nRDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003\nRBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0\nR10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000\nR13: 0000000000000000 R14: 00083878000000f8 R15: 0000000000000000\n \u0026lt;/TASK\u0026gt;\r\n\r\nThe issue is caused when the value of fsi becomes less than -1.\nThe check to break the loop when fsi value becomes -1 is present\nbut syzbot was able to produce value less than -1 which cause the error.\nThis patch simply add the change for the values less than 0.\r\n\r\nThe patch is tested via syzbot.(CVE-2023-52603)\r\n\r\nInteger Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.(CVE-2024-23307)\r\n\r\nA race condition was found in the Linux kernel\u0026apos;s scsi device driver in lpfc_unregister_fcf_rescan() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.\r\n\r\n\r\n\r\n\n(CVE-2024-24855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: qualcomm: rmnet: fix global oob in rmnet_policy\r\n\r\nThe variable rmnet_link_ops assign a *bigger* maxtype which leads to a\nglobal out-of-bounds read when parsing the netlink attributes. See bug\ntrace below:\r\n\r\n==================================================================\nBUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]\nBUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600\nRead of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207\r\n\r\nCPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G                 N 6.1.0 #3\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:284 [inline]\n print_report+0x172/0x475 mm/kasan/report.c:395\n kasan_report+0xbb/0x1c0 mm/kasan/report.c:495\n validate_nla lib/nlattr.c:386 [inline]\n __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600\n __nla_parse+0x3e/0x50 lib/nlattr.c:697\n nla_parse_nested_deprecated include/net/netlink.h:1248 [inline]\n __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485\n rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594\n rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091\n netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921\n sock_sendmsg_nosec net/socket.c:714 [inline]\n sock_sendmsg+0x154/0x190 net/socket.c:734\n ____sys_sendmsg+0x6df/0x840 net/socket.c:2482\n ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536\n __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7fdcf2072359\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359\nRDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003\nRBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000\n \u0026lt;/TASK\u0026gt;\r\n\r\nThe buggy address belongs to the variable:\n rmnet_policy+0x30/0xe0\r\n\r\nThe buggy address belongs to the physical page:\npage:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243\nflags: 0x200000000001000(reserved|node=0|zone=2)\nraw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000\nraw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\r\n\r\nMemory state around the buggy address:\n ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07\n ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9\n\u0026gt;ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9\n                                                 ^\n ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9\n ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9\r\n\r\nAccording to the comment of `nla_parse_nested_deprecated`, the maxtype\nshould be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here.(CVE-2024-26597)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nphy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP\r\n\r\nIf the external phy working together with phy-omap-usb2 does not implement\nsend_srp(), we may still attempt to call it. This can happen on an idle\nEthernet gadget triggering a wakeup for example:\r\n\r\nconfigfs-gadget.g1 gadget.0: ECM Suspend\nconfigfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup\n...\nUnable to handle kernel NULL pointer dereference at virtual address\n00000000 when execute\n...\nPC is at 0x0\nLR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]\n...\nmusb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]\nusb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]\neth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c\ndev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4\nsch_direct_xmit from __dev_queue_xmit+0x334/0xd88\n__dev_queue_xmit from arp_solicit+0xf0/0x268\narp_solicit from neigh_probe+0x54/0x7c\nneigh_probe from __neigh_event_send+0x22c/0x47c\n__neigh_event_send from neigh_resolve_output+0x14c/0x1c0\nneigh_resolve_output from ip_finish_output2+0x1c8/0x628\nip_finish_output2 from ip_send_skb+0x40/0xd8\nip_send_skb from udp_send_skb+0x124/0x340\nudp_send_skb from udp_sendmsg+0x780/0x984\nudp_sendmsg from __sys_sendto+0xd8/0x158\n__sys_sendto from ret_fast_syscall+0x0/0x58\r\n\r\nLet\u0026apos;s fix the issue by checking for send_srp() and set_vbus() before\ncalling them. For USB peripheral only cases these both could be NULL.(CVE-2024-26600)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: signal epoll threads of self-work\r\n\r\nIn (e)poll mode, threads often depend on I/O events to determine when\ndata is ready for consumption. Within binder, a thread may initiate a\ncommand via BINDER_WRITE_READ without a read buffer and then make use\nof epoll_wait() or similar to consume any responses afterwards.\r\n\r\nIt is then crucial that epoll threads are signaled via wakeup when they\nqueue their own work. Otherwise, they risk waiting indefinitely for an\nevent leaving their work unhandled. What is worse, subsequent commands\nwon\u0026apos;t trigger a wakeup either as the thread has pending work.(CVE-2024-26606)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntomoyo: fix UAF write bug in tomoyo_write_control()\r\n\r\nSince tomoyo_write_control() updates head-\u0026gt;write_buf when write()\nof long lines is requested, we need to fetch head-\u0026gt;write_buf after\nhead-\u0026gt;io_sem is held.  Otherwise, concurrent write() requests can\ncause use-after-free-write and double-free problems.(CVE-2024-26622)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nllc: call sock_orphan() at release time\r\n\r\nsyzbot reported an interesting trace [1] caused by a stale sk-\u0026gt;sk_wq\npointer in a closed llc socket.\r\n\r\nIn commit ff7b11aa481f (\u0026quot;net: socket: set sock-\u0026gt;sk to NULL after\ncalling proto_ops::release()\u0026quot;) Eric Biggers hinted that some protocols\nare missing a sock_orphan(), we need to perform a full audit.\r\n\r\nIn net-next, I plan to clear sock-\u0026gt;sk from sock_orphan() and\namend Eric patch to add a warning.\r\n\r\n[1]\n BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline]\n BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline]\n BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline]\n BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468\nRead of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27\r\n\r\nCPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106\n  print_address_description mm/kasan/report.c:377 [inline]\n  print_report+0xc4/0x620 mm/kasan/report.c:488\n  kasan_report+0xda/0x110 mm/kasan/report.c:601\n  list_empty include/linux/list.h:373 [inline]\n  waitqueue_active include/linux/wait.h:127 [inline]\n  sock_def_write_space_wfree net/core/sock.c:3384 [inline]\n  sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468\n  skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080\n  skb_release_all net/core/skbuff.c:1092 [inline]\n  napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404\n  e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970\n  e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline]\n  e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801\n  __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576\n  napi_poll net/core/dev.c:6645 [inline]\n  net_rx_action+0x956/0xe90 net/core/dev.c:6778\n  __do_softirq+0x21a/0x8de kernel/softirq.c:553\n  run_ksoftirqd kernel/softirq.c:921 [inline]\n  run_ksoftirqd+0x31/0x60 kernel/softirq.c:913\n  smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164\n  kthread+0x2c6/0x3a0 kernel/kthread.c:388\n  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n  ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 5167:\n  kasan_save_stack+0x33/0x50 mm/kasan/common.c:47\n  kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n  unpoison_slab_object mm/kasan/common.c:314 [inline]\n  __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340\n  kasan_slab_alloc include/linux/kasan.h:201 [inline]\n  slab_post_alloc_hook mm/slub.c:3813 [inline]\n  slab_alloc_node mm/slub.c:3860 [inline]\n  kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879\n  alloc_inode_sb include/linux/fs.h:3019 [inline]\n  sock_alloc_inode+0x25/0x1c0 net/socket.c:308\n  alloc_inode+0x5d/0x220 fs/inode.c:260\n  new_inode_pseudo+0x16/0x80 fs/inode.c:1005\n  sock_alloc+0x40/0x270 net/socket.c:634\n  __sock_create+0xbc/0x800 net/socket.c:1535\n  sock_create net/socket.c:1622 [inline]\n  __sys_socket_create net/socket.c:1659 [inline]\n  __sys_socket+0x14c/0x260 net/socket.c:1706\n  __do_sys_socket net/socket.c:1720 [inline]\n  __se_sys_socket net/socket.c:1718 [inline]\n  __x64_sys_socket+0x72/0xb0 net/socket.c:1718\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nFreed by task 0:\n  kasan_save_stack+0x33/0x50 mm/kasan/common.c:47\n  kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n  kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640\n  poison_slab_object mm/kasan/common.c:241 [inline]\n  __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257\n  kasan_slab_free include/linux/kasan.h:184 [inline]\n  slab_free_hook mm/slub.c:2121 [inlin\n---truncated---(CVE-2024-26625)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2404.1.0.0245.oe1"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2404.1.0.0245.oe1.aarch64.rpm","bpftool-debuginfo-4.19.90-2404.1.0.0245.oe1.aarch64.rpm","kernel-debuginfo-4.19.90-2404.1.0.0245.oe1.aarch64.rpm","kernel-debugsource-4.19.90-2404.1.0.0245.oe1.aarch64.rpm","python2-perf-debuginfo-4.19.90-2404.1.0.0245.oe1.aarch64.rpm","kernel-tools-devel-4.19.90-2404.1.0.0245.oe1.aarch64.rpm","kernel-tools-4.19.90-2404.1.0.0245.oe1.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2404.1.0.0245.oe1.aarch64.rpm","python3-perf-4.19.90-2404.1.0.0245.oe1.aarch64.rpm","python3-perf-debuginfo-4.19.90-2404.1.0.0245.oe1.aarch64.rpm","kernel-source-4.19.90-2404.1.0.0245.oe1.aarch64.rpm","python2-perf-4.19.90-2404.1.0.0245.oe1.aarch64.rpm","perf-4.19.90-2404.1.0.0245.oe1.aarch64.rpm","perf-debuginfo-4.19.90-2404.1.0.0245.oe1.aarch64.rpm","kernel-4.19.90-2404.1.0.0245.oe1.aarch64.rpm","kernel-devel-4.19.90-2404.1.0.0245.oe1.aarch64.rpm"],"src":["kernel-4.19.90-2404.1.0.0245.oe1.src.rpm"],"x86_64":["perf-debuginfo-4.19.90-2404.1.0.0245.oe1.x86_64.rpm","perf-4.19.90-2404.1.0.0245.oe1.x86_64.rpm","kernel-source-4.19.90-2404.1.0.0245.oe1.x86_64.rpm","python2-perf-debuginfo-4.19.90-2404.1.0.0245.oe1.x86_64.rpm","bpftool-debuginfo-4.19.90-2404.1.0.0245.oe1.x86_64.rpm","kernel-devel-4.19.90-2404.1.0.0245.oe1.x86_64.rpm","kernel-debugsource-4.19.90-2404.1.0.0245.oe1.x86_64.rpm","kernel-tools-devel-4.19.90-2404.1.0.0245.oe1.x86_64.rpm","kernel-debuginfo-4.19.90-2404.1.0.0245.oe1.x86_64.rpm","bpftool-4.19.90-2404.1.0.0245.oe1.x86_64.rpm","python2-perf-4.19.90-2404.1.0.0245.oe1.x86_64.rpm","kernel-4.19.90-2404.1.0.0245.oe1.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2404.1.0.0245.oe1.x86_64.rpm","python3-perf-4.19.90-2404.1.0.0245.oe1.x86_64.rpm","kernel-tools-4.19.90-2404.1.0.0245.oe1.x86_64.rpm","python3-perf-debuginfo-4.19.90-2404.1.0.0245.oe1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1392"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2020-36777"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2020-36780"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2020-36784"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-46904"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-46924"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-46926"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-46928"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-46934"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-46935"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-46952"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-46989"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47086"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47112"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47113"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47114"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47122"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52443"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52469"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52476"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52502"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52509"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52599"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52600"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52601"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52602"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52603"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-23307"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-24855"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26597"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26600"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26606"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26622"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26625"}],"database_specific":{"severity":"High"}}