Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: fix workqueue leak on bind errors<br /> <br /> Make sure to destroy the workqueue also in case of early errors during<br /> bind (e.g. a subcomponent failing to bind).<br /> <br /> Since commit c3b790ea07a1 ("drm: Manage drm_mode_config_init with<br /> drmm_") the mode config will be freed when the drm device is released<br /> also when using the legacy interface, but add an explicit cleanup for<br /> consistency and to facilitate backporting.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/525093/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iavf: use internal state to free traffic IRQs<br /> <br /> If the system tries to close the netdev while iavf_reset_task() is<br /> running, __LINK_STATE_START will be cleared and netif_running() will<br /> return false in iavf_reinit_interrupt_scheme(). This will result in<br /> iavf_free_traffic_irqs() not being called and a leak as follows:<br /> <br /> [7632.489326] remove_proc_entry: removing non-empty directory &amp;#39;irq/999&amp;#39;, leaking at least &amp;#39;iavf-enp24s0f0v0-TxRx-0&amp;#39;<br /> [7632.490214] WARNING: CPU: 0 PID: 10 at fs/proc/generic.c:718 remove_proc_entry+0x19b/0x1b0<br /> <br /> is shown when pci_disable_msix() is later called. Fix by using the<br /> internal adapter state. The traffic IRQs will always exist if<br /> state == __IAVF_RUNNING.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dp: Drop aux devices together with DP controller<br /> <br /> Using devres to depopulate the aux bus made sure that upon a probe<br /> deferral the EDP panel device would be destroyed and recreated upon next<br /> attempt.<br /> <br /> But the struct device which the devres is tied to is the DPUs<br /> (drm_dev-&gt;dev), which may be happen after the DP controller is torn<br /> down.<br /> <br /> Indications of this can be seen in the commonly seen EDID-hexdump full<br /> of zeros in the log, or the occasional/rare KASAN fault where the<br /> panel&amp;#39;s attempt to read the EDID information causes a use after free on<br /> DP resources.<br /> <br /> It&amp;#39;s tempting to move the devres to the DP controller&amp;#39;s struct device,<br /> but the resources used by the device(s) on the aux bus are explicitly<br /> torn down in the error path. The KASAN-reported use-after-free also<br /> remains, as the DP aux "module" explicitly frees its devres-allocated<br /> memory in this code path.<br /> <br /> As such, explicitly depopulate the aux bus in the error path, and in the<br /> component unbind path, to avoid these issues.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/542163/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-core: fix memory leak in dhchap_secret_store<br /> <br /> Free dhchap_secret in nvme_ctrl_dhchap_secret_store() before we return<br /> fix following kmemleack:-<br /> <br /> unreferenced object 0xffff8886376ea800 (size 64):<br /> comm "check", pid 22048, jiffies 4344316705 (age 92.199s)<br /> hex dump (first 32 bytes):<br /> 44 48 48 43 2d 31 3a 30 30 3a 6e 78 72 35 4b 67 DHHC-1:00:nxr5Kg<br /> 75 58 34 75 6f 41 78 73 4a 61 34 63 2f 68 75 4c uX4uoAxsJa4c/huL<br /> backtrace:<br /> [] __kmalloc+0x4b/0x130<br /> [] nvme_ctrl_dhchap_secret_store+0x8f/0x160 [nvme_core]<br /> [] kernfs_fop_write_iter+0x12b/0x1c0<br /> [] vfs_write+0x2ba/0x3c0<br /> [] ksys_write+0x5f/0xe0<br /> [] do_syscall_64+0x3b/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> unreferenced object 0xffff8886376eaf00 (size 64):<br /> comm "check", pid 22048, jiffies 4344316736 (age 92.168s)<br /> hex dump (first 32 bytes):<br /> 44 48 48 43 2d 31 3a 30 30 3a 6e 78 72 35 4b 67 DHHC-1:00:nxr5Kg<br /> 75 58 34 75 6f 41 78 73 4a 61 34 63 2f 68 75 4c uX4uoAxsJa4c/huL<br /> backtrace:<br /> [] __kmalloc+0x4b/0x130<br /> [] nvme_ctrl_dhchap_secret_store+0x8f/0x160 [nvme_core]<br /> [] kernfs_fop_write_iter+0x12b/0x1c0<br /> [] vfs_write+0x2ba/0x3c0<br /> [] ksys_write+0x5f/0xe0<br /> [] do_syscall_64+0x3b/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x72/0xdc

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netlink: annotate accesses to nlk-&gt;cb_running<br /> <br /> Both netlink_recvmsg() and netlink_native_seq_show() read<br /> nlk-&gt;cb_running locklessly. Use READ_ONCE() there.<br /> <br /> Add corresponding WRITE_ONCE() to netlink_dump() and<br /> __netlink_dump_start()<br /> <br /> syzbot reported:<br /> BUG: KCSAN: data-race in __netlink_dump_start / netlink_recvmsg<br /> <br /> write to 0xffff88813ea4db59 of 1 bytes by task 28219 on cpu 0:<br /> __netlink_dump_start+0x3af/0x4d0 net/netlink/af_netlink.c:2399<br /> netlink_dump_start include/linux/netlink.h:308 [inline]<br /> rtnetlink_rcv_msg+0x70f/0x8c0 net/core/rtnetlink.c:6130<br /> netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2577<br /> rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6192<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]<br /> netlink_unicast+0x56f/0x640 net/netlink/af_netlink.c:1365<br /> netlink_sendmsg+0x665/0x770 net/netlink/af_netlink.c:1942<br /> sock_sendmsg_nosec net/socket.c:724 [inline]<br /> sock_sendmsg net/socket.c:747 [inline]<br /> sock_write_iter+0x1aa/0x230 net/socket.c:1138<br /> call_write_iter include/linux/fs.h:1851 [inline]<br /> new_sync_write fs/read_write.c:491 [inline]<br /> vfs_write+0x463/0x760 fs/read_write.c:584<br /> ksys_write+0xeb/0x1a0 fs/read_write.c:637<br /> __do_sys_write fs/read_write.c:649 [inline]<br /> __se_sys_write fs/read_write.c:646 [inline]<br /> __x64_sys_write+0x42/0x50 fs/read_write.c:646<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> read to 0xffff88813ea4db59 of 1 bytes by task 28222 on cpu 1:<br /> netlink_recvmsg+0x3b4/0x730 net/netlink/af_netlink.c:2022<br /> sock_recvmsg_nosec+0x4c/0x80 net/socket.c:1017<br /> ____sys_recvmsg+0x2db/0x310 net/socket.c:2718<br /> ___sys_recvmsg net/socket.c:2762 [inline]<br /> do_recvmmsg+0x2e5/0x710 net/socket.c:2856<br /> __sys_recvmmsg net/socket.c:2935 [inline]<br /> __do_sys_recvmmsg net/socket.c:2958 [inline]<br /> __se_sys_recvmmsg net/socket.c:2951 [inline]<br /> __x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> value changed: 0x00 -&gt; 0x01

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> devlink: report devlink_port_type_warn source device<br /> <br /> devlink_port_type_warn is scheduled for port devlink and warning<br /> when the port type is not set. But from this warning it is not easy<br /> found out which device (driver) has no devlink port set.<br /> <br /> [ 3709.975552] Type was not set for devlink port.<br /> [ 3709.975579] WARNING: CPU: 1 PID: 13092 at net/devlink/leftover.c:6775 devlink_port_type_warn+0x11/0x20<br /> [ 3709.993967] Modules linked in: openvswitch nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nfnetlink bluetooth rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs vhost_net vhost vhost_iotlb tap tun bridge stp llc qrtr intel_rapl_msr intel_rapl_common i10nm_edac nfit libnvdimm x86_pkg_temp_thermal mlx5_ib intel_powerclamp coretemp dell_wmi ledtrig_audio sparse_keymap ipmi_ssif kvm_intel ib_uverbs rfkill ib_core video kvm iTCO_wdt acpi_ipmi intel_vsec irqbypass ipmi_si iTCO_vendor_support dcdbas ipmi_devintf mei_me ipmi_msghandler rapl mei intel_cstate isst_if_mmio isst_if_mbox_pci dell_smbios intel_uncore isst_if_common i2c_i801 dell_wmi_descriptor wmi_bmof i2c_smbus intel_pch_thermal pcspkr acpi_power_meter xfs libcrc32c sd_mod sg nvme_tcp mgag200 i2c_algo_bit nvme_fabrics drm_shmem_helper drm_kms_helper nvme syscopyarea ahci sysfillrect sysimgblt nvme_core fb_sys_fops crct10dif_pclmul libahci mlx5_core sfc crc32_pclmul nvme_common drm<br /> [ 3709.994030] crc32c_intel mtd t10_pi mlxfw libata tg3 mdio megaraid_sas psample ghash_clmulni_intel pci_hyperv_intf wmi dm_multipath sunrpc dm_mirror dm_region_hash dm_log dm_mod be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse<br /> [ 3710.108431] CPU: 1 PID: 13092 Comm: kworker/1:1 Kdump: loaded Not tainted 5.14.0-319.el9.x86_64 #1<br /> [ 3710.108435] Hardware name: Dell Inc. PowerEdge R750/0PJ80M, BIOS 1.8.2 09/14/2022<br /> [ 3710.108437] Workqueue: events devlink_port_type_warn<br /> [ 3710.108440] RIP: 0010:devlink_port_type_warn+0x11/0x20<br /> [ 3710.108443] Code: 84 76 fe ff ff 48 c7 03 20 0e 1a ad 31 c0 e9 96 fd ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 48 c7 c7 18 24 4e ad e8 ef 71 62 ff 0b c3 cc cc cc cc 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f6 87<br /> [ 3710.108445] RSP: 0018:ff3b6d2e8b3c7e90 EFLAGS: 00010282<br /> [ 3710.108447] RAX: 0000000000000000 RBX: ff366d6580127080 RCX: 0000000000000027<br /> [ 3710.108448] RDX: 0000000000000027 RSI: 00000000ffff86de RDI: ff366d753f41f8c8<br /> [ 3710.108449] RBP: ff366d658ff5a0c0 R08: ff366d753f41f8c0 R09: ff3b6d2e8b3c7e18<br /> [ 3710.108450] R10: 0000000000000001 R11: 0000000000000023 R12: ff366d753f430600<br /> [ 3710.108451] R13: ff366d753f436900 R14: 0000000000000000 R15: ff366d753f436905<br /> [ 3710.108452] FS: 0000000000000000(0000) GS:ff366d753f400000(0000) knlGS:0000000000000000<br /> [ 3710.108453] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 3710.108454] CR2: 00007f1c57bc74e0 CR3: 000000111d26a001 CR4: 0000000000773ee0<br /> [ 3710.108456] PKRU: 55555554<br /> [ 3710.108457] Call Trace:<br /> [ 3710.108458] <br /> [ 3710.108459] process_one_work+0x1e2/0x3b0<br /> [ 3710.108466] ? rescuer_thread+0x390/0x390<br /> [ 3710.108468] worker_thread+0x50/0x3a0<br /> [ 3710.108471] ? rescuer_thread+0x390/0x390<br /> [ 3710.108473] kthread+0xdd/0x100<br /> [ 3710.108477] ? kthread_complete_and_exit+0x20/0x20<br /> [ 3710.108479] ret_from_fork+0x1f/0x30<br /> [ 3710.108485] <br /> [ 3710.108486] ---[ end trace 1b4b23cd0c65d6a0 ]---<br /> <br /> After patch:<br /> [ 402.473064] ice 0000:41:00.0: Type was not set for devlink port.<br /> [ 402.473064] ice 0000:41:00.1: Type was not set for devlink port.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codecs: wcd-mbhc-v2: fix resource leaks on component remove<br /> <br /> The MBHC resources must be released on component probe failure and<br /> removal so can not be tied to the lifetime of the component device.<br /> <br /> This is specifically needed to allow probe deferrals of the sound card<br /> which otherwise fails when reprobing the codec component:<br /> <br /> snd-sc8280xp sound: ASoC: failed to instantiate card -517<br /> genirq: Flags mismatch irq 299. 00002001 (mbhc sw intr) vs. 00002001 (mbhc sw intr)<br /> wcd938x_codec audio-codec: Failed to request mbhc interrupts -16<br /> wcd938x_codec audio-codec: mbhc initialization failed<br /> wcd938x_codec audio-codec: ASoC: error at snd_soc_component_probe on audio-codec: -16<br /> snd-sc8280xp sound: ASoC: failed to instantiate card -16

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: reject negative ifindex<br /> <br /> Recent changes in net-next (commit 759ab1edb56c ("net: store netdevs<br /> in an xarray")) refactored the handling of pre-assigned ifindexes<br /> and let syzbot surface a latent problem in ovs. ovs does not validate<br /> ifindex, making it possible to create netdev ports with negative<br /> ifindex values. It&amp;#39;s easy to repro with YNL:<br /> <br /> $ ./cli.py --spec netlink/specs/ovs_datapath.yaml \<br /> --do new \<br /> --json &amp;#39;{"upcall-pid": 1, "name":"my-dp"}&amp;#39;<br /> $ ./cli.py --spec netlink/specs/ovs_vport.yaml \<br /> --do new \<br /> --json &amp;#39;{"upcall-pid": "00000001", "name": "some-port0", "dp-ifindex":3,"ifindex":4294901760,"type":2}&amp;#39;<br /> <br /> $ ip link show<br /> -65536: some-port0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000<br /> link/ether 7a:48:21:ad:0b:fb brd ff:ff:ff:ff:ff:ff<br /> ...<br /> <br /> Validate the inputs. Now the second command correctly returns:<br /> <br /> $ ./cli.py --spec netlink/specs/ovs_vport.yaml \<br /> --do new \<br /> --json &amp;#39;{"upcall-pid": "00000001", "name": "some-port0", "dp-ifindex":3,"ifindex":4294901760,"type":2}&amp;#39;<br /> <br /> lib.ynl.NlError: Netlink error: Numerical result out of range<br /> nl_len = 108 (92) nl_flags = 0x300 nl_type = 2<br /> error: -34 extack: {&amp;#39;msg&amp;#39;: &amp;#39;integer out of range&amp;#39;, &amp;#39;unknown&amp;#39;: [[type:4 len:36] b&amp;#39;\x0c\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0c\x00\x03\x00\xff\xff\xff\x7f\x00\x00\x00\x00\x08\x00\x01\x00\x08\x00\x00\x00&amp;#39;], &amp;#39;bad-attr&amp;#39;: &amp;#39;.ifindex&amp;#39;}<br /> <br /> Accept 0 since it used to be silently ignored.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ttm: Don&amp;#39;t leak a resource on swapout move error<br /> <br /> If moving the bo to system for swapout failed, we were leaking<br /> a resource. Fix.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix infinite loop in nilfs_mdt_get_block()<br /> <br /> If the disk image that nilfs2 mounts is corrupted and a virtual block<br /> address obtained by block lookup for a metadata file is invalid,<br /> nilfs_bmap_lookup_at_level() may return the same internal return code as<br /> -ENOENT, meaning the block does not exist in the metadata file.<br /> <br /> This duplication of return codes confuses nilfs_mdt_get_block(), causing<br /> it to read and create a metadata block indefinitely.<br /> <br /> In particular, if this happens to the inode metadata file, ifile,<br /> semaphore i_rwsem can be left held, causing task hangs in lock_mount.<br /> <br /> Fix this issue by making nilfs_bmap_lookup_at_level() treat virtual block<br /> address translation failures with -ENOENT as metadata corruption instead<br /> of returning the error code.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: fix NULL-deref on snapshot tear down<br /> <br /> In case of early initialisation errors and on platforms that do not use<br /> the DPU controller, the deinitilisation code can be called with the kms<br /> pointer set to NULL.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/525099/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: synchronize atomic write aborts<br /> <br /> To fix a race condition between atomic write aborts, I use the inode<br /> lock and make COW inode to be re-usable thoroughout the whole<br /> atomic file inode lifetime.