Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: spectrum: Protect driver from buggy firmware<br /> <br /> When processing port up/down events generated by the device&amp;#39;s firmware,<br /> the driver protects itself from events reported for non-existent local<br /> ports, but not the CPU port (local port 0), which exists, but lacks a<br /> netdev.<br /> <br /> This can result in a NULL pointer dereference when calling<br /> netif_carrier_{on,off}().<br /> <br /> Fix this by bailing early when processing an event reported for the CPU<br /> port. Problem was only observed when running on top of a buggy emulator.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release()<br /> <br /> For avoiding to slow down queue destroy, we don&amp;#39;t call<br /> blk_mq_quiesce_queue() in blk_cleanup_queue(), instead of delaying to<br /> cancel dispatch work in blk_release_queue().<br /> <br /> However, this way has caused kernel oops[1], reported by Changhui. The log<br /> shows that scsi_device can be freed before running blk_release_queue(),<br /> which is expected too since scsi_device is released after the scsi disk<br /> is closed and the scsi_device is removed.<br /> <br /> Fixes the issue by canceling blk-mq dispatch work in both blk_cleanup_queue()<br /> and disk_release():<br /> <br /> 1) when disk_release() is run, the disk has been closed, and any sync<br /> dispatch activities have been done, so canceling dispatch work is enough to<br /> quiesce filesystem I/O dispatch activity.<br /> <br /> 2) in blk_cleanup_queue(), we only focus on passthrough request, and<br /> passthrough request is always explicitly allocated &amp; freed by<br /> its caller, so once queue is frozen, all sync dispatch activity<br /> for passthrough request has been done, then it is enough to just cancel<br /> dispatch work for avoiding any dispatch activity.<br /> <br /> [1] kernel panic log<br /> [12622.769416] BUG: kernel NULL pointer dereference, address: 0000000000000300<br /> [12622.777186] #PF: supervisor read access in kernel mode<br /> [12622.782918] #PF: error_code(0x0000) - not-present page<br /> [12622.788649] PGD 0 P4D 0<br /> [12622.791474] Oops: 0000 [#1] PREEMPT SMP PTI<br /> [12622.796138] CPU: 10 PID: 744 Comm: kworker/10:1H Kdump: loaded Not tainted 5.15.0+ #1<br /> [12622.804877] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015<br /> [12622.813321] Workqueue: kblockd blk_mq_run_work_fn<br /> [12622.818572] RIP: 0010:sbitmap_get+0x75/0x190<br /> [12622.823336] Code: 85 80 00 00 00 41 8b 57 08 85 d2 0f 84 b1 00 00 00 45 31 e4 48 63 cd 48 8d 1c 49 48 c1 e3 06 49 03 5f 10 4c 8d 6b 40 83 f0 01 8b 33 44 89 f2 4c 89 ef 0f b6 c8 e8 fa f3 ff ff 83 f8 ff 75 58<br /> [12622.844290] RSP: 0018:ffffb00a446dbd40 EFLAGS: 00010202<br /> [12622.850120] RAX: 0000000000000001 RBX: 0000000000000300 RCX: 0000000000000004<br /> [12622.858082] RDX: 0000000000000006 RSI: 0000000000000082 RDI: ffffa0b7a2dfe030<br /> [12622.866042] RBP: 0000000000000004 R08: 0000000000000001 R09: ffffa0b742721334<br /> [12622.874003] R10: 0000000000000008 R11: 0000000000000008 R12: 0000000000000000<br /> [12622.881964] R13: 0000000000000340 R14: 0000000000000000 R15: ffffa0b7a2dfe030<br /> [12622.889926] FS: 0000000000000000(0000) GS:ffffa0baafb40000(0000) knlGS:0000000000000000<br /> [12622.898956] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [12622.905367] CR2: 0000000000000300 CR3: 0000000641210001 CR4: 00000000001706e0<br /> [12622.913328] Call Trace:<br /> [12622.916055] <br /> [12622.918394] scsi_mq_get_budget+0x1a/0x110<br /> [12622.922969] __blk_mq_do_dispatch_sched+0x1d4/0x320<br /> [12622.928404] ? pick_next_task_fair+0x39/0x390<br /> [12622.933268] __blk_mq_sched_dispatch_requests+0xf4/0x140<br /> [12622.939194] blk_mq_sched_dispatch_requests+0x30/0x60<br /> [12622.944829] __blk_mq_run_hw_queue+0x30/0xa0<br /> [12622.949593] process_one_work+0x1e8/0x3c0<br /> [12622.954059] worker_thread+0x50/0x3b0<br /> [12622.958144] ? rescuer_thread+0x370/0x370<br /> [12622.962616] kthread+0x158/0x180<br /> [12622.966218] ? set_kthread_struct+0x40/0x40<br /> [12622.970884] ret_from_fork+0x22/0x30<br /> [12622.974875] <br /> [12622.977309] Modules linked in: scsi_debug rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs sunrpc dm_multipath intel_rapl_msr intel_rapl_common dell_wmi_descriptor sb_edac rfkill video x86_pkg_temp_thermal intel_powerclamp dcdbas coretemp kvm_intel kvm mgag200 irqbypass i2c_algo_bit rapl drm_kms_helper ipmi_ssif intel_cstate intel_uncore syscopyarea sysfillrect sysimgblt fb_sys_fops pcspkr cec mei_me lpc_ich mei ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter drm fuse xfs libcrc32c sr_mod cdrom sd_mod t10_pi sg ixgbe ahci libahci crct10dif_pclmul crc32_pclmul crc32c_intel libata megaraid_sas ghash_clmulni_intel tg3 wdat_w<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: vlan: fix underflow for the real_dev refcnt<br /> <br /> Inject error before dev_hold(real_dev) in register_vlan_dev(),<br /> and execute the following testcase:<br /> <br /> ip link add dev dummy1 type dummy<br /> ip link add name dummy1.100 link dummy1 type vlan id 100<br /> ip link del dev dummy1<br /> <br /> When the dummy netdevice is removed, we will get a WARNING as following:<br /> <br /> =======================================================================<br /> refcount_t: decrement hit 0; leaking memory.<br /> WARNING: CPU: 2 PID: 0 at lib/refcount.c:31 refcount_warn_saturate+0xbf/0x1e0<br /> <br /> and an endless loop of:<br /> <br /> =======================================================================<br /> unregister_netdevice: waiting for dummy1 to become free. Usage count = -1073741824<br /> <br /> That is because dev_put(real_dev) in vlan_dev_free() be called without<br /> dev_hold(real_dev) in register_vlan_dev(). It makes the refcnt of real_dev<br /> underflow.<br /> <br /> Move the dev_hold(real_dev) to vlan_dev_init() which is the call-back of<br /> ndo_init(). That makes dev_hold() and dev_put() for vlan&amp;#39;s real_dev<br /> symmetrical.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: Fix NULL pointer dereferencing in smc_vlan_by_tcpsk()<br /> <br /> Coverity reports a possible NULL dereferencing problem:<br /> <br /> in smc_vlan_by_tcpsk():<br /> 6. returned_null: netdev_lower_get_next returns NULL (checked 29 out of 30 times).<br /> 7. var_assigned: Assigning: ndev = NULL return value from netdev_lower_get_next.<br /> 1623 ndev = (struct net_device *)netdev_lower_get_next(ndev, &amp;lower);<br /> CID 1468509 (#1 of 1): Dereference null return value (NULL_RETURNS)<br /> 8. dereference: Dereferencing a pointer that might be NULL ndev when calling is_vlan_dev.<br /> 1624 if (is_vlan_dev(ndev)) {<br /> <br /> Remove the manual implementation and use netdev_walk_all_lower_dev() to<br /> iterate over the lower devices. While on it remove an obsolete function<br /> parameter comment.

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.

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.