Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/sseu: fix max_subslices array-index-out-of-bounds access<br /> <br /> It seems that commit bc3c5e0809ae ("drm/i915/sseu: Don&amp;#39;t try to store EU<br /> mask internally in UAPI format") exposed a potential out-of-bounds<br /> access, reported by UBSAN as following on a laptop with a gen 11 i915<br /> card:<br /> <br /> UBSAN: array-index-out-of-bounds in drivers/gpu/drm/i915/gt/intel_sseu.c:65:27<br /> index 6 is out of range for type &amp;#39;u16 [6]&amp;#39;<br /> CPU: 2 PID: 165 Comm: systemd-udevd Not tainted 6.2.0-9-generic #9-Ubuntu<br /> Hardware name: Dell Inc. XPS 13 9300/077Y9N, BIOS 1.11.0 03/22/2022<br /> Call Trace:<br /> <br /> show_stack+0x4e/0x61<br /> dump_stack_lvl+0x4a/0x6f<br /> dump_stack+0x10/0x18<br /> ubsan_epilogue+0x9/0x3a<br /> __ubsan_handle_out_of_bounds.cold+0x42/0x47<br /> gen11_compute_sseu_info+0x121/0x130 [i915]<br /> intel_sseu_info_init+0x15d/0x2b0 [i915]<br /> intel_gt_init_mmio+0x23/0x40 [i915]<br /> i915_driver_mmio_probe+0x129/0x400 [i915]<br /> ? intel_gt_probe_all+0x91/0x2e0 [i915]<br /> i915_driver_probe+0xe1/0x3f0 [i915]<br /> ? drm_privacy_screen_get+0x16d/0x190 [drm]<br /> ? acpi_dev_found+0x64/0x80<br /> i915_pci_probe+0xac/0x1b0 [i915]<br /> ...<br /> <br /> According to the definition of sseu_dev_info, eu_mask-&gt;hsw is limited to<br /> a maximum of GEN_MAX_SS_PER_HSW_SLICE (6) sub-slices, but<br /> gen11_sseu_info_init() can potentially set 8 sub-slices, in the<br /> !IS_JSL_EHL(gt-&gt;i915) case.<br /> <br /> Fix this by reserving up to 8 slots for max_subslices in the eu_mask<br /> struct.<br /> <br /> (cherry picked from commit 3cba09a6ac86ea1d456909626eb2685596c07822)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: nl80211: fix NULL-ptr deref in offchan check<br /> <br /> If, e.g. in AP mode, the link was already created by userspace<br /> but not activated yet, it has a chandef but the chandef isn&amp;#39;t<br /> valid and has no channel. Check for this and ignore this link.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix kernel crash during reboot when adapter is in recovery mode<br /> <br /> If the driver detects during probe that firmware is in recovery<br /> mode then i40e_init_recovery_mode() is called and the rest of<br /> probe function is skipped including pci_set_drvdata(). Subsequent<br /> i40e_shutdown() called during shutdown/reboot dereferences NULL<br /> pointer as pci_get_drvdata() returns NULL.<br /> <br /> To fix call pci_set_drvdata() also during entering to recovery mode.<br /> <br /> Reproducer:<br /> 1) Lets have i40e NIC with firmware in recovery mode<br /> 2) Run reboot<br /> <br /> Result:<br /> [ 139.084698] i40e: Intel(R) Ethernet Connection XL710 Network Driver<br /> [ 139.090959] i40e: Copyright (c) 2013 - 2019 Intel Corporation.<br /> [ 139.108438] i40e 0000:02:00.0: Firmware recovery mode detected. Limiting functionality.<br /> [ 139.116439] i40e 0000:02:00.0: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.<br /> [ 139.129499] i40e 0000:02:00.0: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]<br /> [ 139.215932] i40e 0000:02:00.0 enp2s0f0: renamed from eth0<br /> [ 139.223292] i40e 0000:02:00.1: Firmware recovery mode detected. Limiting functionality.<br /> [ 139.231292] i40e 0000:02:00.1: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.<br /> [ 139.244406] i40e 0000:02:00.1: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]<br /> [ 139.329209] i40e 0000:02:00.1 enp2s0f1: renamed from eth0<br /> ...<br /> [ 156.311376] BUG: kernel NULL pointer dereference, address: 00000000000006c2<br /> [ 156.318330] #PF: supervisor write access in kernel mode<br /> [ 156.323546] #PF: error_code(0x0002) - not-present page<br /> [ 156.328679] PGD 0 P4D 0<br /> [ 156.331210] Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> [ 156.335567] CPU: 26 PID: 15119 Comm: reboot Tainted: G E 6.2.0+ #1<br /> [ 156.343126] Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.4 04/13/2022<br /> [ 156.353369] RIP: 0010:i40e_shutdown+0x15/0x130 [i40e]<br /> [ 156.358430] Code: c1 fc ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 55 48 89 fd 53 48 8b 9f 48 01 00 00 80 8b c2 06 00 00 04 f0 80 8b c0 06 00 00 08 48 8d bb 08 08 00<br /> [ 156.377168] RSP: 0018:ffffb223c8447d90 EFLAGS: 00010282<br /> [ 156.382384] RAX: ffffffffc073ee70 RBX: 0000000000000000 RCX: 0000000000000001<br /> [ 156.389510] RDX: 0000000080000001 RSI: 0000000000000246 RDI: ffff95db49988000<br /> [ 156.396634] RBP: ffff95db49988000 R08: ffffffffffffffff R09: ffffffff8bd17d40<br /> [ 156.403759] R10: 0000000000000001 R11: ffffffff8a5e3d28 R12: ffff95db49988000<br /> [ 156.410882] R13: ffffffff89a6fe17 R14: ffff95db49988150 R15: 0000000000000000<br /> [ 156.418007] FS: 00007fe7c0cc3980(0000) GS:ffff95ea8ee80000(0000) knlGS:0000000000000000<br /> [ 156.426083] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 156.431819] CR2: 00000000000006c2 CR3: 00000003092fc005 CR4: 0000000000770ee0<br /> [ 156.438944] PKRU: 55555554<br /> [ 156.441647] Call Trace:<br /> [ 156.444096] <br /> [ 156.446199] pci_device_shutdown+0x38/0x60<br /> [ 156.450297] device_shutdown+0x163/0x210<br /> [ 156.454215] kernel_restart+0x12/0x70<br /> [ 156.457872] __do_sys_reboot+0x1ab/0x230<br /> [ 156.461789] ? vfs_writev+0xa6/0x1a0<br /> [ 156.465362] ? __pfx_file_free_rcu+0x10/0x10<br /> [ 156.469635] ? __call_rcu_common.constprop.85+0x109/0x5a0<br /> [ 156.475034] do_syscall_64+0x3e/0x90<br /> [ 156.478611] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> [ 156.483658] RIP: 0033:0x7fe7bff37ab7

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix memory leaks in mpi3mr_init_ioc()<br /> <br /> Don&amp;#39;t allocate memory again when IOC is being reinitialized.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: avoid potential UAF in nvmet_req_complete()<br /> <br /> An nvme target -&gt;queue_response() operation implementation may free the<br /> request passed as argument. Such implementation potentially could result<br /> in a use after free of the request pointer when percpu_ref_put() is<br /> called in nvmet_req_complete().<br /> <br /> Avoid such problem by using a local variable to save the sq pointer<br /> before calling __nvmet_req_complete(), thus avoiding dereferencing the<br /> req pointer after that function call.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: prevent out-of-bounds array speculation when closing a file descriptor<br /> <br /> Google-Bug-Id: 114199369

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Fix a procfs host directory removal regression<br /> <br /> scsi_proc_hostdir_rm() decreases a reference counter and hence must only be<br /> called once per host that is removed. This change does not require a<br /> scsi_add_host_with_dma() change since scsi_add_host_with_dma() will return<br /> 0 (success) if scsi_proc_host_add() is called.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: pn533: initialize struct pn533_out_arg properly<br /> <br /> struct pn533_out_arg used as a temporary context for out_urb is not<br /> initialized properly. Its uninitialized &amp;#39;phy&amp;#39; field can be dereferenced in<br /> error cases inside pn533_out_complete() callback function. It causes the<br /> following failure:<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.2.0-rc3-next-20230110-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> RIP: 0010:pn533_out_complete.cold+0x15/0x44 drivers/nfc/pn533/usb.c:441<br /> Call Trace:<br /> <br /> __usb_hcd_giveback_urb+0x2b6/0x5c0 drivers/usb/core/hcd.c:1671<br /> usb_hcd_giveback_urb+0x384/0x430 drivers/usb/core/hcd.c:1754<br /> dummy_timer+0x1203/0x32d0 drivers/usb/gadget/udc/dummy_hcd.c:1988<br /> call_timer_fn+0x1da/0x800 kernel/time/timer.c:1700<br /> expire_timers+0x234/0x330 kernel/time/timer.c:1751<br /> __run_timers kernel/time/timer.c:2022 [inline]<br /> __run_timers kernel/time/timer.c:1995 [inline]<br /> run_timer_softirq+0x326/0x910 kernel/time/timer.c:2035<br /> __do_softirq+0x1fb/0xaf6 kernel/softirq.c:571<br /> invoke_softirq kernel/softirq.c:445 [inline]<br /> __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650<br /> irq_exit_rcu+0x9/0x20 kernel/softirq.c:662<br /> sysvec_apic_timer_interrupt+0x97/0xc0 arch/x86/kernel/apic/apic.c:1107<br /> <br /> Initialize the field with the pn533_usb_phy currently used.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: zero i_disksize when initializing the bootloader inode<br /> <br /> If the boot loader inode has never been used before, the<br /> EXT4_IOC_SWAP_BOOT inode will initialize it, including setting the<br /> i_size to 0. However, if the "never before used" boot loader has a<br /> non-zero i_size, then i_disksize will be non-zero, and the<br /> inconsistency between i_size and i_disksize can trigger a kernel<br /> warning:<br /> <br /> WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319<br /> CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa<br /> RIP: 0010:ext4_file_write_iter+0xbc7/0xd10<br /> Call Trace:<br /> vfs_write+0x3b1/0x5c0<br /> ksys_write+0x77/0x160<br /> __x64_sys_write+0x22/0x30<br /> do_syscall_64+0x39/0x80<br /> <br /> Reproducer:<br /> 1. create corrupted image and mount it:<br /> mke2fs -t ext4 /tmp/foo.img 200<br /> debugfs -wR "sif size 25700" /tmp/foo.img<br /> mount -t ext4 /tmp/foo.img /mnt<br /> cd /mnt<br /> echo 123 &gt; file<br /> 2. Run the reproducer program:<br /> posix_memalign(&amp;buf, 1024, 1024)<br /> fd = open("file", O_RDWR | O_DIRECT);<br /> ioctl(fd, EXT4_IOC_SWAP_BOOT);<br /> write(fd, buf, 1024);<br /> <br /> Fix this by setting i_disksize as well as i_size to zero when<br /> initiaizing the boot loader inode.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: xsk: disable txq irq before flushing hw<br /> <br /> ice_qp_dis() intends to stop a given queue pair that is a target of xsk<br /> pool attach/detach. One of the steps is to disable interrupts on these<br /> queues. It currently is broken in a way that txq irq is turned off<br /> *after* HW flush which in turn takes no effect.<br /> <br /> ice_qp_dis():<br /> -&gt; ice_qvec_dis_irq()<br /> --&gt; disable rxq irq<br /> --&gt; flush hw<br /> -&gt; ice_vsi_stop_tx_ring()<br /> --&gt;disable txq irq<br /> <br /> Below splat can be triggered by following steps:<br /> - start xdpsock WITHOUT loading xdp prog<br /> - run xdp_rxq_info with XDP_TX action on this interface<br /> - start traffic<br /> - terminate xdpsock<br /> <br /> [ 256.312485] BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> [ 256.319560] #PF: supervisor read access in kernel mode<br /> [ 256.324775] #PF: error_code(0x0000) - not-present page<br /> [ 256.329994] PGD 0 P4D 0<br /> [ 256.332574] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 256.337006] CPU: 3 PID: 32 Comm: ksoftirqd/3 Tainted: G OE 6.2.0-rc5+ #51<br /> [ 256.345218] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019<br /> [ 256.355807] RIP: 0010:ice_clean_rx_irq_zc+0x9c/0x7d0 [ice]<br /> [ 256.361423] Code: b7 8f 8a 00 00 00 66 39 ca 0f 84 f1 04 00 00 49 8b 47 40 4c 8b 24 d0 41 0f b7 45 04 66 25 ff 3f 66 89 04 24 0f 84 85 02 00 00 8b 44 24 18 0f b7 14 24 48 05 00 01 00 00 49 89 04 24 49 89 44<br /> [ 256.380463] RSP: 0018:ffffc900088bfd20 EFLAGS: 00010206<br /> [ 256.385765] RAX: 000000000000003c RBX: 0000000000000035 RCX: 000000000000067f<br /> [ 256.393012] RDX: 0000000000000775 RSI: 0000000000000000 RDI: ffff8881deb3ac80<br /> [ 256.400256] RBP: 000000000000003c R08: ffff889847982710 R09: 0000000000010000<br /> [ 256.407500] R10: ffffffff82c060c0 R11: 0000000000000004 R12: 0000000000000000<br /> [ 256.414746] R13: ffff88811165eea0 R14: ffffc9000d255000 R15: ffff888119b37600<br /> [ 256.421990] FS: 0000000000000000(0000) GS:ffff8897e0cc0000(0000) knlGS:0000000000000000<br /> [ 256.430207] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 256.436036] CR2: 0000000000000018 CR3: 0000000005c0a006 CR4: 00000000007706e0<br /> [ 256.443283] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 256.450527] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 256.457770] PKRU: 55555554<br /> [ 256.460529] Call Trace:<br /> [ 256.463015] <br /> [ 256.465157] ? ice_xmit_zc+0x6e/0x150 [ice]<br /> [ 256.469437] ice_napi_poll+0x46d/0x680 [ice]<br /> [ 256.473815] ? _raw_spin_unlock_irqrestore+0x1b/0x40<br /> [ 256.478863] __napi_poll+0x29/0x160<br /> [ 256.482409] net_rx_action+0x136/0x260<br /> [ 256.486222] __do_softirq+0xe8/0x2e5<br /> [ 256.489853] ? smpboot_thread_fn+0x2c/0x270<br /> [ 256.494108] run_ksoftirqd+0x2a/0x50<br /> [ 256.497747] smpboot_thread_fn+0x1c1/0x270<br /> [ 256.501907] ? __pfx_smpboot_thread_fn+0x10/0x10<br /> [ 256.506594] kthread+0xea/0x120<br /> [ 256.509785] ? __pfx_kthread+0x10/0x10<br /> [ 256.513597] ret_from_fork+0x29/0x50<br /> [ 256.517238] <br /> <br /> In fact, irqs were not disabled and napi managed to be scheduled and run<br /> while xsk_pool pointer was still valid, but SW ring of xdp_buff pointers<br /> was already freed.<br /> <br /> To fix this, call ice_qvec_dis_irq() after ice_vsi_stop_tx_ring(). Also<br /> while at it, remove redundant ice_clean_rx_ring() call - this is handled<br /> in ice_qp_clean_rings().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: restore bond&amp;#39;s IFF_SLAVE flag if a non-eth dev enslave fails<br /> <br /> syzbot reported a warning[1] where the bond device itself is a slave and<br /> we try to enslave a non-ethernet device as the first slave which fails<br /> but then in the error path when ether_setup() restores the bond device<br /> it also clears all flags. In my previous fix[2] I restored the<br /> IFF_MASTER flag, but I didn&amp;#39;t consider the case that the bond device<br /> itself might also be a slave with IFF_SLAVE set, so we need to restore<br /> that flag as well. Use the bond_ether_setup helper which does the right<br /> thing and restores the bond&amp;#39;s flags properly.<br /> <br /> Steps to reproduce using a nlmon dev:<br /> $ ip l add nlmon0 type nlmon<br /> $ ip l add bond1 type bond<br /> $ ip l add bond2 type bond<br /> $ ip l set bond1 master bond2<br /> $ ip l set dev nlmon0 master bond1<br /> $ ip -d l sh dev bond1<br /> 22: bond1: mtu 1500 qdisc noqueue master bond2 state DOWN mode DEFAULT group default qlen 1000<br /> (now bond1&amp;#39;s IFF_SLAVE flag is gone and we&amp;#39;ll hit a warning[3] if we<br /> try to delete it)<br /> <br /> [1] https://syzkaller.appspot.com/bug?id=391c7b1f6522182899efba27d891f1743e8eb3ef<br /> [2] commit 7d5cd2ce5292 ("bonding: correctly handle bonding type change on enslave failure")<br /> [3] example warning:<br /> [ 27.008664] bond1: (slave nlmon0): The slave device specified does not support setting the MAC address<br /> [ 27.008692] bond1: (slave nlmon0): Error -95 calling set_mac_address<br /> [ 32.464639] bond1 (unregistering): Released all slaves<br /> [ 32.464685] ------------[ cut here ]------------<br /> [ 32.464686] WARNING: CPU: 1 PID: 2004 at net/core/dev.c:10829 unregister_netdevice_many+0x72a/0x780<br /> [ 32.464694] Modules linked in: br_netfilter bridge bonding virtio_net<br /> [ 32.464699] CPU: 1 PID: 2004 Comm: ip Kdump: loaded Not tainted 5.18.0-rc3+ #47<br /> [ 32.464703] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014<br /> [ 32.464704] RIP: 0010:unregister_netdevice_many+0x72a/0x780<br /> [ 32.464707] Code: 99 fd ff ff ba 90 1a 00 00 48 c7 c6 f4 02 66 96 48 c7 c7 20 4d 35 96 c6 05 fa c7 2b 02 01 e8 be 6f 4a 00 0f 0b e9 73 fd ff ff 0b e9 5f fd ff ff 80 3d e3 c7 2b 02 00 0f 85 3b fd ff ff ba 59<br /> [ 32.464710] RSP: 0018:ffffa006422d7820 EFLAGS: 00010206<br /> [ 32.464712] RAX: ffff8f6e077140a0 RBX: ffffa006422d7888 RCX: 0000000000000000<br /> [ 32.464714] RDX: ffff8f6e12edbe58 RSI: 0000000000000296 RDI: ffffffff96d4a520<br /> [ 32.464716] RBP: ffff8f6e07714000 R08: ffffffff96d63600 R09: ffffa006422d7728<br /> [ 32.464717] R10: 0000000000000ec0 R11: ffffffff9698c988 R12: ffff8f6e12edb140<br /> [ 32.464719] R13: dead000000000122 R14: dead000000000100 R15: ffff8f6e12edb140<br /> [ 32.464723] FS: 00007f297c2f1740(0000) GS:ffff8f6e5d900000(0000) knlGS:0000000000000000<br /> [ 32.464725] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 32.464726] CR2: 00007f297bf1c800 CR3: 00000000115e8000 CR4: 0000000000350ee0<br /> [ 32.464730] Call Trace:<br /> [ 32.464763] <br /> [ 32.464767] rtnl_dellink+0x13e/0x380<br /> [ 32.464776] ? cred_has_capability.isra.0+0x68/0x100<br /> [ 32.464780] ? __rtnl_unlock+0x33/0x60<br /> [ 32.464783] ? bpf_lsm_capset+0x10/0x10<br /> [ 32.464786] ? security_capable+0x36/0x50<br /> [ 32.464790] rtnetlink_rcv_msg+0x14e/0x3b0<br /> [ 32.464792] ? _copy_to_iter+0xb1/0x790<br /> [ 32.464796] ? post_alloc_hook+0xa0/0x160<br /> [ 32.464799] ? rtnl_calcit.isra.0+0x110/0x110<br /> [ 32.464802] netlink_rcv_skb+0x50/0xf0<br /> [ 32.464806] netlink_unicast+0x216/0x340<br /> [ 32.464809] netlink_sendmsg+0x23f/0x480<br /> [ 32.464812] sock_sendmsg+0x5e/0x60<br /> [ 32.464815] ____sys_sendmsg+0x22c/0x270<br /> [ 32.464818] ? import_iovec+0x17/0x20<br /> [ 32.464821] ? sendmsg_copy_msghdr+0x59/0x90<br /> [ 32.464823] ? do_set_pte+0xa0/0xe0<br /> [ 32.464828] ___sys_sendmsg+0x81/0xc0<br /> [ 32.464832] ? mod_objcg_state+0xc6/0x300<br /> [ 32.464835] ? refill_obj_stock+0xa9/0x160<br /> [ 32.464838] ? memcg_slab_free_hook+0x1a5/0x1f0<br /> [ 32.464842] __sys_sendm<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: smsc75xx: Move packet length check to prevent kernel panic in skb_pull<br /> <br /> Packet length check needs to be located after size and align_count<br /> calculation to prevent kernel panic in skb_pull() in case<br /> rx_cmd_a &amp; RX_CMD_A_RED evaluates to true.