Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/433c84c8495008922534c5cafdae6ff970fb3241 - https://git.kernel.org/stable/c/57c4f4db0a194416da237fd09dad9527e00cb587 - https://git.kernel.org/stable/c/252f147b1826cbb30ae0304cf86b66d3bb12b743 - https://git.kernel.org/stable/c/41cf6f26abe4f491b694c54bd1aa2530369b7510 - https://git.kernel.org/stable/c/889304120ecb2ca30674d89cd4ef15990b6a571c - https://git.kernel.org/stable/c/688872c4ea4a528cd6a057d545c83506b533ee1f - https://git.kernel.org/stable
f15990b6a571c - https://git.kernel.org/stable/c/688872c4ea4a528cd6a057d545c83506b533ee1f - https://git.kernel.org/stable/c/11c0d49093b82f6c547fd419c41a982d26bdf5ef - https://git.kernel.org/stable/c/9cf14f5a2746c19455ce9cb44341b5527b5e19c3
CVE ID: CVE-2024-50181 State: REJECTED Published: 2024-11-08T05:38:22.620Z Last Updated: 2025-03-03T08:16:01.884Z Description: No description available.
CVE ID: CVE-2024-50182 State: PUBLISHED Published: 2024-11-08T05:38:23.528Z Last Updated: 2025-11-03T22:26:32.866Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_dire
semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly "work" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure.
T_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201
ped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/ Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d0ae6ffa1aeb297aef89f49cfb894a83c329ebad - https://git.kernel.org/stable/c/5ea0b7af38754d2b45ead9257bca47e84662e926 - https://git.kernel.org/stable/c/7caf966390e6e4ebf42775df54e7ee1f280ce677 - https://git.kernel.org/stable/c/757786abe4547eb3d9d0e8350a63bdb0f9824af2 - https://gi
90e6e4ebf42775df54e7ee1f280ce677 - https://git.kernel.org/stable/c/757786abe4547eb3d9d0e8350a63bdb0f9824af2 - https://git.kernel.org/stable/c/532b53cebe58f34ce1c0f34d866f5c0e335c53c6
CVE ID: CVE-2024-50183 State: PUBLISHED Published: 2024-11-08T05:38:24.400Z Last Updated: 2025-11-03T22:26:34.323Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/085
ional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/0857b1c573c0b095aa778bb26d8b3378172471b6 - https://git.kernel.org/stable/c/0ef6e016eb53fad6dc44c3253945efb43a3486b9 - https://git.kernel.org/stable/c/bbc525409bfe8e5bff12f5d18d550ab3e52cdbef - https://git.kernel.org/stable/c/0a3c84f71680684c1d41abb92db05f95c09111e8
CVE ID: CVE-2024-50184 State: PUBLISHED Published: 2024-11-08T05:38:25.258Z Last Updated: 2025-11-03T22:26:35.840Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/59ac565c6277d4be6661e81ea6a7f3ca2c5e4e36 - http
: - CVE Program Container: References: - https://git.kernel.org/stable/c/59ac565c6277d4be6661e81ea6a7f3ca2c5e4e36 - https://git.kernel.org/stable/c/4ce662fe4be6fbc2595d9ef4888b2b6e778c99ed - https://git.kernel.org/stable/c/9a2bc9b6f929a2ce1ebe4d1a796ddab37568c5b4 - https://git.kernel.org/stable/c/6a5ca0ab94e13a1474bf7ad8437a975c2193618f - https://git.kernel.org/stable/c/b01793cc63dd39c8f12b9a3d8dc115fbebb19e2a - https://git.kernel.org/stable/c/ce7a3a62cc533c922072f328fd2ea2fd7cb893d4 - https://git.kernel.org/stable/c/e25fbcd97cf52c3c9824d44b5c56c19673c3dd50
CVE ID: CVE-2024-50185 State: PUBLISHED Published: 2024-11-08T05:38:26.359Z Last Updated: 2025-11-03T22:26:37.356Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/fde99e972b8f8
yst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/fde99e972b8f88cebe619241d7aa43d288ef666a - https://git.kernel.org/stable/c/12c1676d598e3b8dd92a033b623b792cc2ea1ec5 - https://git.kernel.org/stable/c/35668f8ec84f6c944676e48ecc6bbc5fc8e6fe25 - https://git.kernel.org/stable/c/b8be15d1ae7ea4eedd547c3b3141f592fbddcd30 - https://git.kernel.org/stable/c/8bfd391bde685df7289b928ce8876a3583be4bfb - https://git.kernel.org/stable/c/e32d262c89e2b22cb0640223f953b548617ed8a6
CVE ID: CVE-2024-50186 State: PUBLISHED Published: 2024-11-08T05:38:27.272Z Last Updated: 2025-11-03T22:26:38.814Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket creation fails"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PA
aths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program
if the pointer is not NULL, it is definitely dangling. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/daf462ff3cde6ecf22b98d9ae770232c10d28de2 - https://git.kernel.org/stable/c/b7d22a79ff4e962b8af5ffe623abd1d6c179eb9f - https://git.kernel.org/stable/c/563e6892e21d6ecabdf62103fc4e7b326d212334 - https://git.kernel.org/stable/c/8e1b72fd74bf9da3b099d09857f4e7f114f38e12 - https://git.kernel.org/stable/c/631083143315d1b192bd7d915b967b37819e88ea
CVE ID: CVE-2024-50187 State: PUBLISHED Published: 2024-11-08T05:38:28.194Z Last Updated: 2025-11-03T22:26:40.257Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_
rmance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/75452da51e2403e14be007df80d133e1443fc967 - https://git.kernel.org/stable/c/937943c042503dc6087438bf3557f9057a588ba0 - https://git.kernel.org/stab
0d133e1443fc967 - https://git.kernel.org/stable/c/937943c042503dc6087438bf3557f9057a588ba0 - https://git.kernel.org/stable/c/c9adba739d5f7cdc47a7754df4a17b47b1ecf513 - https://git.kernel.org/stable/c/0b2ad4f6f2bec74a5287d96cb2325a5e11706f22
CVE ID: CVE-2024-50188 State: PUBLISHED Published: 2024-11-08T05:38:29.127Z Last Updated: 2025-11-03T22:26:41.710Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed. Additional Analyst N
rom supported at the end of the function the incorrect line isn't needed at all and can be removed. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/21b5af7f0c99b3bf1fd02016e6708b613acbcaf4 - https://git.kernel.org/stable/c/ad0d76b8ee5db063791cc2e7a30ffc9852ac37c4 - https://git.kernel.org/stable/c/c1944b4253649fc6f2fb53e7d6302eb414d2182c - https://git.kernel.org/stable/c/9ca634676ff66e1d616259e136f96f96b2a1759a - https://git.kernel.org/stable/c/e3f2de32dae35bc7d173377dc97b5bc9fcd9fc84 - https://git.kernel.org/stable/c/a842e443ca8184f2dc82ab307b43a8b38defd6a5
CVE ID: CVE-2024-50189 State: PUBLISHED Published: 2024-11-08T05:43:45.524Z Last Updated: 2025-11-03T22:26:43.186Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/8c6ad37e5882073cab84901a31da9cb22f316276 - http
: - CVE Program Container: References: - https://git.kernel.org/stable/c/8c6ad37e5882073cab84901a31da9cb22f316276 - https://git.kernel.org/stable/c/4cd9c5a0fcadc39a05c978a01e15e0d1edc4be93 - https://git.kernel.org/stable/c/1c3b4c90479aa0375ec98fe1a802993ff96a5f47 - https://git.kernel.org/stable/c/9dfee956f53eea96d93ef1e13ab4ce020f4c58b3 - https://git.kernel.org/stable/c/c56f9ecb7fb6a3a90079c19eb4c8daf3bbf514b3
CVE ID: CVE-2024-50190 State: PUBLISHED Published: 2024-11-08T05:43:46.911Z Last Updated: 2025-10-01T20:27:08.563Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [<ffffffff8761044d>] kmemdup_noprof+0x1d/0x50 [<ffffffffc0a0a480>] ice_init_ddp_config+0x100/0x220 [ice] [<ffffff
ch PF: [<ffffffff8761044d>] kmemdup_noprof+0x1d/0x50 [<ffffffffc0a0a480>] ice_init_ddp_config+0x100/0x220 [ice] [<ffffffffc0a0da7f>] ice_init_dev+0x6f/0x200 [ice] [<ffffffffc0a0dc49>] ice_init+0x29/0x560 [ice] [<ffffffffc0a10c1d>] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/43544b4e30732c3d88f423252281915d5bc739b6 - https://git.kernel.org/stable/c/c188afdc36113760873ec78cbc036f6b05f77621
CVE ID: CVE-2024-50191 State: PUBLISHED Published: 2024-11-08T05:43:47.840Z Last Updated: 2025-11-03T22:26:44.672Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warning
good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/fbb177bc1d6487cd3e9b50ae0be2781b7297980d - https://git.kernel.org/stable/c/4061e07f040a091f694f461b86a26cf95ae66439 - https://git.kernel.org/stable/c/58c0648e4c773f5b54f0cb63bc8c7c6bf5271
table/c/4061e07f040a091f694f461b86a26cf95ae66439 - https://git.kernel.org/stable/c/58c0648e4c773f5b54f0cb63bc8c7c6bf52719a9 - https://git.kernel.org/stable/c/ee77c388469116565e009eaa704a60bc78489e09 - https://git.kernel.org/stable/c/d3476f3dad4ad68ae5f6b008ea6591d1520da5d8
CVE ID: CVE-2024-50192 State: PUBLISHED Published: 2024-11-08T05:54:07.535Z Last Updated: 2025-11-03T22:26:46.124Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1
r the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/b7d7b7fc876f836f40bf48a87e07ea18756ba196 - https://git.kernel.org/stable/c/755b9532c885b8761fb135fedcd705e21e61cccb - https://git.kernel.org/stable/c/64b12b061c5488e2d69e67c4eaae5da64fd30bfe - https://git.kernel.org/stable/c/01282ab5182f85e42234df2ff42f0ce790f465ff - https://git.kernel.org/stable/c/d960505a869e66184fff97fb334980a5b797c7c6 - https://git.kernel.org/stable/c/1442ee0011983f0c5c4b92380e6853afb513841a
CVE ID: CVE-2024-50193 State: PUBLISHED Published: 2024-11-08T05:54:08.464Z Last Updated: 2025-11-03T22:26:47.607Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.k
RESTORE_ALL_NMI. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/6f44a5fc15b5cece0785bc07453db77d99b0a6de - https://git.kernel.org/stable/c/b6400eb0b347821efc57760221f8fb6d63b9548a - https://git.kernel.org/stable/c/43778de19d2ef129636815274644b9c16e78c66b - https://git.kernel.org/stable/c/227358e89703c344008119be7e8ffa3fdb5b92de - https://git.kernel.org/stable/c/64adf22c4bc73ede920baca5defefb70f190cdbc - https://git.kernel.org/stable/c/48a2440d0f20c826b884e04377ccc1e4696c84e9
CVE ID: CVE-2024-50194 State: PUBLISHED Published: 2024-11-08T05:54:09.327Z Last Updated: 2025-11-03T22:26:49.079Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an i
reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch
memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include
e time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include <stdio.h> | #include <stdbool.h> | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | " adrp %x0, adrp_self\n" | " add %x0, %x0, :lo12:adrp_self\n" | : "=r" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf("adrp_self => %p\n" | "adrp_self() => %p\n" | "%s\n", | adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 <adrp_self>: | 4007e0: 9000
); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 <adrp_self>: | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-s
drp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/b6a638cb600e13f94b5464724eaa6ab7f3349ca2 - https://git.kernel.org/stable/c/e6ab336213918575124d6db43dc5d3554526242e - https://git.kernel.org/stable/c/cf9ddf9ed94c15564a05bbf6e9f18dffa0c7df80
le/c/e6ab336213918575124d6db43dc5d3554526242e - https://git.kernel.org/stable/c/cf9ddf9ed94c15564a05bbf6e9f18dffa0c7df80 - https://git.kernel.org/stable/c/cf60d19d40184e43d9a624e55a0da73be09e938d - https://git.kernel.org/stable/c/14841bb7a531b96e2dde37423a3b33e75147c60d - https://git.kernel.org/stable/c/8165bf83b8a64be801d59cd2532b0d1ffed74d00 - https://git.kernel.org/stable/c/3d2530c65be04e93720e30f191a7cf1a3aa8b51c - https://git.kernel.org/stable/c/13f8f1e05f1dc36dbba6cba0ae03354c0dafcde7