Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path<br /> <br /> When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after<br /> failing to attach the region to an ACL group, we hit a NULL pointer<br /> dereference upon &amp;#39;region-&gt;group-&gt;tcam&amp;#39; [1].<br /> <br /> Fix by retrieving the &amp;#39;tcam&amp;#39; pointer using mlxsw_sp_acl_to_tcam().<br /> <br /> [1]<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [...]<br /> RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0<br /> [...]<br /> Call Trace:<br /> mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20<br /> mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0<br /> mlxsw_sp_acl_rule_add+0x47/0x240<br /> mlxsw_sp_flower_replace+0x1a9/0x1d0<br /> tc_setup_cb_add+0xdc/0x1c0<br /> fl_hw_replace_filter+0x146/0x1f0<br /> fl_change+0xc17/0x1360<br /> tc_new_tfilter+0x472/0xb90<br /> rtnetlink_rcv_msg+0x313/0x3b0<br /> netlink_rcv_skb+0x58/0x100<br /> netlink_unicast+0x244/0x390<br /> netlink_sendmsg+0x1e4/0x440<br /> ____sys_sendmsg+0x164/0x260<br /> ___sys_sendmsg+0x9a/0xe0<br /> __sys_sendmsg+0x7a/0xc0<br /> do_syscall_64+0x40/0xe0<br /> entry_SYSCALL_64_after_hwframe+0x63/0x6b

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hisi_acc_vfio_pci: Update migration data pointer correctly on saving/resume<br /> <br /> When the optional PRE_COPY support was added to speed up the device<br /> compatibility check, it failed to update the saving/resuming data<br /> pointers based on the fd offset. This results in migration data<br /> corruption and when the device gets started on the destination the<br /> following error is reported in some cases,<br /> <br /> [ 478.907684] arm-smmu-v3 arm-smmu-v3.2.auto: event 0x10 received:<br /> [ 478.913691] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000310200000010<br /> [ 478.919603] arm-smmu-v3 arm-smmu-v3.2.auto: 0x000002088000007f<br /> [ 478.925515] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000000000000000<br /> [ 478.931425] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000000000000000<br /> [ 478.947552] hisi_zip 0000:31:00.0: qm_axi_rresp [error status=0x1] found<br /> [ 478.955930] hisi_zip 0000:31:00.0: qm_db_timeout [error status=0x400] found<br /> [ 478.955944] hisi_zip 0000:31:00.0: qm sq doorbell timeout in function 2

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length<br /> <br /> If the host sends an H2CData command with an invalid DATAL,<br /> the kernel may crash in nvmet_tcp_build_pdu_iovec().<br /> <br /> Unable to handle kernel NULL pointer dereference at<br /> virtual address 0000000000000000<br /> lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp]<br /> Call trace:<br /> process_one_work+0x174/0x3c8<br /> worker_thread+0x2d0/0x3e8<br /> kthread+0x104/0x110<br /> <br /> Fix the bug by raising a fatal error if DATAL isn&amp;#39;t coherent<br /> with the packet size.<br /> Also, the PDU length should never exceed the MAXH2CDATA parameter which<br /> has been communicated to the host in nvmet_tcp_handle_icreq().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Don&amp;#39;t reserve 0-length IOVA region<br /> <br /> When the bootloader/firmware doesn&amp;#39;t setup the framebuffers, their<br /> address and size are 0 in "iommu-addresses" property. If IOVA region is<br /> reserved with 0 length, then it ends up corrupting the IOVA rbtree with<br /> an entry which has pfn_hi

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: imx: fix tx statemachine deadlock<br /> <br /> When using the serial port as RS485 port, the tx statemachine is used to<br /> control the RTS pin to drive the RS485 transceiver TX_EN pin. When the<br /> TTY port is closed in the middle of a transmission (for instance during<br /> userland application crash), imx_uart_shutdown disables the interface<br /> and disables the Transmission Complete interrupt. afer that,<br /> imx_uart_stop_tx bails on an incomplete transmission, to be retriggered<br /> by the TC interrupt. This interrupt is disabled and therefore the tx<br /> statemachine never transitions out of SEND. The statemachine is in<br /> deadlock now, and the TX_EN remains low, making the interface useless.<br /> <br /> imx_uart_stop_tx now checks for incomplete transmission AND whether TC<br /> interrupts are enabled before bailing to be retriggered. This makes sure<br /> the state machine handling is reached, and is properly set to<br /> WAIT_AFTER_SEND.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250: omap: Don&amp;#39;t skip resource freeing if pm_runtime_resume_and_get() failed<br /> <br /> Returning an error code from .remove() makes the driver core emit the<br /> little helpful error message:<br /> <br /> remove callback returned a non-zero value. This will be ignored.<br /> <br /> and then remove the device anyhow. So all resources that were not freed<br /> are leaked in this case. Skipping serial8250_unregister_port() has the<br /> potential to keep enough of the UART around to trigger a use-after-free.<br /> <br /> So replace the error return (and with it the little helpful error<br /> message) by a more useful error message and continue to cleanup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: add check that partition length needs to be aligned with block size<br /> <br /> Before calling add partition or resize partition, there is no check<br /> on whether the length is aligned with the logical block size.<br /> If the logical block size of the disk is larger than 512 bytes,<br /> then the partition size maybe not the multiple of the logical block size,<br /> and when the last sector is read, bio_truncate() will adjust the bio size,<br /> resulting in an IO error if the size of the read command is smaller than<br /> the logical block size.If integrity data is supported, this will also<br /> result in a null pointer dereference when calling bio_integrity_free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: v4l: async: Fix duplicated list deletion<br /> <br /> The list deletion call dropped here is already called from the<br /> helper function in the line before. Having a second list_del()<br /> call results in either a warning (with CONFIG_DEBUG_LIST=y):<br /> <br /> list_del corruption, c46c8198-&gt;next is LIST_POISON1 (00000100)<br /> <br /> If CONFIG_DEBUG_LIST is disabled the operation results in a<br /> kernel error due to NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix NULL pointer dereference at hibernate<br /> <br /> During hibernate sequence the source context might not have a clk_mgr.<br /> So don&amp;#39;t use it to look for DML2 support.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sched: Fix bounds limiting when given a malformed entity<br /> <br /> If we&amp;#39;re given a malformed entity in drm_sched_entity_init()--shouldn&amp;#39;t<br /> happen, but we verify--with out-of-bounds priority value, we set it to an<br /> allowed value. Fix the expression which sets this limit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: fix check for attempt to corrupt spilled pointer<br /> <br /> When register is spilled onto a stack as a 1/2/4-byte register, we set<br /> slot_type[BPF_REG_SIZE - 1] (plus potentially few more below it,<br /> depending on actual spill size). So to check if some stack slot has<br /> spilled register we need to consult slot_type[7], not slot_type[0].<br /> <br /> To avoid the need to remember and double-check this in the future, just<br /> use is_spilled_reg() helper.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efivarfs: force RO when remounting if SetVariable is not supported<br /> <br /> If SetVariable at runtime is not supported by the firmware we never assign<br /> a callback for that function. At the same time mount the efivarfs as<br /> RO so no one can call that. However, we never check the permission flags<br /> when someone remounts the filesystem as RW. As a result this leads to a<br /> crash looking like this:<br /> <br /> $ mount -o remount,rw /sys/firmware/efi/efivars<br /> $ efi-updatevar -f PK.auth PK<br /> <br /> [ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [ 303.280482] Mem abort info:<br /> [ 303.280854] ESR = 0x0000000086000004<br /> [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits<br /> [ 303.282016] SET = 0, FnV = 0<br /> [ 303.282414] EA = 0, S1PTW = 0<br /> [ 303.282821] FSC = 0x04: level 0 translation fault<br /> [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000<br /> [ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000<br /> [ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP<br /> [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6<br /> [ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1<br /> [ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023<br /> [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 303.292123] pc : 0x0<br /> [ 303.292443] lr : efivar_set_variable_locked+0x74/0xec<br /> [ 303.293156] sp : ffff800008673c10<br /> [ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000<br /> [ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027<br /> [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000<br /> [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000<br /> [ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54<br /> [ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4<br /> [ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002<br /> [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201<br /> [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc<br /> [ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000<br /> [ 303.303341] Call trace:<br /> [ 303.303679] 0x0<br /> [ 303.303938] efivar_entry_set_get_size+0x98/0x16c<br /> [ 303.304585] efivarfs_file_write+0xd0/0x1a4<br /> [ 303.305148] vfs_write+0xc4/0x2e4<br /> [ 303.305601] ksys_write+0x70/0x104<br /> [ 303.306073] __arm64_sys_write+0x1c/0x28<br /> [ 303.306622] invoke_syscall+0x48/0x114<br /> [ 303.307156] el0_svc_common.constprop.0+0x44/0xec<br /> [ 303.307803] do_el0_svc+0x38/0x98<br /> [ 303.308268] el0_svc+0x2c/0x84<br /> [ 303.308702] el0t_64_sync_handler+0xf4/0x120<br /> [ 303.309293] el0t_64_sync+0x190/0x194<br /> [ 303.309794] Code: ???????? ???????? ???????? ???????? (????????)<br /> [ 303.310612] ---[ end trace 0000000000000000 ]---<br /> <br /> Fix this by adding a .reconfigure() function to the fs operations which<br /> we can use to check the requested flags and deny anything that&amp;#39;s not RO<br /> if the firmware doesn&amp;#39;t implement SetVariable at runtime.