Vulnerabilidades

*** Pendiente de traducción *** Nagios Core before 4.5.13 and Nagios XI before 2026R1.5 contains a CSRF vulnerability in cmd.cgi. When no Cookie header is present, the double-submit cookie protection can be bypassed by supplying matching NagFormId and nagFormId values in the POST body, allowing a cross-site request to execute Nagios commands as a currently authenticated user.

*** Pendiente de traducción *** Nagios Core before 4.5.12 contains a cross-site request forgery vulnerability in cmd.cgi where the CSRF protection mechanism passes validation when the NagFormId cookie is absent. Attackers can craft a malicious cross-site POST request to execute arbitrary Nagios commands as a currently authenticated user without their knowledge or consent.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: avoid combining some incoming suboptions<br /> <br /> Some MPTCP suboptions are mutually exclusive according to the RFC8684,<br /> but also because in different places, the code doesn&amp;#39;t expect some<br /> combinations to be present. That&amp;#39;s specially true for suboptions that<br /> would be present twice, but with different attributes.<br /> <br /> The new restrictions are the same as the ones applied on the output<br /> side, with mptcp_write_options. The same rules can be reused with a<br /> small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks<br /> this option [1], which is not the case on Linux. Here are the rules:<br /> <br /> Which options can be used together?<br /> <br /> X: mutually exclusive<br /> O: often used together<br /> C: can be used together in some cases<br /> P: could be used together but we prefer not to (optimisations)<br /> <br /> | Opt: | MPC | MPJ | DSS | ADD | RM | PRIO | FAIL | FC |<br /> |------|------|------|------|------|------|------|------|------|<br /> | MPC |------|------|------|------|------|------|------|------|<br /> | MPJ | X |------|------|------|------|------|------|------|<br /> | DSS | X | X |------|------|------|------|------|------|<br /> | ADD | X | X | P |------|------|------|------|------|<br /> | RM | C | C | C | P |------|------|------|------|<br /> | PRIO | X | C | C | C | C |------|------|------|<br /> | FAIL | X | X | C | X | X | X |------|------|<br /> | FC | X | X | P | X | X | X | X |------|<br /> | RST | X | X | X | X | X | X | O | O |<br /> |------|------|------|------|------|------|------|------|------|<br /> <br /> The only difference is with the &amp;#39;P&amp;#39;: another stack could send and<br /> ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be<br /> allowed.<br /> <br /> A few points of attention:<br /> <br /> - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is<br /> no reason to add it with a SYN. Note that even with a 4th ACK, it<br /> doesn&amp;#39;t seem to be useful, except when IDs are known in advance via<br /> another channel. Better not to break that.<br /> <br /> - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer<br /> result to a reject of the two options, but only the second suboption<br /> is ignored. That seems OK to do that for this unexpected error. At<br /> least now all inconsistent combinations are handled the same way.<br /> This could change later in next. This also means the explicit checks<br /> for having both MPC + MPJ in subflow.c will now be unreachable.<br /> That&amp;#39;s fine, they will be removed in a follow-up patch.<br /> <br /> - In case of conflicting combinations, the extra suboption(s) is/are<br /> ignored: having such combinations either means the remote peer is<br /> buggy, or is evil. The simplest action is then taken in this case:<br /> stop processing the current suboption.<br /> <br /> - In mp_opt-&gt;suboptions, there is also a bit reserved to the checksum,<br /> which can be used in an MP_CAPABLE and a DSS. Each time a DSS option<br /> can be used in parallel with another option, the checksum can be set,<br /> so the verification is combined into a new OPTIONS_MPTCP_DSS macro.<br /> <br /> - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional<br /> Checksum: they are the same as the ones found in a DSS, because a DSS<br /> cannot be used in parallel to an MP_CAPABLE. Similarly, even if there<br /> is room, a DSS cannot be used with an MP_JOIN.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: reclaim forward-allocated memory on RX path errors<br /> <br /> After commit 9db5b3cec4ec ("mptcp: borrow forward memory from subflow"),<br /> errors in the receive path prior to queueing skbs into the receive<br /> queue do not trigger forward-allocated memory reclaiming.<br /> <br /> Prevent forward memory from growing unboundedly in pathological drop<br /> scenarios by explicitly reclaiming memory when skbs are dropped.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: stop the timeout timer when releasing a never added disk<br /> <br /> disk_release() undoes blk_mq_init_allocated_queue() for a disk whose<br /> probe failed before add_disk(), but it only calls blk_mq_exit_queue().<br /> Nothing there stops q-&gt;timeout, and that timer rolls forward: it stays<br /> pending until it next expires, not until the last request completes.<br /> So if the driver issued any I/O before adding the disk, the<br /> request_queue is freed while still linked into a timer wheel bucket.<br /> <br /> Commit 6f8191fdf41d ("block: simplify disk shutdown") dropped the<br /> blk_cleanup_queue() call that used to stop it. __del_gendisk() and<br /> blk_mq_destroy_queue() still do; only the probe failure path lost it.<br /> <br /> nvme gets there because nvme_update_ns_info() submits Report Zones or<br /> FDP io-mgmt-recv on ns-&gt;queue before the disk is added, so a later<br /> failure - a concurrent reset setting NVME_CTRL_FROZEN, or<br /> device_add_disk() failing - lands in put_disk() with the timer armed:<br /> <br /> BUG: KASAN: slab-use-after-free in detach_if_pending+0x30c/0x340<br /> Write of size 8 at addr ffff888004d71310 by task kworker/u8:2/37<br /> __timer_delete_sync+0x156/0x240 kernel/time/timer.c:1621<br /> blk_sync_queue+0x22/0x40 block/blk-core.c:222<br /> nvme_sync_queues+0x100/0x150 drivers/nvme/host/core.c:5362<br /> nvme_reset_work+0x138/0x930 drivers/nvme/host/pci.c:3264<br /> <br /> Allocated by task 34:<br /> __blk_mq_alloc_disk+0x33/0x100 block/blk-mq.c:4462<br /> nvme_alloc_ns+0x290/0x3870 drivers/nvme/host/core.c:4146<br /> <br /> Freed by task 0:<br /> blk_free_queue_rcu+0x3a/0x50 block/blk-core.c:254<br /> rcu_core+0xc10/0x1730 kernel/rcu/tree.c:2857<br /> <br /> The queue being synced there is ctrl-&gt;admin_q, only a victim sharing a<br /> timer wheel bucket with the freed queue&amp;#39;s dangling entry; other runs<br /> tripped in enqueue_timer(), __run_timers() or blk_mq_timeout_work().<br /> Failing nvme_alloc_ns() with a debug patch makes it deterministic: one<br /> leaked timer trips KASAN within seconds, while 1987 patched releases<br /> produced no splat.<br /> <br /> Stop the timer and the queue work items before blk_mq_exit_queue(), like<br /> blk_mq_destroy_queue() does.<br /> <br /> Found by FuzzNvme.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: clear fb_info-&gt;mode before deleting a videomode<br /> <br /> fb_set_var() can delete a mode from info-&gt;modelist when userspace<br /> passes FB_ACTIVATE_INV_MODE through FBIOPUT_VSCREENINFO. The code<br /> checks that the mode being deleted is not the current info-&gt;var and<br /> that fbcon is not using it, but it does not check fb_info-&gt;mode.<br /> <br /> fb_info-&gt;mode may still point into the modelist entry being deleted.<br /> If the entry is freed, later mode sysfs reads through show_mode() can<br /> dereference a stale pointer.<br /> <br /> Clear fb_info-&gt;mode before calling fb_delete_videomode() when it<br /> matches the mode being removed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: bound mode sysfs output to the sysfs buffer<br /> <br /> mode_string() uses snprintf() which can return a value larger than the<br /> remaining buffer space. show_modes() accumulates the return value into i<br /> without checking whether i has reached PAGE_SIZE, causing the offset to<br /> advance past the sysfs buffer if the modelist is long enough.<br /> <br /> Add a size parameter to mode_string() and use scnprintf() to return<br /> only the bytes actually written. Add an early return when offset<br /> already exceeds the buffer. In show_modes(), stop accumulating once<br /> the buffer is full.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: ipc4-pcm: Continue the pipeline trigger in case of IPC timeout<br /> <br /> Ignore IPC errors for pipeline state change if the firmware state is<br /> crashed or the IPC has timed out.<br /> <br /> If the firmware has crashed the kernel still needs to go through the state<br /> changes to reset its internal to be able to correctly work the next time<br /> the DSP is booted up.<br /> <br /> The case with IPC timeout is a bit more problematic, but it has been<br /> rootcaused to be the result of system scheduling blockage and the firmware<br /> did actually received and handled the message, but the reply handling got<br /> blocked by issues outside of the SOF stack.<br /> So far the best way to handle this is to continue with setting the state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/shmem_helper: Check VMA boundaries for PMD mappings<br /> <br /> In the -&gt;huge_fault handler do not install a PMD huge page<br /> mapping if the huge page exceeds the boundaries of the VMA.<br /> <br /> All other -&gt;huge_fault handlers have similar checks and the<br /> resulting mapping will trigger a VM_BUG_ON_VMA() if it ever<br /> reaches copy_pmd_range().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codecs: lpass-tx-macro: Fix enum kcontrol accesses<br /> <br /> The "DEC0 MODE" to "DEC7 MODE" controls are enumerated, but<br /> tx_macro_dec_mode_get() and tx_macro_dec_mode_put() access their<br /> value through ucontrol-&gt;value.integer.value[0] (a long) instead of<br /> ucontrol-&gt;value.enumerated.item[0] (an unsigned int).<br /> <br /> This same pattern was fixed in the sibling drivers by<br /> commit bcfe5f76cc40 ("ASoC: codecs: rx-macro: fix accessing array<br /> out of bounds for enum type") and<br /> commit 0ea5eff7c606 ("ASoC: codecs: va-macro: fix accessing array<br /> out of bounds for enum type"), but tx-macro was missed.<br /> <br /> On 64-bit kernels built with CONFIG_SND_CTL_DEBUG, the elem value<br /> sanity check catches the 4 bytes written past the enumerated item<br /> and every read of these controls fails with -EINVAL:<br /> <br /> snd-sm8250 sound: control 2:0:0:DEC0 MODE:0: access overflow

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/qeth: validate user buffer length in SNMP and ARP query ioctls<br /> <br /> qeth_snmp_command() and qeth_l3_arp_query() allocate a buffer sized by<br /> a user-supplied length (udata_len) without checking a lower bound, then<br /> set udata_offset to a fixed non-zero value and pass both to a reply<br /> callback. The callback bounds-checks the copy with<br /> <br /> if ((udata_len - udata_offset)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fastopen: only mark MPTFO subflows with SYN data<br /> <br /> Passive TCP Fast Open accepts a valid-cookie SYN even when it carries<br /> no data. In that case the child socket&amp;#39;s receive queue is intentionally<br /> left empty.<br /> <br /> mptcp_fastopen_subflow_synack_set_params() set is_mptfo before checking<br /> for queued SYN data. That made data-less TFO SYNs hit a WARN and, if<br /> the warning was non-fatal, left stale MPTFO state behind. The stale<br /> flag could later trigger a state-confusion bug in<br /> check_fully_established().<br /> <br /> Only mark the subflow as MPTFO after confirming that an SKB was queued.<br /> Return quietly when the receive queue is empty.<br /> <br /> Note that mptcp_subflow_context&amp;#39;s is_mptfo field is now not just about<br /> subflows where the TFO was present, but about MPTFO subflow that<br /> consumed SYN data. Only having a valid cookie but not carrying data is<br /> not really "doing TFO".