CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-47749 – RDMA/cxgb4: Added NULL check for lookup_atid
https://notcve.org/view.php?id=CVE-2024-47749
In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/cfdda9d764362ab77b11a410bb928400e6520d57 https://git.kernel.org/stable/c/b12e25d91c7f97958341538c7dc63ee49d01548f https://git.kernel.org/stable/c/4e1fe68d695af367506ea3c794c5969630f21697 https://git.kernel.org/stable/c/dd598ac57dcae796cb58551074660c39b43fb155 https://git.kernel.org/stable/c/b11318dc8a1ec565300bb1a9073095af817cc508 https://git.kernel.org/stable/c/39cb9f39913566ec5865581135f3e8123ad1aee1 https://git.kernel.org/stable/c/0d50ae281a1712b9b2ca72830a96b8f11882358d https://git.kernel.org/stable/c/54aaa3ed40972511e423b604324b88142 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47748 – vhost_vdpa: assign irq bypass producer token correctly
https://notcve.org/view.php?id=CVE-2024-47748
In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set. • https://git.kernel.org/stable/c/2cf1ba9a4d15cb78b96ea97f727b93382c3f9a60 https://git.kernel.org/stable/c/0c170b1e918b9afac25e2bbd01eaa2bfc0ece8c0 https://git.kernel.org/stable/c/927a2580208e0f9b0b47b08f1c802b7233a7ba3c https://git.kernel.org/stable/c/ec5f1b54ceb23475049ada6e7a43452cf4df88d1 https://git.kernel.org/stable/c/ca64edd7ae93402af2596a952e0d94d545e2b9c0 https://git.kernel.org/stable/c/fae9b1776f53aab93ab345bdbf653b991aed717d https://git.kernel.org/stable/c/7cf2fb51175cafe01df8c43fa15a06194a59c6e2 https://git.kernel.org/stable/c/02e9e9366fefe461719da5d173385b668 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-47747 – net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition
https://notcve.org/view.php?id=CVE-2024-47747
In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove. • https://git.kernel.org/stable/c/6fd9c53f71862a4797b7ed8a5de80e2c64829f56 https://git.kernel.org/stable/c/25d559ed2beec9b34045886100dac46d1ad92eba https://git.kernel.org/stable/c/b5a84b6c772564c8359a9a0fbaeb2a2944aa1ee9 https://git.kernel.org/stable/c/338a0582b28e69460df03af50e938b86b4206353 https://git.kernel.org/stable/c/822c7bb1f6f8b0331e8d1927151faf8db3b33afd https://git.kernel.org/stable/c/1c57d61a43293252ad732007c7070fdb112545fd https://git.kernel.org/stable/c/d2abc379071881798d20e2ac1d332ad855ae22f3 https://git.kernel.org/stable/c/516dbc6d16637430808c39568cbb6b841 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-47745 – mm: call the security_mmap_file() LSM hook in remap_file_pages()
https://notcve.org/view.php?id=CVE-2024-47745
In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks] • https://git.kernel.org/stable/c/49d3a4ad57c57227c3b0fd6cd4188b2a5ebd6178 https://git.kernel.org/stable/c/3393fddbfa947c8e1fdcc4509226905ffffd8b89 https://git.kernel.org/stable/c/ce14f38d6ee9e88e37ec28427b4b93a7c33c70d3 https://git.kernel.org/stable/c/ea7e2d5e49c05e5db1922387b09ca74aa40f46e2 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-47743 – KEYS: prevent NULL pointer dereference in find_asymmetric_key()
https://notcve.org/view.php?id=CVE-2024-47743
In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. • https://git.kernel.org/stable/c/7d30198ee24f2ddcc4fefcd38a9b76bd8ab31360 https://git.kernel.org/stable/c/3322fa8f2aa40b0b3651034cd541647a600cc6c0 https://git.kernel.org/stable/c/a3765b497a4f5224cb2f7a6a2d3357d3066214ee https://git.kernel.org/stable/c/13b5b401ead95b5d8266f64904086c55b6024900 https://git.kernel.org/stable/c/0d3b0706ada15c333e6f9faf19590ff715e45d1e https://git.kernel.org/stable/c/70fd1966c93bf3bfe3fe6d753eb3d83a76597eef •