Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: at803x: fix NULL pointer dereference on AR9331 PHY<br /> <br /> Latest kernel will explode on the PHY interrupt config, since it depends<br /> now on allocated priv. So, run probe to allocate priv to fix it.<br /> <br /> ar9331_switch ethernet.1:10 lan0 (uninitialized): PHY [!ahb!ethernet@1a000000!mdio!switch@10:00] driver [Qualcomm Atheros AR9331 built-in PHY] (irq=13)<br /> CPU 0 Unable to handle kernel paging request at virtual address 0000000a, epc == 8050e8a8, ra == 80504b34<br /> ...<br /> Call Trace:<br /> [] at803x_config_intr+0x5c/0xd0<br /> [] phy_request_interrupt+0xa8/0xd0<br /> [] phylink_bringup_phy+0x2d8/0x3ac<br /> [] phylink_fwnode_phy_connect+0x118/0x130<br /> [] dsa_slave_create+0x270/0x420<br /> [] dsa_port_setup+0x12c/0x148<br /> [] dsa_register_switch+0xaf0/0xcc0<br /> [] ar9331_sw_probe+0x370/0x388<br /> [] mdio_probe+0x44/0x70<br /> [] really_probe+0x200/0x424<br /> [] __driver_probe_device+0x290/0x298<br /> [] driver_probe_device+0x54/0xe4<br /> [] __device_attach_driver+0xe4/0x130<br /> [] bus_for_each_drv+0xb4/0xd8<br /> [] __device_attach+0x104/0x1a4<br /> [] bus_probe_device+0x48/0xc4<br /> [] deferred_probe_work_func+0xf0/0x10c<br /> [] process_one_work+0x314/0x4d4<br /> [] worker_thread+0x2a4/0x354<br /> [] kthread+0x134/0x13c<br /> [] ret_from_kernel_thread+0x14/0x1c<br /> <br /> Same Issue would affect some other PHYs (QCA8081, QCA9561), so fix it<br /> too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_net: fix xdp_rxq_info bug after suspend/resume<br /> <br /> The following sequence currently causes a driver bug warning<br /> when using virtio_net:<br /> <br /> # ip link set eth0 up<br /> # echo mem &gt; /sys/power/state (or e.g. # rtcwake -s 10 -m mem)<br /> <br /> # ip link set eth0 down<br /> <br /> Missing register, driver bug<br /> WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138 xdp_rxq_info_unreg+0x58/0x60<br /> Call trace:<br /> xdp_rxq_info_unreg+0x58/0x60<br /> virtnet_close+0x58/0xac<br /> __dev_close_many+0xac/0x140<br /> __dev_change_flags+0xd8/0x210<br /> dev_change_flags+0x24/0x64<br /> do_setlink+0x230/0xdd0<br /> ...<br /> <br /> This happens because virtnet_freeze() frees the receive_queue<br /> completely (including struct xdp_rxq_info) but does not call<br /> xdp_rxq_info_unreg(). Similarly, virtnet_restore() sets up the<br /> receive_queue again but does not call xdp_rxq_info_reg().<br /> <br /> Actually, parts of virtnet_freeze_down() and virtnet_restore_up()<br /> are almost identical to virtnet_close() and virtnet_open(): only<br /> the calls to xdp_rxq_info_(un)reg() are missing. This means that<br /> we can fix this easily and avoid such problems in the future by<br /> just calling virtnet_close()/open() from the freeze/restore handlers.<br /> <br /> Aside from adding the missing xdp_rxq_info calls the only difference<br /> is that the refill work is only cancelled if netif_running(). However,<br /> this should not make any functional difference since the refill work<br /> should only be active if the network interface is actually up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/cm: Fix memory leak in ib_cm_insert_listen<br /> <br /> cm_alloc_id_priv() allocates resource for the cm_id_priv. When<br /> cm_init_listen() fails it doesn&amp;#39;t free it, leading to memory leak.<br /> <br /> Add the missing error unwind.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: tun: unlink NAPI from device on destruction<br /> <br /> Syzbot found a race between tun file and device destruction.<br /> NAPIs live in struct tun_file which can get destroyed before<br /> the netdev so we have to del them explicitly. The current<br /> code is missing deleting the NAPI if the queue was detached<br /> first.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm raid: fix KASAN warning in raid5_add_disks<br /> <br /> There&amp;#39;s a KASAN warning in raid5_add_disk when running the LVM testsuite.<br /> The warning happens in the test<br /> lvconvert-raid-reshape-linear_to_raid6-single-type.sh. We fix the warning<br /> by verifying that rdev-&gt;saved_raid_disk is within limits.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm raid: fix accesses beyond end of raid member array<br /> <br /> On dm-raid table load (using raid_ctr), dm-raid allocates an array<br /> rs-&gt;devs[rs-&gt;raid_disks] for the raid device members. rs-&gt;raid_disks<br /> is defined by the number of raid metadata and image tupples passed<br /> into the target&amp;#39;s constructor.<br /> <br /> In the case of RAID layout changes being requested, that number can be<br /> different from the current number of members for existing raid sets as<br /> defined in their superblocks. Example RAID layout changes include:<br /> - raid1 legs being added/removed<br /> - raid4/5/6/10 number of stripes changed (stripe reshaping)<br /> - takeover to higher raid level (e.g. raid5 -&gt; raid6)<br /> <br /> When accessing array members, rs-&gt;raid_disks must be used in control<br /> loops instead of the potentially larger value in rs-&gt;md.raid_disks.<br /> Otherwise it will cause memory access beyond the end of the rs-&gt;devs<br /> array.<br /> <br /> Fix this by changing code that is prone to out-of-bounds access.<br /> Also fix validate_raid_redundancy() to validate all devices that are<br /> added. Also, use braces to help clean up raid_iterate_devices().<br /> <br /> The out-of-bounds memory accesses was discovered using KASAN.<br /> <br /> This commit was verified to pass all LVM2 RAID tests (with KASAN<br /> enabled).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tick/nohz: unexport __init-annotated tick_nohz_full_setup()<br /> <br /> EXPORT_SYMBOL and __init is a bad combination because the .init.text<br /> section is freed up after the initialization. Hence, modules cannot<br /> use symbols annotated __init. The access to a freed symbol may end up<br /> with kernel panic.<br /> <br /> modpost used to detect it, but it had been broken for a decade.<br /> <br /> Commit 28438794aba4 ("modpost: fix section mismatch check for exported<br /> init/exit sections") fixed it so modpost started to warn it again, then<br /> this showed up:<br /> <br /> MODPOST vmlinux.symvers<br /> WARNING: modpost: vmlinux.o(___ksymtab_gpl+tick_nohz_full_setup+0x0): Section mismatch in reference from the variable __ksymtab_tick_nohz_full_setup to the function .init.text:tick_nohz_full_setup()<br /> The symbol tick_nohz_full_setup is exported and annotated __init<br /> Fix this by removing the __init annotation of tick_nohz_full_setup or drop the export.<br /> <br /> Drop the export because tick_nohz_full_setup() is only called from the<br /> built-in code in kernel/sched/isolation.c.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memory: samsung: exynos5422-dmc: Fix refcount leak in of_get_dram_timings<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> This function doesn&amp;#39;t call of_node_put() in some error paths.<br /> To unify the structure, Add put_node label and goto it on errors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: cns3xxx: Fix refcount leak in cns3xxx_init<br /> <br /> of_find_compatible_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: bcm: brcmstb: pm: pm-arm: Fix refcount leak in brcmstb_pm_probe<br /> <br /> of_find_matching_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.<br /> <br /> In brcmstb_init_sram, it pass dn to of_address_to_resource(),<br /> of_address_to_resource() will call of_find_device_by_node() to take<br /> reference, so we should release the reference returned by<br /> of_find_matching_node().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: Fix refcount leak in axxia_boot_secondary<br /> <br /> of_find_compatible_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: exynos: Fix refcount leak in exynos_map_pmu<br /> <br /> of_find_matching_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.<br /> of_node_put() checks null pointer.