Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: pcl726: Prevent invalid irq number<br /> <br /> The reproducer passed in an irq number(0x80008000) that was too large,<br /> which triggered the oob.<br /> <br /> Added an interrupt number check to prevent users from passing in an irq<br /> number that was too large.<br /> <br /> If `it-&gt;options[1]` is 31, then `1 options[1]` value to 30 or lower, or using `1U

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl()<br /> <br /> syzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`. A kernel<br /> buffer is allocated to hold `insn-&gt;n` samples (each of which is an<br /> `unsigned int`). For some instruction types, `insn-&gt;n` samples are<br /> copied back to user-space, unless an error code is being returned. The<br /> problem is that not all the instruction handlers that need to return<br /> data to userspace fill in the whole `insn-&gt;n` samples, so that there is<br /> an information leak. There is a similar syzbot report for<br /> `do_insnlist_ioctl()`, although it does not have a reproducer for it at<br /> the time of writing.<br /> <br /> One culprit is `insn_rw_emulate_bits()` which is used as the handler for<br /> `INSN_READ` or `INSN_WRITE` instructions for subdevices that do not have<br /> a specific handler for that instruction, but do have an `INSN_BITS`<br /> handler. For `INSN_READ` it only fills in at most 1 sample, so if<br /> `insn-&gt;n` is greater than 1, the remaining `insn-&gt;n - 1` samples copied<br /> to userspace will be uninitialized kernel data.<br /> <br /> Another culprit is `vm80xx_ai_insn_read()` in the "vm80xx" driver. It<br /> never returns an error, even if it fails to fill the buffer.<br /> <br /> Fix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making sure<br /> that uninitialized parts of the allocated buffer are zeroed before<br /> handling each instruction.<br /> <br /> Thanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`. That fix<br /> replaced the call to `kmalloc_array()` with `kcalloc()`, but it is not<br /> always necessary to clear the whole buffer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: server: split ksmbd_rdma_stop_listening() out of ksmbd_rdma_destroy()<br /> <br /> We can&amp;#39;t call destroy_workqueue(smb_direct_wq); before stop_sessions()!<br /> <br /> Otherwise already existing connections try to use smb_direct_wq as<br /> a NULL pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/buffer: fix use-after-free when call bh_read() helper<br /> <br /> There&amp;#39;s issue as follows:<br /> BUG: KASAN: stack-out-of-bounds in end_buffer_read_sync+0xe3/0x110<br /> Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0<br /> CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x86_64<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x55/0x70<br /> print_address_description.constprop.0+0x2c/0x390<br /> print_report+0xb4/0x270<br /> kasan_report+0xb8/0xf0<br /> end_buffer_read_sync+0xe3/0x110<br /> end_bio_bh_io_sync+0x56/0x80<br /> blk_update_request+0x30a/0x720<br /> scsi_end_request+0x51/0x2b0<br /> scsi_io_completion+0xe3/0x480<br /> ? scsi_device_unbusy+0x11e/0x160<br /> blk_complete_reqs+0x7b/0x90<br /> handle_softirqs+0xef/0x370<br /> irq_exit_rcu+0xa5/0xd0<br /> sysvec_apic_timer_interrupt+0x6e/0x90<br /> <br /> <br /> Above issue happens when do ntfs3 filesystem mount, issue may happens<br /> as follows:<br /> mount IRQ<br /> ntfs_fill_super<br /> read_cache_page<br /> do_read_cache_folio<br /> filemap_read_folio<br /> mpage_read_folio<br /> do_mpage_readpage<br /> ntfs_get_block_vbo<br /> bh_read<br /> submit_bh<br /> wait_on_buffer(bh);<br /> blk_complete_reqs<br /> scsi_io_completion<br /> scsi_end_request<br /> blk_update_request<br /> end_bio_bh_io_sync<br /> end_buffer_read_sync<br /> __end_buffer_read_notouch<br /> unlock_buffer<br /> <br /> wait_on_buffer(bh);--&gt; return will return to caller<br /> <br /> put_bh<br /> --&gt; trigger stack-out-of-bounds<br /> In the mpage_read_folio() function, the stack variable &amp;#39;map_bh&amp;#39; is<br /> passed to ntfs_get_block_vbo(). Once unlock_buffer() unlocks and<br /> wait_on_buffer() returns to continue processing, the stack variable<br /> is likely to be reclaimed. Consequently, during the end_buffer_read_sync()<br /> process, calling put_bh() may result in stack overrun.<br /> <br /> If the bh is not allocated on the stack, it belongs to a folio. Freeing<br /> a buffer head which belongs to a folio is done by drop_buffers() which<br /> will fail to free buffers which are still locked. So it is safe to call<br /> put_bh() before __end_buffer_read_notouch().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: accel: sca3300: fix uninitialized iio scan data<br /> <br /> Fix potential leak of uninitialized stack data to userspace by ensuring<br /> that the `channels` array is zeroed before use.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: light: as73211: Ensure buffer holes are zeroed<br /> <br /> Given that the buffer is copied to a kfifo that ultimately user space<br /> can read, ensure we zero it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Limit access to parser-&gt;buffer when trace_get_user failed<br /> <br /> When the length of the string written to set_ftrace_filter exceeds<br /> FTRACE_BUFF_MAX, the following KASAN alarm will be triggered:<br /> <br /> BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0<br /> Read of size 1 at addr ffff0000d00bd5ba by task ash/165<br /> <br /> CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> show_stack+0x34/0x50 (C)<br /> dump_stack_lvl+0xa0/0x158<br /> print_address_description.constprop.0+0x88/0x398<br /> print_report+0xb0/0x280<br /> kasan_report+0xa4/0xf0<br /> __asan_report_load1_noabort+0x20/0x30<br /> strsep+0x18c/0x1b0<br /> ftrace_process_regex.isra.0+0x100/0x2d8<br /> ftrace_regex_release+0x484/0x618<br /> __fput+0x364/0xa58<br /> ____fput+0x28/0x40<br /> task_work_run+0x154/0x278<br /> do_notify_resume+0x1f0/0x220<br /> el0_svc+0xec/0xf0<br /> el0t_64_sync_handler+0xa0/0xe8<br /> el0t_64_sync+0x1ac/0x1b0<br /> <br /> The reason is that trace_get_user will fail when processing a string<br /> longer than FTRACE_BUFF_MAX, but not set the end of parser-&gt;buffer to 0.<br /> Then an OOB access will be triggered in ftrace_regex_release-&gt;<br /> ftrace_process_regex-&gt;strsep-&gt;strpbrk. We can solve this problem by<br /> limiting access to parser-&gt;buffer when trace_get_user failed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helper<br /> <br /> Since<br /> <br /> 923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot")<br /> <br /> resctrl_cpu_detect() has been moved from common CPU initialization code to<br /> the vendor-specific BSP init helper, while Hygon didn&amp;#39;t put that call in their<br /> code.<br /> <br /> This triggers a division by zero fault during early booting stage on our<br /> machines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() tries<br /> to calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale.<br /> <br /> Add the missing resctrl_cpu_detect() in the Hygon BSP init helper.<br /> <br /> [ bp: Massage commit message. ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: Fix backlog accounting in qdisc_dequeue_internal<br /> <br /> This issue applies for the following qdiscs: hhf, fq, fq_codel, and<br /> fq_pie, and occurs in their change handlers when adjusting to the new<br /> limit. The problem is the following in the values passed to the<br /> subsequent qdisc_tree_reduce_backlog call given a tbf parent:<br /> <br /> When the tbf parent runs out of tokens, skbs of these qdiscs will<br /> be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued,<br /> which accounts for both qlen and backlog. However, in the case of<br /> qdisc_dequeue_internal, ONLY qlen is accounted for when pulling<br /> from gso_skb. This means that these qdiscs are missing a<br /> qdisc_qstats_backlog_dec when dropping packets to satisfy the<br /> new limit in their change handlers.<br /> <br /> One can observe this issue with the following (with tc patched to<br /> support a limit of 0):<br /> <br /> export TARGET=fq<br /> tc qdisc del dev lo root<br /> tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms<br /> tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000<br /> echo &amp;#39;&amp;#39;; echo &amp;#39;add child&amp;#39;; tc -s -d qdisc show dev lo<br /> ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2&gt;&amp;1 &gt;/dev/null<br /> echo &amp;#39;&amp;#39;; echo &amp;#39;after ping&amp;#39;; tc -s -d qdisc show dev lo<br /> tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0<br /> echo &amp;#39;&amp;#39;; echo &amp;#39;after limit drop&amp;#39;; tc -s -d qdisc show dev lo<br /> tc qdisc replace dev lo handle 2: parent 1:1 sfq<br /> echo &amp;#39;&amp;#39;; echo &amp;#39;post graft&amp;#39;; tc -s -d qdisc show dev lo<br /> <br /> The second to last show command shows 0 packets but a positive<br /> number (74) of backlog bytes. The problem becomes clearer in the<br /> last show command, where qdisc_purge_queue triggers<br /> qdisc_tree_reduce_backlog with the positive backlog and causes an<br /> underflow in the tbf parent&amp;#39;s backlog (4096 Mb instead of 0).<br /> <br /> To fix this issue, the codepath for all clients of qdisc_dequeue_internal<br /> has been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel.<br /> qdisc_dequeue_internal handles the backlog adjustments for all cases that<br /> do not directly use the dequeue handler.<br /> <br /> The old fq_codel_change limit adjustment loop accumulated the arguments to<br /> the subsequent qdisc_tree_reduce_backlog call through the cstats field.<br /> However, this is confusing and error prone as fq_codel_dequeue could also<br /> potentially mutate this field (which qdisc_dequeue_internal calls in the<br /> non gso_skb case), so we have unified the code here with other qdiscs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/amd/hsmp: Ensure sock-&gt;metric_tbl_addr is non-NULL<br /> <br /> If metric table address is not allocated, accessing metrics_bin will<br /> result in a NULL pointer dereference, so add a check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().<br /> <br /> When the nvif_vmm_type is invalid, we will return error directly<br /> without freeing the args in nvif_vmm_ctor(), which leading a memory<br /> leak. Fix it by setting the ret -EINVAL and goto done.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: rtl9300: Fix out-of-bounds bug in rtl9300_i2c_smbus_xfer<br /> <br /> The data-&gt;block[0] variable comes from user. Without proper check,<br /> the variable may be very large to cause an out-of-bounds bug.<br /> <br /> Fix this bug by checking the value of data-&gt;block[0] first.<br /> <br /> 1. commit 39244cc75482 ("i2c: ismt: Fix an out-of-bounds bug in<br /> ismt_access()")<br /> 2. commit 92fbb6d1296f ("i2c: xgene-slimpro: Fix out-of-bounds bug in<br /> xgene_slimpro_i2c_xfer()")