Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: virtio: disable timeout handling<br /> <br /> If a timeout is hit, it can result is incorrect data on the I2C bus<br /> and/or memory corruptions in the guest since the device can still be<br /> operating on the buffers it was given while the guest has freed them.<br /> <br /> Here is, for example, the start of a slub_debug splat which was<br /> triggered on the next transfer after one transfer was forced to timeout<br /> by setting a breakpoint in the backend (rust-vmm/vhost-device):<br /> <br /> BUG kmalloc-1k (Not tainted): Poison overwritten<br /> First byte 0x1 instead of 0x6b<br /> Allocated in virtio_i2c_xfer+0x65/0x35c age=350 cpu=0 pid=29<br /> __kmalloc+0xc2/0x1c9<br /> virtio_i2c_xfer+0x65/0x35c<br /> __i2c_transfer+0x429/0x57d<br /> i2c_transfer+0x115/0x134<br /> i2cdev_ioctl_rdwr+0x16a/0x1de<br /> i2cdev_ioctl+0x247/0x2ed<br /> vfs_ioctl+0x21/0x30<br /> sys_ioctl+0xb18/0xb41<br /> Freed in virtio_i2c_xfer+0x32e/0x35c age=244 cpu=0 pid=29<br /> kfree+0x1bd/0x1cc<br /> virtio_i2c_xfer+0x32e/0x35c<br /> __i2c_transfer+0x429/0x57d<br /> i2c_transfer+0x115/0x134<br /> i2cdev_ioctl_rdwr+0x16a/0x1de<br /> i2cdev_ioctl+0x247/0x2ed<br /> vfs_ioctl+0x21/0x30<br /> sys_ioctl+0xb18/0xb41<br /> <br /> There is no simple fix for this (the driver would have to always create<br /> bounce buffers and hold on to them until the device eventually returns<br /> the buffers), so just disable the timeout support for now.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix vsi-&gt;txq_map sizing<br /> <br /> The approach of having XDP queue per CPU regardless of user&amp;#39;s setting<br /> exposed a hidden bug that could occur in case when Rx queue count differ<br /> from Tx queue count. Currently vsi-&gt;txq_map&amp;#39;s size is equal to the<br /> doubled vsi-&gt;alloc_txq, which is not correct due to the fact that XDP<br /> rings were previously based on the Rx queue count. Below splat can be<br /> seen when ethtool -L is used and XDP rings are configured:<br /> <br /> [ 682.875339] BUG: kernel NULL pointer dereference, address: 000000000000000f<br /> [ 682.883403] #PF: supervisor read access in kernel mode<br /> [ 682.889345] #PF: error_code(0x0000) - not-present page<br /> [ 682.895289] PGD 0 P4D 0<br /> [ 682.898218] Oops: 0000 [#1] PREEMPT SMP PTI<br /> [ 682.903055] CPU: 42 PID: 2878 Comm: ethtool Tainted: G OE 5.15.0-rc5+ #1<br /> [ 682.912214] Hardware name: Intel Corp. GRANTLEY/GRANTLEY, BIOS GRRFCRB1.86B.0276.D07.1605190235 05/19/2016<br /> [ 682.923380] RIP: 0010:devres_remove+0x44/0x130<br /> [ 682.928527] Code: 49 89 f4 55 48 89 fd 4c 89 ff 53 48 83 ec 10 e8 92 b9 49 00 48 8b 9d a8 02 00 00 48 8d 8d a0 02 00 00 49 89 c2 48 39 cb 74 0f 3b 63 10 74 25 48 8b 5b 08 48 39 cb 75 f1 4c 89 ff 4c 89 d6 e8<br /> [ 682.950237] RSP: 0018:ffffc90006a679f0 EFLAGS: 00010002<br /> [ 682.956285] RAX: 0000000000000286 RBX: ffffffffffffffff RCX: ffff88908343a370<br /> [ 682.964538] RDX: 0000000000000001 RSI: ffffffff81690d60 RDI: 0000000000000000<br /> [ 682.972789] RBP: ffff88908343a0d0 R08: 0000000000000000 R09: 0000000000000000<br /> [ 682.981040] R10: 0000000000000286 R11: 3fffffffffffffff R12: ffffffff81690d60<br /> [ 682.989282] R13: ffffffff81690a00 R14: ffff8890819807a8 R15: ffff88908343a36c<br /> [ 682.997535] FS: 00007f08c7bfa740(0000) GS:ffff88a03fd00000(0000) knlGS:0000000000000000<br /> [ 683.006910] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 683.013557] CR2: 000000000000000f CR3: 0000001080a66003 CR4: 00000000003706e0<br /> [ 683.021819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 683.030075] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 683.038336] Call Trace:<br /> [ 683.041167] devm_kfree+0x33/0x50<br /> [ 683.045004] ice_vsi_free_arrays+0x5e/0xc0 [ice]<br /> [ 683.050380] ice_vsi_rebuild+0x4c8/0x750 [ice]<br /> [ 683.055543] ice_vsi_recfg_qs+0x9a/0x110 [ice]<br /> [ 683.060697] ice_set_channels+0x14f/0x290 [ice]<br /> [ 683.065962] ethnl_set_channels+0x333/0x3f0<br /> [ 683.070807] genl_family_rcv_msg_doit+0xea/0x150<br /> [ 683.076152] genl_rcv_msg+0xde/0x1d0<br /> [ 683.080289] ? channels_prepare_data+0x60/0x60<br /> [ 683.085432] ? genl_get_cmd+0xd0/0xd0<br /> [ 683.089667] netlink_rcv_skb+0x50/0xf0<br /> [ 683.094006] genl_rcv+0x24/0x40<br /> [ 683.097638] netlink_unicast+0x239/0x340<br /> [ 683.102177] netlink_sendmsg+0x22e/0x470<br /> [ 683.106717] sock_sendmsg+0x5e/0x60<br /> [ 683.110756] __sys_sendto+0xee/0x150<br /> [ 683.114894] ? handle_mm_fault+0xd0/0x2a0<br /> [ 683.119535] ? do_user_addr_fault+0x1f3/0x690<br /> [ 683.134173] __x64_sys_sendto+0x25/0x30<br /> [ 683.148231] do_syscall_64+0x3b/0xc0<br /> [ 683.161992] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Fix this by taking into account the value that num_possible_cpus()<br /> yields in addition to vsi-&gt;alloc_txq instead of doubling the latter.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: fix memory leak in fib6_rule_suppress<br /> <br /> The kernel leaks memory when a `fib` rule is present in IPv6 nftables<br /> firewall rules and a suppress_prefix rule is present in the IPv6 routing<br /> rules (used by certain tools such as wg-quick). In such scenarios, every<br /> incoming packet will leak an allocation in `ip6_dst_cache` slab cache.<br /> <br /> After some hours of `bpftrace`-ing and source code reading, I tracked<br /> down the issue to ca7a03c41753 ("ipv6: do not free rt if<br /> FIB_LOOKUP_NOREF is set on suppress rule").<br /> <br /> The problem with that change is that the generic `args-&gt;flags` always have<br /> `FIB_LOOKUP_NOREF` set[1][2] but the IPv6-specific flag<br /> `RT6_LOOKUP_F_DST_NOREF` might not be, leading to `fib6_rule_suppress` not<br /> decreasing the refcount when needed.<br /> <br /> How to reproduce:<br /> - Add the following nftables rule to a prerouting chain:<br /> meta nfproto ipv6 fib saddr . mark . iif oif missing drop<br /> This can be done with:<br /> sudo nft create table inet test<br /> sudo nft create chain inet test test_chain &amp;#39;{ type filter hook prerouting priority filter + 10; policy accept; }&amp;#39;<br /> sudo nft add rule inet test test_chain meta nfproto ipv6 fib saddr . mark . iif oif missing drop<br /> - Run:<br /> sudo ip -6 rule add table main suppress_prefixlength 0<br /> - Watch `sudo slabtop -o | grep ip6_dst_cache` to see memory usage increase<br /> with every incoming ipv6 packet.<br /> <br /> This patch exposes the protocol-specific flags to the protocol<br /> specific `suppress` function, and check the protocol-specific `flags`<br /> argument for RT6_LOOKUP_F_DST_NOREF instead of the generic<br /> FIB_LOOKUP_NOREF when decreasing the refcount, like this.<br /> <br /> [1]: https://github.com/torvalds/linux/blob/ca7a03c4175366a92cee0ccc4fec0038c3266e26/net/ipv6/fib6_rules.c#L71<br /> [2]: https://github.com/torvalds/linux/blob/ca7a03c4175366a92cee0ccc4fec0038c3266e26/net/ipv6/fib6_rules.c#L99

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: tulip: de4x5: fix the problem that the array &amp;#39;lp-&gt;phy[8]&amp;#39; may be out of bound<br /> <br /> In line 5001, if all id in the array &amp;#39;lp-&gt;phy[8]&amp;#39; is not 0, when the<br /> &amp;#39;for&amp;#39; end, the &amp;#39;k&amp;#39; is 8.<br /> <br /> At this time, the array &amp;#39;lp-&gt;phy[8]&amp;#39; may be out of bound.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()<br /> <br /> The if statement:<br /> if (port &gt;= DSAF_GE_NUM)<br /> return;<br /> <br /> limits the value of port less than DSAF_GE_NUM (i.e., 8).<br /> However, if the value of port is 6 or 7, an array overflow could occur:<br /> port_rst_off = dsaf_dev-&gt;mac_cb[port]-&gt;port_rst_off;<br /> <br /> because the length of dsaf_dev-&gt;mac_cb is DSAF_MAX_PORT_NUM (i.e., 6).<br /> <br /> To fix this possible array overflow, we first check port and if it is<br /> greater than or equal to DSAF_MAX_PORT_NUM, the function returns.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sata_fsl: fix UAF in sata_fsl_port_stop when rmmod sata_fsl<br /> <br /> When the `rmmod sata_fsl.ko` command is executed in the PPC64 GNU/Linux,<br /> a bug is reported:<br /> ==================================================================<br /> BUG: Unable to handle kernel data access on read at 0x80000800805b502c<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> NIP [c0000000000388a4] .ioread32+0x4/0x20<br /> LR [80000000000c6034] .sata_fsl_port_stop+0x44/0xe0 [sata_fsl]<br /> Call Trace:<br /> .free_irq+0x1c/0x4e0 (unreliable)<br /> .ata_host_stop+0x74/0xd0 [libata]<br /> .release_nodes+0x330/0x3f0<br /> .device_release_driver_internal+0x178/0x2c0<br /> .driver_detach+0x64/0xd0<br /> .bus_remove_driver+0x70/0xf0<br /> .driver_unregister+0x38/0x80<br /> .platform_driver_unregister+0x14/0x30<br /> .fsl_sata_driver_exit+0x18/0xa20 [sata_fsl]<br /> .__se_sys_delete_module+0x1ec/0x2d0<br /> .system_call_exception+0xfc/0x1f0<br /> system_call_common+0xf8/0x200<br /> ==================================================================<br /> <br /> The triggering of the BUG is shown in the following stack:<br /> <br /> driver_detach<br /> device_release_driver_internal<br /> __device_release_driver<br /> drv-&gt;remove(dev) --&gt; platform_drv_remove/platform_remove<br /> drv-&gt;remove(dev) --&gt; sata_fsl_remove<br /> iounmap(host_priv-&gt;hcr_base); data) --&gt; ata_host_stop<br /> ap-&gt;ops-&gt;port_stop(ap) --&gt; sata_fsl_port_stop<br /> ioread32(hcr_base + HCONTROL) ops-&gt;host_stop(host)<br /> <br /> The iounmap(host_priv-&gt;hcr_base) and kfree(host_priv) functions should<br /> not be executed in drv-&gt;remove. These functions should be executed in<br /> host_stop after port_stop. Therefore, we move these functions to the<br /> new function sata_fsl_host_stop and bind the new function to host_stop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/amdgpu: fix potential memleak<br /> <br /> In function amdgpu_get_xgmi_hive, when kobject_init_and_add failed<br /> There is a potential memleak if not call kobject_put.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/amdkfd: Fix kernel panic when reset failed and been triggered again<br /> <br /> In SRIOV configuration, the reset may failed to bring asic back to normal but stop cpsch<br /> already been called, the start_cpsch will not be called since there is no resume in this<br /> case. When reset been triggered again, driver should avoid to do uninitialization again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7915: fix NULL pointer dereference in mt7915_get_phy_mode<br /> <br /> Fix the following NULL pointer dereference in mt7915_get_phy_mode<br /> routine adding an ibss interface to the mt7915 driver.<br /> <br /> [ 101.137097] wlan0: Trigger new scan to find an IBSS to join<br /> [ 102.827039] wlan0: Creating new IBSS network, BSSID 26:a4:50:1a:6e:69<br /> [ 103.064756] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [ 103.073670] Mem abort info:<br /> [ 103.076520] ESR = 0x96000005<br /> [ 103.079614] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 103.084934] SET = 0, FnV = 0<br /> [ 103.088042] EA = 0, S1PTW = 0<br /> [ 103.091215] Data abort info:<br /> [ 103.094104] ISV = 0, ISS = 0x00000005<br /> [ 103.098041] CM = 0, WnR = 0<br /> [ 103.101044] user pgtable: 4k pages, 39-bit VAs, pgdp=00000000460b1000<br /> [ 103.107565] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000<br /> [ 103.116590] Internal error: Oops: 96000005 [#1] SMP<br /> [ 103.189066] CPU: 1 PID: 333 Comm: kworker/u4:3 Not tainted 5.10.75 #0<br /> [ 103.195498] Hardware name: MediaTek MT7622 RFB1 board (DT)<br /> [ 103.201124] Workqueue: phy0 ieee80211_iface_work [mac80211]<br /> [ 103.206695] pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--)<br /> [ 103.212705] pc : mt7915_get_phy_mode+0x68/0x120 [mt7915e]<br /> [ 103.218103] lr : mt7915_mcu_add_bss_info+0x11c/0x760 [mt7915e]<br /> [ 103.223927] sp : ffffffc011cdb9e0<br /> [ 103.227235] x29: ffffffc011cdb9e0 x28: ffffff8006563098<br /> [ 103.232545] x27: ffffff8005f4da22 x26: ffffff800685ac40<br /> [ 103.237855] x25: 0000000000000001 x24: 000000000000011f<br /> [ 103.243165] x23: ffffff8005f4e260 x22: ffffff8006567918<br /> [ 103.248475] x21: ffffff8005f4df80 x20: ffffff800685ac58<br /> [ 103.253785] x19: ffffff8006744400 x18: 0000000000000000<br /> [ 103.259094] x17: 0000000000000000 x16: 0000000000000001<br /> [ 103.264403] x15: 000899c3a2d9d2e4 x14: 000899bdc3c3a1c8<br /> [ 103.269713] x13: 0000000000000000 x12: 0000000000000000<br /> [ 103.275024] x11: ffffffc010e30c20 x10: 0000000000000000<br /> [ 103.280333] x9 : 0000000000000050 x8 : ffffff8006567d88<br /> [ 103.285642] x7 : ffffff8006563b5c x6 : ffffff8006563b44<br /> [ 103.290952] x5 : 0000000000000002 x4 : 0000000000000001<br /> [ 103.296262] x3 : 0000000000000001 x2 : 0000000000000001<br /> [ 103.301572] x1 : 0000000000000000 x0 : 0000000000000011<br /> [ 103.306882] Call trace:<br /> [ 103.309328] mt7915_get_phy_mode+0x68/0x120 [mt7915e]<br /> [ 103.314378] mt7915_bss_info_changed+0x198/0x200 [mt7915e]<br /> [ 103.319941] ieee80211_bss_info_change_notify+0x128/0x290 [mac80211]<br /> [ 103.326360] __ieee80211_sta_join_ibss+0x308/0x6c4 [mac80211]<br /> [ 103.332171] ieee80211_sta_create_ibss+0x8c/0x10c [mac80211]<br /> [ 103.337895] ieee80211_ibss_work+0x3dc/0x614 [mac80211]<br /> [ 103.343185] ieee80211_iface_work+0x388/0x3f0 [mac80211]<br /> [ 103.348495] process_one_work+0x288/0x690<br /> [ 103.352499] worker_thread+0x70/0x464<br /> [ 103.356157] kthread+0x144/0x150<br /> [ 103.359380] ret_from_fork+0x10/0x18<br /> [ 103.362952] Code: 394008c3 52800220 394000e4 7100007f (39400023)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx4_en: Fix an use-after-free bug in mlx4_en_try_alloc_resources()<br /> <br /> In mlx4_en_try_alloc_resources(), mlx4_en_copy_priv() is called and<br /> tmp-&gt;tx_cq will be freed on the error path of mlx4_en_copy_priv().<br /> After that mlx4_en_alloc_resources() is called and there is a dereference<br /> of &amp;tmp-&gt;tx_cq[t][i] in mlx4_en_alloc_resources(), which could lead to<br /> a use after free problem on failure of mlx4_en_copy_priv().<br /> <br /> Fix this bug by adding a check of mlx4_en_copy_priv()<br /> <br /> This bug was found by a static analyzer. The analysis employs<br /> differential checking to identify inconsistent security operations<br /> (e.g., checks or kfrees) between two code paths and confirms that the<br /> inconsistent operations are not recovered in the current function or<br /> the callers, so they constitute bugs.<br /> <br /> Note that, as a bug found by static analysis, it can be a false<br /> positive or hard to trigger. Multiple researchers have cross-reviewed<br /> the bug.<br /> <br /> Builds with CONFIG_MLX4_EN=m show no new warnings,<br /> and our static analyzer no longer warns about this code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qlogic: qlcnic: Fix a NULL pointer dereference in qlcnic_83xx_add_rings()<br /> <br /> In qlcnic_83xx_add_rings(), the indirect function of<br /> ahw-&gt;hw_ops-&gt;alloc_mbx_args will be called to allocate memory for<br /> cmd.req.arg, and there is a dereference of it in qlcnic_83xx_add_rings(),<br /> which could lead to a NULL pointer dereference on failure of the<br /> indirect function like qlcnic_83xx_alloc_mbx_args().<br /> <br /> Fix this bug by adding a check of alloc_mbx_args(), this patch<br /> imitates the logic of mbx_cmd()&amp;#39;s failure handling.<br /> <br /> This bug was found by a static analyzer. The analysis employs<br /> differential checking to identify inconsistent security operations<br /> (e.g., checks or kfrees) between two code paths and confirms that the<br /> inconsistent operations are not recovered in the current function or<br /> the callers, so they constitute bugs.<br /> <br /> Note that, as a bug found by static analysis, it can be a false<br /> positive or hard to trigger. Multiple researchers have cross-reviewed<br /> the bug.<br /> <br /> Builds with CONFIG_QLCNIC=m show no new warnings, and our<br /> static analyzer no longer warns about this code.