Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: adi-axi-adc: Fix refcount leak in adi_axi_adc_attach_client<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 /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: aspeed: Fix refcount leak in aspeed_adc_set_trim_data<br /> <br /> of_find_node_by_name() 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 /> iio: trigger: sysfs: fix use-after-free on remove<br /> <br /> Ensure that the irq_work has completed before the trigger is freed.<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in irq_work_run_list<br /> Read of size 8 at addr 0000000064702248 by task python3/25<br /> <br /> Call Trace:<br /> irq_work_run_list<br /> irq_work_tick<br /> update_process_times<br /> tick_sched_handle<br /> tick_sched_timer<br /> __hrtimer_run_queues<br /> hrtimer_interrupt<br /> <br /> Allocated by task 25:<br /> kmem_cache_alloc_trace<br /> iio_sysfs_trig_add<br /> dev_attr_store<br /> sysfs_kf_write<br /> kernfs_fop_write_iter<br /> new_sync_write<br /> vfs_write<br /> ksys_write<br /> sys_write<br /> <br /> Freed by task 25:<br /> kfree<br /> iio_sysfs_trig_remove<br /> dev_attr_store<br /> sysfs_kf_write<br /> kernfs_fop_write_iter<br /> new_sync_write<br /> vfs_write<br /> ksys_write<br /> sys_write<br /> <br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: uvc: fix list double add in uvcg_video_pump<br /> <br /> A panic can occur if the endpoint becomes disabled and the<br /> uvcg_video_pump adds the request back to the req_free list after it has<br /> already been queued to the endpoint. The endpoint complete will add the<br /> request back to the req_free list. Invalidate the local request handle<br /> once it&amp;#39;s been queued.<br /> <br /> [ 246.796704][T13726] configfs-gadget gadget: uvc: uvc_function_set_alt(1, 0)<br /> [ 246.797078][ T26] list_add double add: new=ffffff878bee5c40, prev=ffffff878bee5c40, next=ffffff878b0f0a90.<br /> [ 246.797213][ T26] ------------[ cut here ]------------<br /> [ 246.797224][ T26] kernel BUG at lib/list_debug.c:31!<br /> [ 246.807073][ T26] Call trace:<br /> [ 246.807180][ T26] uvcg_video_pump+0x364/0x38c<br /> [ 246.807366][ T26] process_one_work+0x2a4/0x544<br /> [ 246.807394][ T26] worker_thread+0x350/0x784<br /> [ 246.807442][ T26] kthread+0x2ac/0x320

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Fix dynamic root getattr<br /> <br /> The recent patch to make afs_getattr consult the server didn&amp;#39;t account<br /> for the pseudo-inodes employed by the dynamic root-type afs superblock<br /> not having a volume or a server to access, and thus an oops occurs if<br /> such a directory is stat&amp;#39;d.<br /> <br /> Fix this by checking to see if the vnode-&gt;volume pointer actually points<br /> anywhere before following it in afs_getattr().<br /> <br /> This can be tested by stat&amp;#39;ing a directory in /afs. It may be<br /> sufficient just to do "ls /afs" and the oops looks something like:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> ...<br /> RIP: 0010:afs_getattr+0x8b/0x14b<br /> ...<br /> Call Trace:<br /> <br /> vfs_statx+0x79/0xf5<br /> vfs_fstatat+0x49/0x62

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erspan: do not assume transport header is always set<br /> <br /> Rewrite tests in ip6erspan_tunnel_xmit() and<br /> erspan_fb_xmit() to not assume transport header is set.<br /> <br /> syzbot reported:<br /> <br /> WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 skb_transport_header include/linux/skbuff.h:2911 [inline]<br /> WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963<br /> Modules linked in:<br /> CPU: 0 PID: 1350 Comm: aoe_tx0 Not tainted 5.19.0-rc2-syzkaller-00160-g274295c6e53f #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014<br /> RIP: 0010:skb_transport_header include/linux/skbuff.h:2911 [inline]<br /> RIP: 0010:ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963<br /> Code: 0f 47 f0 40 88 b5 7f fe ff ff e8 8c 16 4b f9 89 de bf ff ff ff ff e8 a0 12 4b f9 66 83 fb ff 0f 85 1d f1 ff ff e8 71 16 4b f9 0b e9 43 f0 ff ff e8 65 16 4b f9 48 8d 85 30 ff ff ff ba 60 00<br /> RSP: 0018:ffffc90005daf910 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000<br /> RDX: ffff88801f032100 RSI: ffffffff882e8d3f RDI: 0000000000000003<br /> RBP: ffffc90005dafab8 R08: 0000000000000003 R09: 000000000000ffff<br /> R10: 000000000000ffff R11: 0000000000000000 R12: ffff888024f21d40<br /> R13: 000000000000a288 R14: 00000000000000b0 R15: ffff888025a2e000<br /> FS: 0000000000000000(0000) GS:ffff88802c800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b2e425000 CR3: 000000006d099000 CR4: 0000000000152ef0<br /> Call Trace:<br /> <br /> __netdev_start_xmit include/linux/netdevice.h:4805 [inline]<br /> netdev_start_xmit include/linux/netdevice.h:4819 [inline]<br /> xmit_one net/core/dev.c:3588 [inline]<br /> dev_hard_start_xmit+0x188/0x880 net/core/dev.c:3604<br /> sch_direct_xmit+0x19f/0xbe0 net/sched/sch_generic.c:342<br /> __dev_xmit_skb net/core/dev.c:3815 [inline]<br /> __dev_queue_xmit+0x14a1/0x3900 net/core/dev.c:4219<br /> dev_queue_xmit include/linux/netdevice.h:2994 [inline]<br /> tx+0x6a/0xc0 drivers/block/aoe/aoenet.c:63<br /> kthread+0x1e7/0x3b0 drivers/block/aoe/aoecmd.c:1229<br /> kthread+0x2e9/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302<br />

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