There are 287 open security issues in forky.
287 important issues:
- CVE-2013-7445:
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated by JavaScript code that creates many CANVAS elements for rendering by Chrome or Firefox.
- CVE-2020-0347:
In iptables, there is a possible out of bounds write due to an incorrect bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-136658008
- CVE-2021-3847:
An unauthorized access to the execution of the setuid file with capabilities flaw in the Linux kernel OverlayFS subsystem was found in the way user copying a capable file from a nosuid mount into another mount. A local user could use this flaw to escalate their privileges on the system.
- CVE-2021-3864:
A flaw was found in the way the dumpable flag setting was handled when certain SUID binaries executed its descendants. The prerequisite is a SUID binary that sets real UID equal to effective UID, and real GID equal to effective GID. The descendant will then have a dumpable value set to 1. As a result, if the descendant process crashes and core_pattern is set to a relative value, its core dump is stored in the current directory with uid:gid permissions. An unprivileged local user with eligible root SUID binary could use this flaw to place core dumps into root-owned directories, potentially resulting in escalation of privileges.
- CVE-2023-3397:
A race condition occurred between the functions lmLogClose and txEnd in JFS, in the Linux Kernel, executed in different threads. This flaw allows a local attacker with normal user privileges to crash the system or leak internal kernel information.
- CVE-2023-4010:
A flaw was found in the USB Host Controller Driver framework in the Linux kernel. The usb_giveback_urb function has a logic loophole in its implementation. Due to the inappropriate judgment condition of the goto statement, the function cannot return under the input of a specific malformed descriptor file, so it falls into an endless loop, resulting in a denial of service.
- CVE-2023-6238:
A buffer overflow vulnerability was found in the NVM Express (NVMe) driver in the Linux kernel. Only privileged user could specify a small meta buffer and let the device perform larger Direct Memory Access (DMA) into the same buffer, overwriting unrelated kernel memory, causing random kernel crashes and memory corruption.
- CVE-2023-6240:
A Marvin vulnerability side-channel leakage was found in the RSA decryption operation in the Linux Kernel. This issue may allow a network attacker to decrypt ciphertexts or forge signatures, limiting the services that use that private key.
- CVE-2024-2193:
A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative executable code paths.
- CVE-2018-12928:
In the Linux kernel 4.15.0, a NULL pointer dereference was discovered in hfs_ext_read_extent in hfs.ko. This can occur during a mount of a crafted hfs filesystem.
- CVE-2019-15213:
An issue was discovered in the Linux kernel before 5.2.3. There is a use-after-free caused by a malicious USB device in the drivers/media/usb/dvb-usb/dvb-usb-init.c driver.
- CVE-2019-16089:
An issue was discovered in the Linux kernel through 5.2.13. nbd_genl_status in drivers/block/nbd.c does not check the nla_nest_start_noflag return value.
- CVE-2019-19449:
In the Linux kernel 5.0.21, mounting a crafted f2fs filesystem image can lead to slab-out-of-bounds read access in f2fs_build_segment_manager in fs/f2fs/segment.c, related to init_min_max_mtime in fs/f2fs/segment.c (because the second argument to get_seg_entry is not validated).
- CVE-2019-19814:
In the Linux kernel 5.0.21, mounting a crafted f2fs filesystem image can cause __remove_dirty_segment slab-out-of-bounds write access because an array is bounded by the number of dirty types (8) but the array index can exceed this.
- CVE-2019-20794:
An issue was discovered in the Linux kernel 4.18 through 5.6.11 when unprivileged user namespaces are allowed. A user can create their own PID namespace, and mount a FUSE filesystem. Upon interaction with this FUSE filesystem, if the userspace component is terminated via a kill of the PID namespace's pid 1, it will result in a hung task, and resources being permanently locked up until system reboot. This can result in resource exhaustion.
- CVE-2020-14304:
A memory disclosure flaw was found in the Linux kernel's ethernet drivers, in the way it read data from the EEPROM of the device. This flaw allows a local user to read uninitialized values from the kernel memory. The highest threat from this vulnerability is to confidentiality.
- CVE-2020-36694:
An issue was discovered in netfilter in the Linux kernel before 5.10. There can be a use-after-free in the packet processing context, because the per-CPU sequence count is mishandled during concurrent iptables rules replacement. This could be exploited with the CAP_NET_ADMIN capability in an unprivileged namespace. NOTE: cc00bca was reverted in 5.12.
- CVE-2023-31082:
An issue was discovered in drivers/tty/n_gsm.c in the Linux kernel 6.2. There is a sleeping function called from an invalid context in gsmld_write, which will block the kernel. Note: This has been disputed by 3rd parties as not a valid vulnerability.
- CVE-2023-37454:
An issue was discovered in the Linux kernel through 6.4.2. A crafted UDF filesystem image causes a use-after-free write operation in the udf_put_super and udf_close_lvid functions in fs/udf/super.c. NOTE: the suse.com reference has a different perspective about this.
- CVE-2024-21803:
Use After Free vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (bluetooth modules) allows Local Execution of Code. This vulnerability is associated with program files https://gitee.Com/anolis/cloud-kernel/blob/devel-5.10/net/bluetooth/af_bluetooth.C. This issue affects Linux kernel: from v2.6.12-rc2 before v6.8-rc1.
- CVE-2024-24864:
A race condition was found in the Linux kernel's media/dvb-core in dvbdmx_write() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
- CVE-2024-56709:
In the Linux kernel, the following vulnerability has been resolved: io_uring: check if iowq is killed before queuing task work can be executed after the task has gone through io_uring termination, whether it's the final task_work run or the fallback path. In this case, task work will find ->io_wq being already killed and null'ed, which is a problem if it then tries to forward the request to io_queue_iowq(). Make io_queue_iowq() fail requests in this case. Note that it also checks PF_KTHREAD, because the user can first close a DEFER_TASKRUN ring and shortly after kill the task, in which case ->iowq check would race.
- CVE-2026-64187:
In the Linux kernel, the following vulnerability has been resolved: xfs: fail recovery on a committed log item with no regions If the first op of a transaction is a bare transaction header (len == sizeof(struct xfs_trans_header)), xlog_recover_add_to_trans() adds an item but no region, leaving it on r_itemq with ri_cnt == 0 and ri_buf == NULL. The header can be split across op records, so later ops may still add regions; the item is only invalid if the transaction commits with none. The runtime commit path never emits such a transaction, so this only happens on a crafted log. It came from an AI-assisted code audit of the recovery parser. xlog_recover_reorder_trans() calls ITEM_TYPE() on the item, which reads *(unsigned short *)item->ri_buf[0].iov_base and faults on the NULL ri_buf. Reject it there, before the commit handlers that also read ri_buf[0]. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:xlog_recover_reorder_trans (fs/xfs/xfs_log_recover.c:1836) xlog_recover_commit_trans (fs/xfs/xfs_log_recover.c:2043) xlog_recover_process_data (fs/xfs/xfs_log_recover.c:2501) xlog_do_recovery_pass (fs/xfs/xfs_log_recover.c:3244) xlog_recover (fs/xfs/xfs_log_recover.c:3493) xfs_log_mount (fs/xfs/xfs_log.c:618) xfs_mountfs (fs/xfs/xfs_mount.c:1034) xfs_fs_fill_super (fs/xfs/xfs_super.c:1938) vfs_get_tree (fs/super.c:1695) path_mount (fs/namespace.c:4161) __x64_sys_mount (fs/namespace.c:4367)
- CVE-2026-64189:
In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: fix race between dump and ip_set_list resize The release path of ip_set_dump_do() and ip_set_dump_done() read inst->ip_set_list via ip_set_ref_netlink(), a plain rcu_dereference_raw() of the array pointer. These run from netlink_recvmsg() without the nfnl mutex and without an RCU read-side critical section. A concurrent ip_set_create() can grow the array: it publishes the new array, calls synchronize_net() and then kvfree()s the old one. Since the dump paths read the array outside any RCU reader, synchronize_net() does not wait for them and the old array can be freed while they still index into it, causing a use-after-free. The dumped set itself stays pinned via set->ref_netlink, so only the array load needs protecting. Take rcu_read_lock() around it, matching ip_set_get_byname() and __ip_set_put_byindex(). BUG: KASAN: slab-use-after-free in ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) Read of size 8 at addr ffff88800b5c4018 by task exploit/150 Call Trace: ... kasan_report (mm/kasan/report.c:595) ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1697) netlink_dump (net/netlink/af_netlink.c:2325) netlink_recvmsg (net/netlink/af_netlink.c:1976) sock_recvmsg (net/socket.c:1159) __sys_recvfrom (net/socket.c:2315) ... Oops: general protection fault, probably for non-canonical address ... KASAN NOPTI KASAN: maybe wild-memory-access in range [0x02d6...d0-0x02d6...d7] RIP: 0010:ip_set_dump_do (net/netfilter/ipset/ip_set_core.c:1698) Kernel panic - not syncing: Fatal exception
- CVE-2026-64192:
In the Linux kernel, the following vulnerability has been resolved: bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized When CONFIG_BPF_LSM=y is set, BPF inode storage maps (BPF_MAP_TYPE_INODE_STORAGE) are compiled into the kernel. However, if the BPF LSM is not explicitly enabled at boot time (e.g. omitted from the "lsm=" boot parameter), lsm_prepare() is never executed for the BPF LSM. Consequently, the BPF inode security blob offset (bpf_lsm_blob_sizes.lbs_inode) is never initialized and remains at its default compiled size of 8 bytes instead of being updated to a valid offset past the reserved struct rcu_head (typically 16 bytes or more). When a privileged user creates and updates a BPF_MAP_TYPE_INODE_STORAGE map, bpf_inode() evaluates inode->i_security + 8. This erroneously aliases the struct rcu_head.func callback pointer at the beginning of the inode->i_security blob. During subsequent map element cleanup or inode destruction, writing NULL to owner_storage clears the queued RCU callback pointer. When rcu_do_batch() later executes the queued callback, it attempts an instruction fetch at address 0x0, triggering an immediate kernel panic. Fix this by introducing a global bpf_lsm_initialized boolean flag marked with __ro_after_init. Set this flag to true inside bpf_lsm_init() when the LSM framework successfully registers the BPF LSM. Gate map allocation in inode_storage_map_alloc() on this flag, returning -EOPNOTSUPP if the BPF LSM is in turn uninitialized. This fail-fast approach prevents userspace from allocating inode storage maps when the supporting BPF LSM infrastructure is absent, avoiding zombie map states.
- CVE-2026-64205:
In the Linux kernel, the following vulnerability has been resolved: i2c: i801: fix hardware state machine corruption in error path A severe livelock and subsequent Hung Task panic were observed in the i2c-i801 driver during concurrent Fuzzing. The crash is caused by an unconditional hardware register cleanup in the error handling path of i801_access(). When i801_check_pre() fails (e.g., returning -EBUSY because the SMBus controller is actively used by BIOS/ACPI), the kernel does not actually acquire the hardware ownership. However, the code jumps to the 'out' label and executes: iowrite8(SMBHSTSTS_INUSE_STS | STATUS_FLAGS, SMBHSTSTS(priv)); This forcefully clears the INUSE_STS lock and resets the hardware status flags without owning the controller. Doing so interrupts ongoing BIOS/ACPI transactions and totally corrupts the SMBus hardware state machine. Consequently, all subsequent i801_access() calls fail at the pre-check stage, triggering an endless stream of "SMBus is busy, can't use it!" error logs. Over a slow serial console, this printk flood monopolizes the CPU (Console Livelock), starving other processes trying to acquire the mmap_lock down_read semaphore, ultimately triggering the hung task watchdog. Fix this by moving the 'out' label below the hardware register cleanup. If i801_check_pre() fails, we safely bypass the iowrite8() and only release the software locks (pm_runtime and mutex), strictly adhering to the rule of not releasing resources that were never acquired.
- CVE-2026-64206:
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: cancel pending_rx_work before taking conn->lock l2cap_conn_del() takes conn->lock and then calls cancel_work_sync() for pending_rx_work. process_pending_rx() takes the same mutex, so teardown can deadlock against the worker it is flushing. This issue was found by our static analysis tool and then manually reviewed against the current tree. The grounded PoC kept the l2cap_conn_ready() -> queue_work(..., &conn->pending_rx_work) submit path, the l2cap_conn_del() -> cancel_work_sync(&conn->pending_rx_work) teardown path, and the process_pending_rx() -> mutex_lock(&conn->lock) worker edge. Lockdep WARNING: possible circular locking dependency detected process_pending_rx+0x21/0x2a [vuln_msv] l2cap_conn_del.constprop.0+0x3f/0x4e [vuln_msv] *** DEADLOCK *** Cancel pending_rx_work before taking conn->lock, matching the existing lock-before-drain ordering used for the two delayed works in the same teardown path. The pending_rx queue is still purged after the work has been cancelled and conn->lock has been acquired.
- CVE-2026-64207:
In the Linux kernel, the following vulnerability has been resolved: net/sched: dualpi2: fix GSO backlog accounting When DualPI2 splits a GSO skb into N segments, it propagates N additional packets to its parent before returning NET_XMIT_SUCCESS. The parent then accounts for the original skb once more, leaving its qlen one larger than the number of packets actually queued. With QFQ as the parent, after all real packets are dequeued, QFQ still has a non-zero qlen while its in-service aggregate has no active classes. qfq_choose_next_agg() returns NULL and qfq_dequeue() passes the result to qfq_peek_skb(), causing a NULL pointer dereference. Follow the same pattern used by tbf_segment() and taprio: count only successfully queued segments, propagate the difference between the original skb and those segments, and return NET_XMIT_SUCCESS whenever at least one segment was queued.
- CVE-2026-64256:
- CVE-2026-64258:
- CVE-2026-64259:
- CVE-2026-64260:
- CVE-2026-64261:
- CVE-2026-64262:
- CVE-2026-64263:
- CVE-2026-64264:
- CVE-2026-64265:
- CVE-2026-64266:
- CVE-2026-64267:
- CVE-2026-64268:
- CVE-2026-64269:
- CVE-2026-64270:
- CVE-2026-64271:
- CVE-2026-64272:
- CVE-2026-64273:
- CVE-2026-64274:
- CVE-2026-64275:
- CVE-2026-64276:
- CVE-2026-64277:
- CVE-2026-64278:
- CVE-2026-64279:
- CVE-2026-64280:
- CVE-2026-64281:
- CVE-2026-64282:
- CVE-2026-64283:
- CVE-2026-64284:
- CVE-2026-64285:
- CVE-2026-64286:
- CVE-2026-64287:
- CVE-2026-64288:
- CVE-2026-64289:
- CVE-2026-64290:
- CVE-2026-64291:
- CVE-2026-64292:
- CVE-2026-64293:
- CVE-2026-64294:
- CVE-2026-64295:
- CVE-2026-64296:
- CVE-2026-64297:
- CVE-2026-64298:
- CVE-2026-64299:
- CVE-2026-64300:
- CVE-2026-64301:
- CVE-2026-64302:
- CVE-2026-64303:
- CVE-2026-64304:
- CVE-2026-64305:
- CVE-2026-64306:
- CVE-2026-64307:
- CVE-2026-64308:
- CVE-2026-64309:
- CVE-2026-64310:
- CVE-2026-64311:
- CVE-2026-64312:
- CVE-2026-64313:
- CVE-2026-64314:
- CVE-2026-64315:
- CVE-2026-64316:
- CVE-2026-64317:
- CVE-2026-64318:
- CVE-2026-64319:
- CVE-2026-64320:
- CVE-2026-64321:
- CVE-2026-64322:
- CVE-2026-64323:
- CVE-2026-64324:
- CVE-2026-64325:
- CVE-2026-64326:
- CVE-2026-64327:
- CVE-2026-64328:
- CVE-2026-64329:
- CVE-2026-64330:
- CVE-2026-64331:
- CVE-2026-64332:
- CVE-2026-64333:
- CVE-2026-64334:
- CVE-2026-64335:
- CVE-2026-64336:
- CVE-2026-64337:
- CVE-2026-64338:
- CVE-2026-64339:
- CVE-2026-64340:
- CVE-2026-64341:
- CVE-2026-64342:
- CVE-2026-64343:
- CVE-2026-64344:
- CVE-2026-64345:
- CVE-2026-64346:
- CVE-2026-64347:
- CVE-2026-64348:
- CVE-2026-64349:
- CVE-2026-64350:
- CVE-2026-64351:
- CVE-2026-64352:
- CVE-2026-64353:
- CVE-2026-64354:
- CVE-2026-64355:
- CVE-2026-64356:
- CVE-2026-64357:
- CVE-2026-64358:
- CVE-2026-64359:
- CVE-2026-64360:
- CVE-2026-64361:
- CVE-2026-64362:
- CVE-2026-64363:
- CVE-2026-64364:
- CVE-2026-64365:
- CVE-2026-64366:
- CVE-2026-64367:
- CVE-2026-64368:
- CVE-2026-64369:
- CVE-2026-64370:
- CVE-2026-64371:
- CVE-2026-64372:
- CVE-2026-64373:
- CVE-2026-64374:
- CVE-2026-64375:
- CVE-2026-64376:
- CVE-2026-64377:
- CVE-2026-64378:
- CVE-2026-64379:
- CVE-2026-64380:
- CVE-2026-64381:
- CVE-2026-64382:
- CVE-2026-64383:
- CVE-2026-64384:
- CVE-2026-64385:
- CVE-2026-64386:
- CVE-2026-64387:
- CVE-2026-64388:
- CVE-2026-64389:
- CVE-2026-64390:
- CVE-2026-64391:
- CVE-2026-64392:
- CVE-2026-64393:
- CVE-2026-64394:
- CVE-2026-64395:
- CVE-2026-64396:
- CVE-2026-64397:
- CVE-2026-64398:
- CVE-2026-64399:
- CVE-2026-64400:
- CVE-2026-64401:
- CVE-2026-64402:
- CVE-2026-64403:
- CVE-2026-64404:
- CVE-2026-64405:
- CVE-2026-64406:
- CVE-2026-64407:
- CVE-2026-64408:
- CVE-2026-64409:
- CVE-2026-64410:
- CVE-2026-64411:
- CVE-2026-64412:
- CVE-2026-64413:
- CVE-2026-64414:
- CVE-2026-64415:
- CVE-2026-64416:
- CVE-2026-64417:
- CVE-2026-64418:
- CVE-2026-64419:
- CVE-2026-64420:
- CVE-2026-64421:
- CVE-2026-64422:
- CVE-2026-64423:
- CVE-2026-64424:
- CVE-2026-64425:
- CVE-2026-64426:
- CVE-2026-64427:
- CVE-2026-64428:
- CVE-2026-64429:
- CVE-2026-64430:
- CVE-2026-64431:
- CVE-2026-64432:
- CVE-2026-64433:
- CVE-2026-64434:
- CVE-2026-64435:
- CVE-2026-64436:
- CVE-2026-64437:
- CVE-2026-64438:
- CVE-2026-64439:
- CVE-2026-64440:
- CVE-2026-64441:
- CVE-2026-64442:
- CVE-2026-64443:
- CVE-2026-64444:
- CVE-2026-64445:
- CVE-2026-64446:
- CVE-2026-64447:
- CVE-2026-64448:
- CVE-2026-64449:
- CVE-2026-64450:
- CVE-2026-64451:
- CVE-2026-64452:
- CVE-2026-64453:
- CVE-2026-64454:
- CVE-2026-64455:
- CVE-2026-64456:
- CVE-2026-64457:
- CVE-2026-64458:
- CVE-2026-64459:
- CVE-2026-64460:
- CVE-2026-64461:
- CVE-2026-64462:
- CVE-2026-64463:
- CVE-2026-64464:
- CVE-2026-64465:
- CVE-2026-64466:
- CVE-2026-64467:
- CVE-2026-64468:
- CVE-2026-64469:
- CVE-2026-64470:
- CVE-2026-64471:
- CVE-2026-64472:
- CVE-2026-64473:
- CVE-2026-64474:
- CVE-2026-64475:
- CVE-2026-64476:
- CVE-2026-64477:
- CVE-2026-64478:
- CVE-2026-64479:
- CVE-2026-64480:
- CVE-2026-64481:
- CVE-2026-64482:
- CVE-2026-64483:
- CVE-2026-64484:
- CVE-2026-64485:
- CVE-2026-64486:
- CVE-2026-64487:
- CVE-2026-64488:
- CVE-2026-64489:
- CVE-2026-64490:
- CVE-2026-64491:
- CVE-2026-64492:
- CVE-2026-64493:
- CVE-2026-64494:
- CVE-2026-64495:
- CVE-2026-64496:
- CVE-2026-64497:
- CVE-2026-64498:
- CVE-2026-64499:
- CVE-2026-64500:
- CVE-2026-64501:
- CVE-2026-64502:
- CVE-2026-64503:
- CVE-2026-64504:
- CVE-2026-64505:
- CVE-2026-64506:
- CVE-2026-64507:
- CVE-2026-64508:
- CVE-2026-64509:
- CVE-2026-64510:
- CVE-2026-64511:
- CVE-2026-64512:
- CVE-2026-64513:
- CVE-2026-64514:
- CVE-2026-64600:
In the Linux kernel, the following vulnerability has been resolved: xfs: resample the data fork mapping after cycling ILOCK xfs_reflink_fill_{cow_hole,delalloc} are both presented with an inode, a data fork mapping, and a cow fork mapping. Unfortunately, these two helpers cycle the ILOCK to grab a transaction, which means that the mappings are stale as soon as we reacquire the ILOCK. Currently we refresh the cow fork mapping by re-calling xfs_find_trim_cow_extent, but we don't refresh the data fork mapping beforehand, which means that the xfs_bmap_trim_cow in that function queries the refcount btree about the wrong physical blocks and returns an inaccurate value in *shared. If *shared is now false, the directio write proceeds with a stale data fork mapping. Fix this by querying the data fork mapping if the sequence counter changes across the ILOCK cycle.
