p PatchFirst

PatchFirst · Aktuelle Sicherheitslücken

Sicherheitslücken in linux-lowlatency · Seite 64

In den letzten 30 Tagen veröffentlichte Sicherheitslücken für linux-lowlatency: 592. Davon im KEV-Katalog: 0.

Sicherheitslücken filtern
Filter zurücksetzen

Sicherheitslücken: 10942

  1. CVE-2026-90076

    Mittel · CVSS 6.8EPSS 0,21%Keine Korrektur veröffentlicht

    net/sched: fq: add overflow bounds to quantum and initial quantum

    In the Linux kernel, the following vulnerability has been resolved: net/sched: fq: add overflow bounds to quantum and initial quantum fq_init() computes quantum = 2 * psched_mtu() and initial_quantum = 10 * psched_mtu() with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000; the 2 * and 10 * multiplications wrap to 0 in 32-bit arithmetic, so q->quantum == 0. Then in fq_dequeue() the credit-refill loop adds 0 to f->credit (which stays <= 0) and goto begin loops forever under the qdisc lock, creating a soft lockup. Clamp psched_mtu() to [1, 1 << 20] before

    Veröffentlicht Aktualisiert
  2. CVE-2026-90075

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    net/sched: fq_codel: clamp default quantum and mtu

    In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_codel: clamp default quantum and mtu fq_codel_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_codel_dequeue(), causing an infinite loop and soft lockup. Emulate fq_codel_change() and constrain to [256, FQ_CODEL_QUANTUM_MAX]. The same unclamped psched_mtu() is assigned to q->cparams.mtu a bit below, and fq_codel_change() never updates it. codel_should_drop() tests

    Veröffentlicht Aktualisiert
  3. CVE-2026-90074

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    net/sched: fq_pie: clamp default quantum to avoid signed overflow

    In the Linux kernel, the following vulnerability has been resolved: net/sched: fq_pie: clamp default quantum to avoid signed overflow fq_pie_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) without clamping. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, which overflows the signed flow->deficit to INT_MIN in fq_pie_qdisc_dequeue(), causing an infinite loop and soft lockup. Emulate fq_pie_policy which is already bounded to [1, 1 << 20]; clamp the default to [256, 1 << 20]. 256 matches fq_codel's floor and is a sane minimum for a DRR quantum. Conditions to recreate th

    Veröffentlicht Aktualisiert
  4. CVE-2026-90073

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    net/sched: hhf: clamp quantum before hhf_change() to avoid overflow

    In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: clamp quantum before hhf_change() to avoid overflow hhf_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes weight * quantum overflow the signed deficit in hhf_dequeue(), spinning forever. Clamp q->quantum before hhf_change() so both the opt and !opt paths see a sane quantum. Without this, bare "tc qdisc add ... hhf" succeeds with a clamped quantum but "tc qdisc add ... hhf limit 1000" (any option present) fails with -EINVAL because hhf_change() re

    Veröffentlicht Aktualisiert
  5. CVE-2026-90072

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    net/sched: sfq: clamp quantum to avoid signed overflow soft lockup

    In the Linux kernel, the following vulnerability has been resolved: net/sched: sfq: clamp quantum to avoid signed overflow soft lockup sfq_init() sets q->quantum = psched_mtu(qdisc_dev(sch)) (unsigned). A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000, so slot->allot = INT_MIN and INT_MIN + INT_MIN toggles between INT_MIN and 0 forever, spinning sfq_dequeue() under the qdisc lock. Clamp the quantum to [256, 1 << 20] so the refill loop terminates. The lower bound also covers q->quantum == 0 (psched_mtu() returning 0), which spins sfq_dequeue() identically. sfq_change() alr

    Veröffentlicht Aktualisiert
  6. CVE-2026-90071

    Hoch · CVSS 7.8EPSS 0,16%Keine Korrektur veröffentlicht

    net/sched: sch_teql: restore skb->dev on the slave failure path

    In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_teql: restore skb->dev on the slave failure path teql_master_xmit() sets skb->dev = slave before calling the slave's ndo_start_xmit(), but never restores it when that transmit fails. The skb then walks on to the next slave still pointing at the previous one. If a later slave has no resolved neighbour, teql_resolve() hands the skb to neigh_event_send(), which queues it on that neighbour's arp_queue with the stale skb->dev. skb->dev holds no reference, so deleting the previous slave frees the net_device while the skb is still queued. Whatever runs next on that

    Veröffentlicht Aktualisiert
  7. CVE-2026-90070

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    tpm: st33zp24: Return zero on status read failure

    In the Linux kernel, the following vulnerability has been resolved: tpm: st33zp24: Return zero on status read failure st33zp24_status() ignores the result of the transport read and returns data even when no byte was received. The I2C transport, for example, skips i2c_master_recv() when the register-select write is short or fails, leaving data uninitialized. The resulting stack value can be interpreted as TPM_STS flags and let status checks complete spuriously. The status callback cannot propagate a transport error. Return zero unless recv() reports exactly one byte. With no status bits set, callers retry or take their existing timeout or e

    Veröffentlicht Aktualisiert
  8. CVE-2026-90068

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    ASoC: dapm: Fix off-by-one check on the second enum channel

    In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: Fix off-by-one check on the second enum channel The snd_soc_dapm_put_enum_double() rejects item[0] once it reaches e->items, but it lets item[1] be equal to it. Both go on to snd_soc_enum_item_to_val(), which indexes e->values with no bound of its own, so an enum with a value table reads one element past the end. The indexing arrived with the MUX consolidation, which relaxed the item[1] check in the same hunk. The value MUX handler it deleted used >= there, and the snd_soc_put_enum_double() in soc-ops.c still does. Only adav80x pairs a value table with two s

    Veröffentlicht Aktualisiert
  9. CVE-2026-90067

    Hoch · CVSS 7.5EPSS 0,68%Keine Korrektur veröffentlicht

    libceph: validate banner payload length

    In the Linux kernel, the following vulnerability has been resolved: libceph: validate banner payload length When parsing the Ceph messenger v2 protocol banner, the `payload_len` field is decoded from the banner prefix. If a client sends a banner with a `payload_len` of 0, the kernel sets up a 0-length socket read. This violates an invariant in the state machine, triggering a warning in `populate_in_iter()`: ------------[ cut here ]------------ !iov_iter_count(&con->v2.in_iter) WARNING: net/ceph/messenger_v2.c:3129 at populate_in_iter net/ceph/messenger_v2.c:3129 [inline], CPU#1: kworker/1:3/5070 WARNING: net/ceph/messenger_v2.c:3129 at cep

    Veröffentlicht Aktualisiert
  10. CVE-2026-90063

    Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht

    virtio-net: Ensure that TCP packets don't overflow gso_segs

    In the Linux kernel, the following vulnerability has been resolved: virtio-net: Ensure that TCP packets don't overflow gso_segs The user can specify any gso_size in a packet crafted with an AF_PACKET PACKET_VNET_HDR socket, even smaller than TCP_MIN_GSO_SIZE = 8. At the same time, GSO_MAX_SIZE = 8 * GSO_MAX_SEGS = 8 * 65535. When the user crafts a packet with gso_size < 8, there is a risk for partial GSO to overflow the 16-bit gso_segs field when dividing the SKB length by gso_size. Adjust gso_size of TCP packets to be at least TCP_MIN_GSO_SIZE = 8. Keep gso_size of UDP GSO packets, as gso_size=1 is valid and explicitly tested at tools/tes

    Veröffentlicht Aktualisiert
  11. CVE-2026-90062

    Hoch · CVSS 7.1EPSS 0,16%Keine Korrektur veröffentlicht

    netfilter: nf_tables: move hardware offload step after building the chain blob

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: move hardware offload step after building the chain blob Allocate the chain blob before the ruleset offload to reduce chances of entering an inconsistent state where the offloaded ruleset in the nic and the software ruleset differ.

    Veröffentlicht Aktualisiert
  12. CVE-2026-90061

    Mittel · CVSS 6.8EPSS 0,21%Keine Korrektur veröffentlicht

    netfilter: nf_tables: skip double clone set expressions on element insert

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: skip double clone set expressions on element insert Both the dynset and newsetelem path clone the existing set expressions when setting set element expressions if no override expressions are provided. This results in a double clone, once to clone the template set expressions then another clone on the new element. Add a flag to annotate if userspace provides a override expression (ie. expression of the same type of the set but different configuration), otherwise borrow the existing expression from the set. Add conditionals to release expression iif they

    Veröffentlicht Aktualisiert
  13. CVE-2026-90060

    Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht

    ALSA: control: Don't add invalid kcontrols to LED layer

    In the Linux kernel, the following vulnerability has been resolved: ALSA: control: Don't add invalid kcontrols to LED layer The kcontrol LED state layer tries to track the all associated kcontrol elements with naive assumptions that they are readable. But one can create a write-only element that has no get callback (even a user element can do it), and this may lead to a NULL dereference at the call chain of snd_ctl_led_notify(), as found by syzkaller. For avoiding the Oops, add a sanity check of the kcontrol's info and get callbacks, and just skip the invalid kcontrols before assigning the kctl to the LED layer.

    Veröffentlicht Aktualisiert
  14. CVE-2026-90058

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup

    In the Linux kernel, the following vulnerability has been resolved: net/sched: bound qdisc_pkt_len to prevent qdisc soft lockup qdisc_get_stab() accepts a user-supplied size table, and __qdisc_calculate_pkt_len() amplifies qdisc_pkt_len() through the overhead, the size-table data (u16), and size_log (up to STAB_SIZE_LOG_MAX). A crafted stab can therefore set qdisc_pkt_len() to ~1 GiB for an ordinary skb. Per-flow deficit schedulers such as DRR and ETS replenish one quantum per loop iteration; with a tiny quantum (1) they spin billions of times under the qdisc lock, producing a soft lockup / RCU stall as illustrated by [email protected]. Cap

    Veröffentlicht Aktualisiert
  15. CVE-2026-90057

    Hoch · CVSS 7.8EPSS 0,16%Keine Korrektur veröffentlicht

    slip: remove slip_hangup() to fix use-after-free in slip_receive_buf()

    In the Linux kernel, the following vulnerability has been resolved: slip: remove slip_hangup() to fix use-after-free in slip_receive_buf() Jaeyoung Chung and Eulgyu Kim reported a slab-use-after-free read in slip_receive_buf() when racing against tty hangup. tty_ldisc_hangup() calls ld->ops->hangup() while holding only a read lock on tty->ldisc_sem (via tty_ldisc_ref()). Because slip_hangup() simply called slip_close(), it ran concurrently with reader functions such as slip_receive_buf(). slip_close() unregisters and frees the net device and its private struct slip, causing concurrent reader threads in slip_receive_buf() to dereference fr

    Veröffentlicht Aktualisiert
  16. CVE-2026-90056

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    net: fec: only stop PTP if it was initialized

    In the Linux kernel, the following vulnerability has been resolved: net: fec: only stop PTP if it was initialized fec_ptp_init() is only called when fep->bufdesc_ex is available. However, fec_probe() unconditionally calls fec_ptp_stop() on the failed_init path, and fec_drv_remove() unconditionally calls fec_ptp_stop() during device removal. Check fep->bufdesc_ex before calling fec_ptp_stop() in both paths to avoid stopping PTP when it was not initialized.

    Veröffentlicht Aktualisiert
  17. CVE-2026-90055

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    usb: atm: usbatm: fix invalid ci_range initialization

    In the Linux kernel, the following vulnerability has been resolved: usb: atm: usbatm: fix invalid ci_range initialization syzbot reported a shift-out-of-bounds in __vcc_connect(): UBSAN: shift-out-of-bounds in net/atm/common.c:382:32 shift exponent -1 is negative CPU: 0 UID: 0 PID: 5987 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/05/2026 Call Trace: <TASK> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 ubsan_epilogue+0xa/0x30 lib/ubsan.c:233 __ubsan_handle_shift_out_of_bounds+0x36d/0x400 lib/ubsan.c:494 __vcc_connect+0x14b4/0x19c0

    Veröffentlicht Aktualisiert
  18. CVE-2026-90054

    Nicht bewertetEPSS 0,22%Keine Korrektur veröffentlicht

    tcp: fix corruption of urgent data on multi-segment retransmit

    In the Linux kernel, the following vulnerability has been resolved: tcp: fix corruption of urgent data on multi-segment retransmit On the normal xmit path, while in urgent mode we refuse to build a multi-segment TSO packet, so every segment gets its own urg_ptr: /* tcp_write_xmit() */ limit = mss_now; if (tso_segs > 1 && !tcp_urg_mode(tp)) limit = tcp_mss_split_point(...); The retransmit path has no such guard. __tcp_retransmit_skb() builds a segs > 1 skb and hands it to the GSO layer, which only advances th->seq per segment and copies urg_ptr verbatim: /* __tcp_retransmit_skb() */ len = cur_mss * segs; /* segs > 1, no urg_mode c

    Veröffentlicht Aktualisiert
  19. CVE-2026-90053

    Nicht bewertetEPSS 0,21%Keine Korrektur veröffentlicht

    net/sched: sch_htb: limit htb_classify inner-class filter hops

    In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_htb: limit htb_classify inner-class filter hops htb_classify() follows each filter-selected inner class by switching to cl->filter_list, but never bounds the number of hops. A filter on an inner class can point back to itself or to another inner class that points back, creating an infinite loop in the packet classification path with the qdisc lock held and BH disabled — a soft lockup / panic from a single packet. Bound the traversal with a hop counter and drop the packet with a rate-limited warning once the bound is exceeded. The counter is incremented at th

    Veröffentlicht Aktualisiert
  20. CVE-2026-90049

    Kritisch · CVSS 9.3EPSS 0,17%Öffentlicher ExploitKeine Korrektur veröffentlicht

    net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy()

    In the Linux kernel, the following vulnerability has been resolved: net: skbuff: don't skb_tx_error() the source skb in skb_zerocopy() skb_zerocopy() copies frags from @from into @to. On an skb_orphan_frags() failure it calls skb_tx_error(@from), a destructive operation on the source skb the copy helper does not own. That completes @from's zerocopy uarg and clears SKBFL_ALL_ZEROCOPY, including the SKBFL_SHARED_FRAG page-ownership marker. Both callers already report the failure on their own drop path. nfnetlink_queue does it at nla_put_failure, and Open vSwitch does it in the flow-miss drop arm of ovs_dp_process_packet(), so nothing is lost

    Veröffentlicht Aktualisiert

Prüfen Sie Ihren Server

Gleichen Sie Ihren installierten Stack und seine Versionen mit den aktuellen Sicherheitsmeldungen ab.

Prüfen Sie Ihren Server →