Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xtensa: xtfpga: Fix refcount leak bug in setup<br /> <br /> In machine_setup(), of_find_compatible_node() will return a node<br /> pointer with refcount incremented. We should use of_node_put() when<br /> it is not used anymore.

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 /> can: gs_usb: gs_usb_open/close(): fix memory leak<br /> <br /> The gs_usb driver appears to suffer from a malady common to many USB<br /> CAN adapter drivers in that it performs usb_alloc_coherent() to<br /> allocate a number of USB request blocks (URBs) for RX, and then later<br /> relies on usb_kill_anchored_urbs() to free them, but this doesn&amp;#39;t<br /> actually free them. As a result, this may be leaking DMA memory that&amp;#39;s<br /> been used by the driver.<br /> <br /> This commit is an adaptation of the techniques found in the esd_usb2<br /> driver where a similar design pattern led to a memory leak. It<br /> explicitly frees the RX URBs and their DMA memory via a call to<br /> usb_free_coherent(). Since the RX URBs were allocated in the<br /> gs_can_open(), we remove them in gs_can_close() rather than in the<br /> disconnect function as was done in esd_usb2.<br /> <br /> For more information, see the 928150fad41b ("can: esd_usb2: fix memory<br /> leak").