Page 45 of 2578 results (0.017 seconds)

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

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/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/54aaa3ed40972511e423b604324b881425b9ff1e https://git.kernel.org/stable/c/b9c94c8ba5a713817cffd74c4bacc05187469624 https://git.kernel.org/stable/c/e766e6a92410ca269161de059fff0843b •

CVSS: -EPSS: 0%CPEs: 7EXPL: 0

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: 7EXPL: 0

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/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/516dbc6d16637430808c39568cbb6b841d32b55b https://git.kernel.org/stable/c/77a77331cef0a219b8dd91361435eeef04cb741c https://git.kernel.org/stable/c/b5109b60ee4fcb2f2bb24f589575e10cc •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever. • https://git.kernel.org/stable/c/205c1d8026835746d8597e1aa70c370e014e83fa https://git.kernel.org/stable/c/fa4890bd8237e5a1e7428acd7328729db2703b23 https://git.kernel.org/stable/c/4e181761ffec67307157a7e8a78d58ee4130cf00 https://git.kernel.org/stable/c/2f3d8ff457982f4055fe8f7bf19d3821ba22c376 •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

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 •