Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: ioctl: fix potential NULL deref in ethtool_set_coalesce()<br /> <br /> ethtool_set_coalesce() now uses both the .get_coalesce() and<br /> .set_coalesce() callbacks. But the check for their availability is<br /> buggy, so changing the coalesce settings on a device where the driver<br /> provides only _one_ of the callbacks results in a NULL pointer<br /> dereference instead of an -EOPNOTSUPP.<br /> <br /> Fix the condition so that the availability of both callbacks is<br /> ensured. This also matches the netlink code.<br /> <br /> Note that reproducing this requires some effort - it only affects the<br /> legacy ioctl path, and needs a specific combination of driver options:<br /> - have .get_coalesce() and .coalesce_supported but no<br /> .set_coalesce(), or<br /> - have .set_coalesce() but no .get_coalesce(). Here eg. ethtool doesn&amp;#39;t<br /> cause the crash as it first attempts to call ethtool_get_coalesce()<br /> and bails out on error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_ets: don&amp;#39;t peek at classes beyond &amp;#39;nbands&amp;#39;<br /> <br /> when the number of DRR classes decreases, the round-robin active list can<br /> contain elements that have already been freed in ets_qdisc_change(). As a<br /> consequence, it&amp;#39;s possible to see a NULL dereference crash, caused by the<br /> attempt to call cl-&gt;qdisc-&gt;ops-&gt;peek(cl-&gt;qdisc) when cl-&gt;qdisc is NULL:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000018<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 1 PID: 910 Comm: mausezahn Not tainted 5.16.0-rc1+ #475<br /> Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014<br /> RIP: 0010:ets_qdisc_dequeue+0x129/0x2c0 [sch_ets]<br /> Code: c5 01 41 39 ad e4 02 00 00 0f 87 18 ff ff ff 49 8b 85 c0 02 00 00 49 39 c4 0f 84 ba 00 00 00 49 8b ad c0 02 00 00 48 8b 7d 10 8b 47 18 48 8b 40 38 0f ae e8 ff d0 48 89 c3 48 85 c0 0f 84 9d<br /> RSP: 0000:ffffbb36c0b5fdd8 EFLAGS: 00010287<br /> RAX: ffff956678efed30 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: 0000000000000002 RSI: ffffffff9b938dc9 RDI: 0000000000000000<br /> RBP: ffff956678efed30 R08: e2f3207fe360129c R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000001 R12: ffff956678efeac0<br /> R13: ffff956678efe800 R14: ffff956611545000 R15: ffff95667ac8f100<br /> FS: 00007f2aa9120740(0000) GS:ffff95667b800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000018 CR3: 000000011070c000 CR4: 0000000000350ee0<br /> Call Trace:<br /> <br /> qdisc_peek_dequeued+0x29/0x70 [sch_ets]<br /> tbf_dequeue+0x22/0x260 [sch_tbf]<br /> __qdisc_run+0x7f/0x630<br /> net_tx_action+0x290/0x4c0<br /> __do_softirq+0xee/0x4f8<br /> irq_exit_rcu+0xf4/0x130<br /> sysvec_apic_timer_interrupt+0x52/0xc0<br /> asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> RIP: 0033:0x7f2aa7fc9ad4<br /> Code: b9 ff ff 48 8b 54 24 18 48 83 c4 08 48 89 ee 48 89 df 5b 5d e9 ed fc ff ff 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 83 ec 10 48 8b 05 10 64 33 00 48 8b 00 48 85 c0 0f 85 84 00<br /> RSP: 002b:00007ffe5d33fab8 EFLAGS: 00000202<br /> RAX: 0000000000000002 RBX: 0000561f72c31460 RCX: 0000561f72c31720<br /> RDX: 0000000000000002 RSI: 0000561f72c31722 RDI: 0000561f72c31720<br /> RBP: 000000000000002a R08: 00007ffe5d33fa40 R09: 0000000000000014<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000561f7187e380<br /> R13: 0000000000000000 R14: 0000000000000000 R15: 0000561f72c31460<br /> <br /> Modules linked in: sch_ets sch_tbf dummy rfkill iTCO_wdt intel_rapl_msr iTCO_vendor_support intel_rapl_common joydev virtio_balloon lpc_ich i2c_i801 i2c_smbus pcspkr ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel ahci libahci ghash_clmulni_intel serio_raw libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod<br /> CR2: 0000000000000018<br /> <br /> Ensuring that &amp;#39;alist&amp;#39; was never zeroed [1] was not sufficient, we need to<br /> remove from the active list those elements that are no more SP nor DRR.<br /> <br /> [1] https://lore.kernel.org/netdev/60d274838bf09777f0371253416e8af71360bc08.1633609148.git.dcaratti@redhat.com/<br /> <br /> v3: fix race between ets_qdisc_change() and ets_qdisc_dequeue() delisting<br /> DRR classes beyond &amp;#39;nbands&amp;#39; in ets_qdisc_change() with the qdisc lock<br /> acquired, thanks to Cong Wang.<br /> <br /> v2: when a NULL qdisc is found in the DRR active list, try to dequeue skb<br /> from the next list item.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: Disable Tx queues when reconfiguring the interface<br /> <br /> The Tx queues were not disabled in situations where the driver needed to<br /> stop the interface to apply a new configuration. This could result in a<br /> kernel panic when doing any of the 3 following actions:<br /> * reconfiguring the number of queues (ethtool -L)<br /> * reconfiguring the size of the ring buffers (ethtool -G)<br /> * installing/removing an XDP program (ip l set dev ethX xdp)<br /> <br /> Prevent the panic by making sure netif_tx_disable is called when stopping<br /> an interface.<br /> <br /> Without this patch, the following kernel panic can be observed when doing<br /> any of the actions above:<br /> <br /> Unable to handle kernel paging request at virtual address ffff80001238d040<br /> [....]<br /> Call trace:<br /> dwmac4_set_addr+0x8/0x10<br /> dev_hard_start_xmit+0xe4/0x1ac<br /> sch_direct_xmit+0xe8/0x39c<br /> __dev_queue_xmit+0x3ec/0xaf0<br /> dev_queue_xmit+0x14/0x20<br /> [...]<br /> [ end trace 0000000000000002 ]---

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 /> 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 /> 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.