Filtered by vendor Linux Subscriptions
Filtered by product Linux Subscriptions
Total 520 CVE
CVE Vendors Products Updated CVSS v3.1
CVE-2026-99023 1 Linux 2 Linux, Linux Kernel 2026-10-29 2.3 Low
In the Linux kernel, the following vulnerability has been resolved: power: sequencing: pcie-m2: Fix leaking array from of_regulator_bulk_get_all() of_regulator_bulk_get_all() allocates the consumers array and hands it to the caller, who is expected to free it at an appropriate time. pwrseq-pcie-m2.c never did, leading to a memory leak. Add an explicit kfree() for the consumers array.
CVE-2026-99026 1 Linux 2 Linux, Linux Kernel 2026-10-29 2.5 Low
In the Linux kernel, the following vulnerability has been resolved: net: team: free skb when broadcast has no txable port bc_transmit() sends the original skb through the last txable port. When no port is txable, it returns false without consuming the skb, but team_xmit() still returns NETDEV_TX_OK. AF_PACKET sends then retain the skb and its socket write-memory charge. A TX-enabled, link-down port keeps the broadcast transmit op installed. Carrier can stay up through a second link-up, TX-disabled port or be forced on by userspace. Free the original skb on the no-port path while leaving the existing drop accounting intact. Discovered by Sashiko during review of previous commit.
CVE-2026-99030 1 Linux 2 Linux, Linux Kernel 2026-10-29 7.5 High
In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't leave stale bytes in skb_copy_and_csum_bits() When skb_copy_and_csum_bits() reaches unreadable frags it returns 0 after copying only the linear part, and the rest of the caller's buffer is left as it was. The callers copy into a buffer that is about to go out on the wire: an ICMP error quoting the offending packet, or a driver's TX bounce buffer in skb_copy_and_csum_dev(). Neither buffer is zeroed beforehand, so whatever was in memory there gets sent. Zero the part of the buffer we didn't fill. The checksum usually won't match the data any more, so the receiver will usually drop the packet, but either way it no longer carries anything it shouldn't. Only zero for a positive @len, a negative one from a broken caller must not turn into a huge memset().
CVE-2026-98957 1 Linux 2 Linux, Linux Kernel 2026-10-29 4.4 Medium
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: disable rx napi when removing device Unloading the mt7915e module with a MT7916 triggers multiples WARN in __netif_napi_del_locked() and in page_pool_disable_direct_recycling() because the driver does not disable the napi before destroying it. This is troublesome since on MT7916 it is required to unload the module and reinsert it with a different enable_6ghz parameter to change the frequency. The system generally becomes unstable after reinserting the module. Fix it by disabling rx napi inside mt7915e itself, even through napi rx is enabled in the mt76 generic code. Disabling it in the mt76 generic code was previously attempted and reverted because napi was disabled too late and rx handlers could access freed structures. Note that the tx side is enabled and disabled by the mt76 generic code. It is disabled in mt7915_stop_hardware() since, unlike mt7915_unregister_device(), is it also called in the probe path if an error happens after rx napi is enabled.
CVE-2026-98958 1 Linux 2 Linux, Linux Kernel 2026-10-29 6.5 Medium
In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: account non-AQL frames per peer rather than per link The driver increments wcid->non_aql_packets when a frame goes to the hardware queue. The completion path decrements the counter again. For an MLO peer, the hardware reports the completion on the link that it used for the transmission. This link can differ from the link that the driver queued the frame on. In that case, the increment and the decrement go to different link wcids, and the count drifts upwards until it blocks the station. Keep the count on the wcid of the primary link, like the other peer-wide state.
CVE-2026-98960 1 Linux 2 Linux, Linux Kernel 2026-10-29 3.3 Low
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't stash io_uring encoded data across -EAGAIN Returning -EAGAIN while leaving btrfs_uring_encoded_data in the cmd PDU leaks if the request is cancelled or the ring exits before reissue. io_uring does not free driver PDU allocations on cleanup. Write: io_queue_sqe() always issues with IO_URING_F_NONBLOCK first, so return -EAGAIN before allocating and free data on every exit. Read: free on nowait -EAGAIN too; only -EIOCBQUEUED keeps the allocation for btrfs_uring_read_finished().
CVE-2026-98923 1 Linux 2 Linux, Linux Kernel 2026-10-29 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: arm64: io: Reject non-user protection in ioremap_prot() Mapping a stack-top page via /dev/mem with PROT_NONE and then reading that process's /proc/<pid>/cmdline triggers a spurious WARN in ioremap_prot() through generic_access_phys(): WARNING: ./arch/arm64/include/asm/io.h:275 at generic_access_phys Call trace: generic_access_phys+0x1c8/0x228 (P) __access_remote_vm+0x2b4/0x398 access_remote_vm+0x14/0x30 get_mm_cmdline+0xf8/0x2a0 proc_pid_cmdline_read+0x68/0x120 generic_access_phys() passes the protection derived from the user PTE to ioremap_prot(). On arm64, a PROT_NONE mapping is represented by a present-invalid PTE, so pte_present() still returns true and the protection reaches ioremap_prot(). A PROT_NONE mapping does not have PTE_USER, causing the existing WARN_ON_ONCE() in ioremap_prot() to fire even though this is a valid user mapping. Execute-only mappings have the same issue and must not be readable through this path either. ioremap_prot() should therefore reject protection values without PTE_USER without warning. This makes the access fail cleanly for PROT_NONE and execute-only mappings while retaining the existing user-protection contract.
CVE-2026-98924 1 Linux 2 Linux, Linux Kernel 2026-10-29 4.4 Medium
In the Linux kernel, the following vulnerability has been resolved: fs: avoid repeated scans in evict_inodes() We observed hung tasks when users attempted to unmount a filesystem after its disk had been removed while still in use. During device removal, fs_bdev_mark_dead() calls evict_inodes() while holding s_umount. Each time evict_inodes() drops s_inode_list_lock to reschedule, it restarts the walk from the head of s_inodes. With many referenced inodes at the head of the list, these restarts repeatedly scan the same inodes without reclaiming them. This can keep s_umount held for a long time, blocking concurrent umount attempts and triggering hung-task reports. Keep the current inode, already marked I_FREEING, out of the disposal batch until s_inode_list_lock is reacquired. Resume the walk from this inode and dispose of it in a later batch or at the end of the walk. The zero-refcount and state checks under i_lock allow this walker to claim the inode by setting I_FREEING and removing it from the LRU. Other reclaimers skip the inode, leaving this walker responsible for eviction. Only evict() removes it from s_inodes, so keeping it out of the disposal batch ensures that it remains on the list while the lock is dropped. After reacquiring the lock, reading its current next pointer accounts for concurrent removal of following inodes. The existing inode lifetime rules prohibit acquiring a reference to an inode marked I_FREEING or I_WILL_FREE. __iget() requires its caller to hold i_lock and establish that taking a reference is valid. Inode lookup and igrab() check these flags under i_lock when acquiring a reference from zero. ihold() requires an existing reference, which would keep i_count nonzero and prevent this walker from claiming the inode. These rules already allow iput_final() and the inode shrinker to release i_lock after setting I_FREEING and before eviction completes. A temporary __iget() reference would also keep the inode on the list, but its release must preserve last-reference handling. Another user can acquire a reference, update lazy timestamps and drop its reference while the pin is held. If the pin becomes the last reference, dropping it with atomic_dec_and_test() and evicting directly bypasses iput()'s lazytime handling and can lose those timestamp updates. Releasing the pin with iput() preserves that handling, but does not guarantee eviction. fs_bdev_mark_dead() runs with SB_ACTIVE set, so iput() may retain the inode in cache, whereas evict_inodes() must evict eligible zero-reference inodes. The inode may also have been freed when iput() returns, so the walker cannot then use it to force eviction. Using I_FREEING preserves the existing eviction behavior without introducing an additional last-reference transition. The xfstests auto group passed on ext4 and XFS with known unrelated failures excluded. No new issues were observed, and the previously reproducible hung task no longer occurs with this patch.
CVE-2026-98925 1 Linux 2 Linux, Linux Kernel 2026-10-29 4.4 Medium
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix self-redirect copied_seq double-counting When a BPF stream_verdict program redirects an skb back to the same socket (self-redirect with BPF_F_INGRESS), sk_psock_verdict_apply() calls tcp_eat_skb() which advances tcp_sk->copied_seq. However, the skb is then delivered to the socket's psock ingress queue and later read by tcp_bpf_recvmsg_parser(), which also advances copied_seq via the copied_from_self accounting path. This double-counting causes copied_seq to advance by 2x the actual data length, triggering: TCP recvmsg seq # bug 2: copied BF2E806, seq BF2E7FD, \ rcvnxt BF2E806, fl 0 WARNING: net/ipv4/tcp.c:2745 at tcp_recvmsg_locked+0x72b/0x2640 Call Trace: tcp_recvmsg+0x10a/0x500 sock_recvmsg+0x168/0x1d0 __sys_recvfrom+0x19a/0x2a0 __x64_sys_recvfrom+0xe4/0x1f0 do_syscall_64+0xf7/0x530 entry_SYSCALL_64_after_hwframe+0x77/0x7f cleanup rbuf bug: copied BF2E806 seq BF2E806 rcvnxt BF2E806 WARNING: net/ipv4/tcp.c:1609 at tcp_cleanup_rbuf+0xf2/0x1c0 Call Trace: tcp_recvmsg_locked+0x8d1/0x2640 tcp_recvmsg+0x10a/0x500 sock_recvmsg+0x168/0x1d0 __sys_recvfrom+0x19a/0x2a0 __x64_sys_recvfrom+0xe4/0x1f0 do_syscall_64+0xf7/0x530 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fix this by converting self-redirect verdict to __SK_PASS at the beginning of sk_psock_verdict_apply(). This bypasses the __SK_REDIRECT case entirely (which calls sk_psock_eat_skb), letting the __SK_PASS path queue the skb to the psock ingress queue. The data is then read via tcp_bpf_recvmsg_parser(), which advances copied_seq exactly once through copied_from_self. Cross-socket redirects continue through __SK_REDIRECT with sk_psock_eat_skb() unchanged.
CVE-2026-99205 1 Linux 2 Linux, Linux Kernel 2026-10-28 4.7 Medium
In the Linux kernel, the following vulnerability has been resolved: sched/core: Call wakeup_preempt() for queued tasks during class change Paul reported recent RCU changes exposed a lost resched where CPU idles with a rcutorture thread waiting while being completely runnable. Dumping the rq state at the time of idling with runnable tasks showed the following: rq->next_class = &fair_sched_class rq->nr_running = 1 rq->cfs.h_nr_queued = 0 rq->rt.rt_nr_running = 1 Although the waiting task was an RT task, "rq->next_class" did not point to rt_sched_class and was stuck at the lower priority fair_sched_class. Inspecting sched_change_end() revealed the following race with __sched_setscheduler() for queued, but non-running tasks: CPU0 CPU1 ==== ==== __schedule() /* * rq->donor is a fair task that blocks. * rq->next_class = &fair_sched_class */ rq_lock(rq0) pick_next_task() /* nr_running = 0 */ pick_task_fair() sched_balance_newidle() raw_spin_rq_unlock(rq0) rq_lock(rq0) activate_task(rq0, p) /* p is a fair task */ rq0->nr_running++; rq0->cfs.h_nr_queued++; wakeup_preempt(rq, p) rq->next_class = &fair_sched_class resched_curr() rq_unlock(rq0) __sched_setscheduler(p) /* p is moved to SCHED_RR */ task_rq_lock(p) sched_change_begin() rq0->cfs.h_nr_queued--; rq0->rt.rt_nr_running++; sched_change_end() /* * p->on_rq = 1 (ctx->queued) * but p is not rq->donor * (!ctx->running) hence * resched_curr() is and * rq->next_class upgrade is * skipped. */ task_rq_unlock() raw_spin_rq_lock(rq0) /* * rq->nr_running = 1 * rq->cfs.h_nr_queued = 0 * rq->rt.rt_nr_running = 1 * rq->next_class = &fair_sched_class */ if (rq->cfs.h_nr_queued && ...) /* Above is false */ if (rq_modified_above(this_rq, &fair_sched_class)) /* Also false since rq->next_class is still fair */ /* * sched_balance_newidle() is considered to * have failed to pull any fair tasks and no * other wakeups were detected. */ return NULL; /* pick_task_fair() */ pick_task_idle() return rq->idle; next = rq->idle; /* Preemption indicators are lost */ clear_tsk_need_resched(prev); clear_preempt_need_resched(); rq->curr = rq->idle; !!! rq->idle switches in with rq->running == 1 but !need_resched() !!! In simple words, enqueue, followed by a class change of the newly queued task goes unnoticed in rq->next_class indicator and sched_balance_newidle() sees no fair task, nor any higher priority task enqueued. The above sequence will lead to CPU idling with a runnable task on the CPU. Call wakeup_preempt() for ctx->queued cases in sched_change_end() to re-evaluate rq->next_class after class change (ENQUEUE_CLASS) and set the NEED_RESCHED indicator accordingly. Newidle balance will correctly see an enqueue of a higher priority t ---truncated---
CVE-2026-99193 1 Linux 2 Linux, Linux Kernel 2026-10-28 4.4 Medium
In the Linux kernel, the following vulnerability has been resolved: net: ti: icssm-prueth: Move setting of netops to fix crash icssm_prueth_netdev_init() calls of_phy_get_and_connect() before ndev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash").
CVE-2026-99209 1 Linux 2 Linux, Linux Kernel 2026-10-28 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: drm/xe: skip eviction of a BO with no resource xe_evict_flags() switches on tbo->resource->mem_type to choose an eviction placement. An xe BO can reach eviction with no ttm.resource, e.g. an imported dma-buf BO whose resource was freed during teardown while its attachment is still live: the exporter then invalidates it via xe_dma_buf_move_notify() -> xe_bo_evict(), and the switch dereferences a NULL resource and faults. A BO with no resource has nothing placed or mapped, so there is nothing to evict. Return an empty placement (num_placement = 0), mirroring the handling already used for non-xe scatter-gather BOs just above; ttm_bo_validate() then takes the pipeline-gutting path and returns 0. Without the fix the xe_dma_buf@xe_test_dmabuf_move_notify_no_resource dynamic live selftest will fail with below stack. BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:xe_evict_flags+0xf4/0x140 [xe] Call Trace: <TASK> xe_bo_evict+0x40/0xa0 [xe] ? ttm_bo_pipeline_gutting+0x71/0x180 [ttm] xe_test_dmabuf_move_notify_no_resource+0x182/0x440 [xe] xe_dma_buf_kunit+0x387/0x580 [xe] v2: Add Fixes tag and failure info in commit text (Matt Brost) (cherry picked from commit dbcfaac6331f1fcb0c2fe3ad3e9adb1e5d43ec0c)
CVE-2026-99215 1 Linux 2 Linux, Linux Kernel 2026-10-28 4.1 Medium
In the Linux kernel, the following vulnerability has been resolved: power: supply: core: prevent unregistering a power supply while a callback runs Once a power supply is registered, its callbacks can immediately start firing from other contexts, such as external_power_changed() triggered by the TCPM stack. If a power supply is unregistered while the callback is still running, the driver data can already be freed when the callback tries to access it, leading to a use-after-free. This happens e.g. when the hardware bus carrying the power supply device malfunctions (e.g. I2C is hogged down by another malfunctioning device) immediately after the power supply is registered, and thus the core is still processing the callbacks which were queued up when the driver starts the removal, leading in some cases to a kernel crash, e.g.: [ 11.645942] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000005 [ 11.646751] Mem abort info: [ 11.647006] ESR = 0x0000000096000004 [ 11.647338] EC = 0x25: DABT (current EL), IL = 32 bits [ 11.647806] SET = 0, FnV = 0 [ 11.648077] EA = 0, S1PTW = 0 [ 11.648356] FSC = 0x04: level 0 translation fault [ 11.648785] Data abort info: [ 11.649041] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 11.649524] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 11.649981] GCS = 0, Overlay = 0, DirtyBit = 0 [ 11.650390] [0000000000000005] user address but active_mm is swapper [ 11.650955] Internal error: Oops: 0000000096000004 [#1] SMP [ 11.651460] Modules linked in: [ 11.651742] CPU: 1 UID: 0 PID: 144 Comm: kworker/1:2 Not tainted 7.2.0-rc6-g62a9297af2cd #1 PREEMPT [ 11.652553] Hardware name: Flipper One rev. F0B1C2 (DT) [ 11.653024] Workqueue: events power_supply_changed_work [ 11.653511] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 11.654135] pc : __power_supply_is_supplied_by+0x18/0x100 [ 11.654624] lr : __power_supply_am_i_supplied+0x40/0xb8 [ 11.655098] sp : ffff80008192bb30 [ 11.655399] x29: ffff80008192bb30 x28: 0000000000000000 x27: 0000000000000000 [ 11.656049] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 11.656695] x23: ffff0000c19f4200 x22: ffffdb2232ba4ea8 x21: ffff80008192bc28 [ 11.657344] x20: ffff0000c1eef000 x19: ffff80008192bc18 x18: 00000000a0886e62 [ 11.657991] x17: 000000040044ffff x16: 04500072b5503510 x15: 0000000000000000 [ 11.658639] x14: 0000000000000000 x13: 0000000000000220 x12: 0000000000000000 [ 11.659286] x11: 0000000000000000 x10: ffff0000c1fdb2b0 x9 : ffffdb2232ba5590 [ 11.659934] x8 : 00000000e5b906e6 x7 : ffff0000c2502778 x6 : ffffdb22339793d0 [ 11.660581] x5 : ffff80008192bc18 x4 : ffff0000c19cbca0 x3 : 0000000000000000 [ 11.661228] x2 : ffff0000c1fdaf40 x1 : ffffffffffffffed x0 : ffff0000c1eef000 [ 11.661878] Call trace: [ 11.662103] __power_supply_is_supplied_by+0x18/0x100 (P) [ 11.662596] __power_supply_am_i_supplied+0x40/0xb8 [ 11.663040] psy_for_each_psy_cb+0x20/0x40 [ 11.663416] class_for_each_device+0x110/0x150 [ 11.663825] power_supply_am_i_supplied+0x68/0x100 [ 11.664262] bq257xx_external_power_changed+0x58/0x140 [ 11.664733] __power_supply_changed_work+0x60/0x80 [ 11.665170] psy_for_each_psy_cb+0x20/0x40 [ 11.665545] class_for_each_device+0x110/0x150 [ 11.665953] power_supply_changed_work+0x98/0x1b8 [ 11.666382] process_one_work+0x164/0x4c0 [ 11.666758] worker_thread+0x19c/0x320 [ 11.667104] kthread+0x138/0x150 [ 11.667408] ret_from_fork+0x10/0x20 [ 11.667744] Code: d503233f a9bd7bfd 910003fd a90153f3 (f9400c34) [ 11.668294] ---[ end trace 0000000000000000 ]--- Add a read-write semaphore between external_power_changed() and power_supply_unregister() to prevent the latter from returning (and thus the driver from freeing its data) while the callback is still running.
CVE-2026-99194 1 Linux 2 Linux, Linux Kernel 2026-10-28 4.4 Medium
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: aeroflex: move setting of netops to fix crash greth_of_probe() calls greth_mdio_init(), which connects the PHY, before dev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash").
CVE-2026-99198 1 Linux 2 Linux, Linux Kernel 2026-10-28 4.4 Medium
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: actions: Move setting of netops to fix crash owl_emac_probe() calls owl_emac_phy_init(), which connects the PHY, before netdev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash").
CVE-2026-99200 1 Linux 2 Linux, Linux Kernel 2026-10-28 4.4 Medium
In the Linux kernel, the following vulnerability has been resolved: net: hisilicon: hisi_femac: Move setting of netops to fix crash hisi_femac_drv_probe() connects the PHY before dev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. phy_link_topo_add_phy from phy_attach_direct+0xec/0x37c of_phy_get_and_connect from hisi_femac_drv_probe+0x1f4/0x558 Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash").
CVE-2026-99184 1 Linux 2 Linux, Linux Kernel 2026-10-28 4.4 Medium
In the Linux kernel, the following vulnerability has been resolved: accel/rocket: search every core slot when a core is removed rocket_remove() decrements rdev->num_cores for each core it removes, while find_core_for_dev() searches slots 0 to num_cores - 1. Unbinding the cores in the order they were bound therefore loses the last one: by the time it is removed the search range has already shrunk past its slot, so find_core_for_dev() returns -1 and rocket_remove() gives up without doing anything. num_cores never reaches zero, rocket_device_fini() never runs, and the file-scoped rdev keeps pointing at a device that is going away. Binding the cores again starts from that stale count, because rocket_probe() takes rdev->num_cores as the slot to fill. On an RK3588, which describes three cores, the second round lands on slots 1, 2 and 3 while rdev->cores was allocated with room for three: rocket fdab0000.npu: Rockchip NPU core 1 version: 1179210309 rocket fdac0000.npu: Rockchip NPU core 2 version: 1179210309 rocket fdad0000.npu: Rockchip NPU core 3 version: 1179210309 The write to rdev->cores[3] is past the end of the array. Nothing in tree reads the core array often enough to notice, so the overrun is silent today. It turned up while testing a devfreq series on top of this, where a worker walks every core a few times a second, and UBSAN caught the first bool it read out of the overrun entry: UBSAN: invalid-load in drivers/accel/rocket/rocket_devfreq.c:47:10 load of value 5 is not a valid value for type '_Bool' Workqueue: devfreq_wq devfreq_monitor Record how many slots were allocated and search all of them. Every core is then found on removal, num_cores reaches zero, the device is torn down and a later bind starts from a clean rdev. This does not make unbinding a single core out of several work. probe still takes num_cores as the slot to fill, so rebinding one core while its siblings stay bound would write over a slot that is already in use, and rocket_open() still reaches for cores[0] whether or not anything is there. Both of those want more thought than a fix should carry. Found by unbinding and rebinding all three cores on an Orange Pi 5 Plus. With this applied, 25 unbind/rebind rounds and 5 module unload/reload rounds run clean there: the cores land in slots 0, 1 and 2 every time, whichever order they are bound in, and the shared supply goes back to a single user after each round.
CVE-2026-99186 1 Linux 2 Linux, Linux Kernel 2026-10-28 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: x86/insn-eval: Fix shadowed segment index in get_seg_reg_override_idx() Commit 45e1dccc0653 ("x86/insn: Simplify for_each_insn_prefix()") made for_each_insn_prefix() declare its own loop counter named idx. get_seg_reg_override_idx() keeps its result in a local of the same name, so the assignments in the loop body now write the loop counter: - the function always returns INAT_SEG_REG_DEFAULT, so FS and GS overrides are ignored; - a CS override sets the counter to INAT_SEG_REG_CS (2), the increment makes it 3, and prefixes.bytes[3] holds the last prefix, 0x2e again, so the loop never terminates. The UMIP emulation reaches this from the #GP handler for user space: an SGDT, SIDT or SMSW with a memory operand and a CS prefix leaves the task spinning in the kernel, never returning to user space, with a SIGKILL that is never delivered. Any user can thus tie up CPUs until reboot. With an FS or GS prefix, the emulated result is written to the wrong address. Rename the internal macro iterator variable. [ Lukas' original patch renamed the use site, I changed it to rename the iterator in the macro instead, but left Lukas' commit message and authorship - Linus ]
CVE-2026-99195 1 Linux 2 Linux, Linux Kernel 2026-10-28 4.4 Medium
In the Linux kernel, the following vulnerability has been resolved: net: ethoc: move setting of netops to fix crash ethoc_probe() calls ethoc_mdio_probe(), which connects the PHY, before netdev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash").
CVE-2026-99196 1 Linux 2 Linux, Linux Kernel 2026-10-28 4.4 Medium
In the Linux kernel, the following vulnerability has been resolved: net: au1000: move setting of netops to fix crash au1000_probe() calls au1000_mii_probe(), which connects the PHY, before dev->netdev_ops is assigned. phy_attach_direct() -> phy_link_topo_add_phy() reads dev->netdev_ops through netdev_need_ops_lock() since the commit in question, so probing crashes with a NULL pointer dereference when CONFIG_NET_SHAPER is enabled. Assign netdev_ops before the PHY attach, as was done for emac in commit 7c9f391ec89c ("net: emac: move setting of netops to fix crash").