Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/fbdev-generic: prohibit potential out-of-bounds access<br /> <br /> The fbdev test of IGT may write after EOF, which lead to out-of-bound<br /> access for drm drivers with fbdev-generic. For example, run fbdev test<br /> on a x86+ast2400 platform, with 1680x1050 resolution, will cause the<br /> linux kernel hang with the following call trace:<br /> <br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> [IGT] fbdev: starting subtest eof<br /> Workqueue: events drm_fb_helper_damage_work [drm_kms_helper]<br /> [IGT] fbdev: starting subtest nullptr<br /> <br /> RIP: 0010:memcpy_erms+0xa/0x20<br /> RSP: 0018:ffffa17d40167d98 EFLAGS: 00010246<br /> RAX: ffffa17d4eb7fa80 RBX: ffffa17d40e0aa80 RCX: 00000000000014c0<br /> RDX: 0000000000001a40 RSI: ffffa17d40e0b000 RDI: ffffa17d4eb80000<br /> RBP: ffffa17d40167e20 R08: 0000000000000000 R09: ffff89522ecff8c0<br /> R10: ffffa17d4e4c5000 R11: 0000000000000000 R12: ffffa17d4eb7fa80<br /> R13: 0000000000001a40 R14: 000000000000041a R15: ffffa17d40167e30<br /> FS: 0000000000000000(0000) GS:ffff895257380000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffa17d40e0b000 CR3: 00000001eaeca006 CR4: 00000000001706e0<br /> Call Trace:<br /> <br /> ? drm_fbdev_generic_helper_fb_dirty+0x207/0x330 [drm_kms_helper]<br /> drm_fb_helper_damage_work+0x8f/0x170 [drm_kms_helper]<br /> process_one_work+0x21f/0x430<br /> worker_thread+0x4e/0x3c0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xf4/0x120<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2c/0x50<br /> <br /> CR2: ffffa17d40e0b000<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The is because damage rectangles computed by<br /> drm_fb_helper_memory_range_to_clip() function is not guaranteed to be<br /> bound in the screen&amp;#39;s active display area. Possible reasons are:<br /> <br /> 1) Buffers are allocated in the granularity of page size, for mmap system<br /> call support. The shadow screen buffer consumed by fbdev emulation may<br /> also choosed be page size aligned.<br /> <br /> 2) The DIV_ROUND_UP() used in drm_fb_helper_memory_range_to_clip()<br /> will introduce off-by-one error.<br /> <br /> For example, on a 16KB page size system, in order to store a 1920x1080<br /> XRGB framebuffer, we need allocate 507 pages. Unfortunately, the size<br /> 1920*1080*4 can not be divided exactly by 16KB.<br /> <br /> 1920 * 1080 * 4 = 8294400 bytes<br /> 506 * 16 * 1024 = 8290304 bytes<br /> 507 * 16 * 1024 = 8306688 bytes<br /> <br /> line_length = 1920*4 = 7680 bytes<br /> <br /> 507 * 16 * 1024 / 7680 = 1081.6<br /> <br /> off / line_length = 507 * 16 * 1024 / 7680 = 1081<br /> DIV_ROUND_UP(507 * 16 * 1024, 7680) will yeild 1082<br /> <br /> memcpy_toio() typically issue the copy line by line, when copy the last<br /> line, out-of-bound access will be happen. Because:<br /> <br /> 1082 * line_length = 1082 * 7680 = 8309760, and 8309760 &gt; 8306688<br /> <br /> Note that userspace may still write to the invisiable area if a larger<br /> buffer than width x stride is exposed. But it is not a big issue as<br /> long as there still have memory resolve the access if not drafting so<br /> far.<br /> <br /> - Also limit the y1 (Daniel)<br /> - keep fix patch it to minimal (Daniel)<br /> - screen_size is page size aligned because of it need mmap (Thomas)<br /> - Adding fixes tag (Thomas)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/dcssblk: fix kernel crash with list_add corruption<br /> <br /> Commit fb08a1908cb1 ("dax: simplify the dax_device gendisk<br /> association") introduced new logic for gendisk association, requiring<br /> drivers to explicitly call dax_add_host() and dax_remove_host().<br /> <br /> For dcssblk driver, some dax_remove_host() calls were missing, e.g. in<br /> device remove path. The commit also broke error handling for out_dax case<br /> in device add path, resulting in an extra put_device() w/o the previous<br /> get_device() in that case.<br /> <br /> This lead to stale xarray entries after device add / remove cycles. In the<br /> case when a previously used struct gendisk pointer (xarray index) would be<br /> used again, because blk_alloc_disk() happened to return such a pointer, the<br /> xa_insert() in dax_add_host() would fail and go to out_dax, doing the extra<br /> put_device() in the error path. In combination with an already flawed error<br /> handling in dcssblk (device_register() cleanup), which needs to be<br /> addressed in a separate patch, this resulted in a missing device_del() /<br /> klist_del(), and eventually in the kernel crash with list_add corruption on<br /> a subsequent device_add() / klist_add().<br /> <br /> Fix this by adding the missing dax_remove_host() calls, and also move the<br /> put_device() in the error path to restore the previous logic.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: sc16is7xx: setup GPIO controller later in probe<br /> <br /> The GPIO controller component of the sc16is7xx driver is setup too<br /> early, which can result in a race condition where another device tries<br /> to utilise the GPIO lines before the sc16is7xx device has finished<br /> initialising.<br /> <br /> This issue manifests itself as an Oops when the GPIO lines are configured:<br /> <br /> Unable to handle kernel read from unreadable memory at virtual address<br /> ...<br /> pc : sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx]<br /> lr : sc16is7xx_gpio_direction_output+0x4c/0x108 [sc16is7xx]<br /> ...<br /> Call trace:<br /> sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx]<br /> gpiod_direction_output_raw_commit+0x64/0x318<br /> gpiod_direction_output+0xb0/0x170<br /> create_gpio_led+0xec/0x198<br /> gpio_led_probe+0x16c/0x4f0<br /> platform_drv_probe+0x5c/0xb0<br /> really_probe+0xe8/0x448<br /> driver_probe_device+0xe8/0x138<br /> __device_attach_driver+0x94/0x118<br /> bus_for_each_drv+0x8c/0xe0<br /> __device_attach+0x100/0x1b8<br /> device_initial_probe+0x28/0x38<br /> bus_probe_device+0xa4/0xb0<br /> deferred_probe_work_func+0x90/0xe0<br /> process_one_work+0x1c4/0x480<br /> worker_thread+0x54/0x430<br /> kthread+0x138/0x150<br /> ret_from_fork+0x10/0x1c<br /> <br /> This patch moves the setup of the GPIO controller functions to later in the<br /> probe function, ensuring the sc16is7xx device has already finished<br /> initialising by the time other devices try to make use of the GPIO lines.<br /> The error handling has also been reordered to reflect the new<br /> initialisation order.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> inotify: Avoid reporting event with invalid wd<br /> <br /> When inotify_freeing_mark() races with inotify_handle_inode_event() it<br /> can happen that inotify_handle_inode_event() sees that i_mark-&gt;wd got<br /> already reset to -1 and reports this value to userspace which can<br /> confuse the inotify listener. Avoid the problem by validating that wd is<br /> sensible (and pretend the mark got removed before the event got<br /> generated otherwise).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix race condition in hidp_session_thread<br /> <br /> There is a potential race condition in hidp_session_thread that may<br /> lead to use-after-free. For instance, the timer is active while<br /> hidp_del_timer is called in hidp_session_thread(). After hidp_session_put,<br /> then &amp;#39;session&amp;#39; will be freed, causing kernel panic when hidp_idle_timeout<br /> is running.<br /> <br /> The solution is to use del_timer_sync instead of del_timer.<br /> <br /> Here is the call trace:<br /> <br /> ? hidp_session_probe+0x780/0x780<br /> call_timer_fn+0x2d/0x1e0<br /> __run_timers.part.0+0x569/0x940<br /> hidp_session_probe+0x780/0x780<br /> call_timer_fn+0x1e0/0x1e0<br /> ktime_get+0x5c/0xf0<br /> lapic_next_deadline+0x2c/0x40<br /> clockevents_program_event+0x205/0x320<br /> run_timer_softirq+0xa9/0x1b0<br /> __do_softirq+0x1b9/0x641<br /> __irq_exit_rcu+0xdc/0x190<br /> irq_exit_rcu+0xe/0x20<br /> sysvec_apic_timer_interrupt+0xa1/0xc0

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Prevent lpfc_debugfs_lockstat_write() buffer overflow<br /> <br /> A static code analysis tool flagged the possibility of buffer overflow when<br /> using copy_from_user() for a debugfs entry.<br /> <br /> Currently, it is possible that copy_from_user() copies more bytes than what<br /> would fit in the mybuf char array. Add a min() restriction check between<br /> sizeof(mybuf) - 1 and nbytes passed from the userspace buffer to protect<br /> against buffer overflow.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: rawnand: fsl_upm: Fix an off-by one test in fun_exec_op()<br /> <br /> &amp;#39;op-cs&amp;#39; is copied in &amp;#39;fun-&gt;mchip_number&amp;#39; which is used to access the<br /> &amp;#39;mchip_offsets&amp;#39; and the &amp;#39;rnb_gpio&amp;#39; arrays.<br /> These arrays have NAND_MAX_CHIPS elements, so the index must be below this<br /> limit.<br /> <br /> Fix the sanity check in order to avoid the NAND_MAX_CHIPS value. This<br /> would lead to out-of-bound accesses.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: isotp: check CAN address family in isotp_bind()<br /> <br /> Add missing check to block non-AF_CAN binds.<br /> <br /> Syzbot created some code which matched the right sockaddr struct size<br /> but used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address family<br /> field:<br /> <br /> bind$xdp(r2, &amp;(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10)<br /> ^^^^<br /> This has no funtional impact but the userspace should be notified about<br /> the wrong address family field content.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: fix potential memory leak in mlx5e_init_rep_rx<br /> <br /> The memory pointed to by the priv-&gt;rx_res pointer is not freed in the error<br /> path of mlx5e_init_rep_rx, which can lead to a memory leak. Fix by freeing<br /> the memory in the error path, thereby making the error path identical to<br /> mlx5e_cleanup_rep_rx().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-cgroup: dropping parent refcount after pd_free_fn() is done<br /> <br /> Some cgroup policies will access parent pd through child pd even<br /> after pd_offline_fn() is done. If pd_free_fn() for parent is called<br /> before child, then UAF can be triggered. Hence it&amp;#39;s better to guarantee<br /> the order of pd_free_fn().<br /> <br /> Currently refcount of parent blkg is dropped in __blkg_release(), which<br /> is before pd_free_fn() is called in blkg_free_work_fn() while<br /> blkg_free_work_fn() is called asynchronously.<br /> <br /> This patch make sure pd_free_fn() called from removing cgroup is ordered<br /> by delaying dropping parent refcount after calling pd_free_fn() for<br /> child.<br /> <br /> BTW, pd_free_fn() will also be called from blkcg_deactivate_policy()<br /> from deleting device, and following patches will guarantee the order.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix DMA-API call trace on NVMe LS requests<br /> <br /> The following message and call trace was seen with debug kernels:<br /> <br /> DMA-API: qla2xxx 0000:41:00.0: device driver failed to check map<br /> error [device address=0x00000002a3ff38d8] [size=1024 bytes] [mapped as<br /> single]<br /> WARNING: CPU: 0 PID: 2930 at kernel/dma/debug.c:1017<br /> check_unmap+0xf42/0x1990<br /> <br /> Call Trace:<br /> debug_dma_unmap_page+0xc9/0x100<br /> qla_nvme_ls_unmap+0x141/0x210 [qla2xxx]<br /> <br /> Remove DMA mapping from the driver altogether, as it is already done by FC<br /> layer. This prevents the warning.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rcar_fdp1: Fix refcount leak in probe and remove function<br /> <br /> rcar_fcp_get() take reference, which should be balanced with<br /> rcar_fcp_put(). Add missing rcar_fcp_put() in fdp1_remove and<br /> the error paths of fdp1_probe() to fix this.<br /> <br /> [hverkuil: resolve merge conflict, remove() is now void]