Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: Fix possible corruption when moving a directory<br /> <br /> When we are renaming a directory to a different directory, we need to<br /> update &amp;#39;..&amp;#39; entry in the moved directory. However nothing prevents moved<br /> directory from being modified and even converted from the inline format<br /> to the normal format. When such race happens the rename code gets<br /> confused and we crash. Fix the problem by locking the moved directory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: caif: Fix use-after-free in cfusbl_device_notify()<br /> <br /> syzbot reported use-after-free in cfusbl_device_notify() [1]. This<br /> causes a stack trace like below:<br /> <br /> BUG: KASAN: use-after-free in cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138<br /> Read of size 8 at addr ffff88807ac4e6f0 by task kworker/u4:6/1214<br /> <br /> CPU: 0 PID: 1214 Comm: kworker/u4:6 Not tainted 5.19.0-rc3-syzkaller-00146-g92f20ff72066 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Workqueue: netns cleanup_net<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description.constprop.0.cold+0xeb/0x467 mm/kasan/report.c:313<br /> print_report mm/kasan/report.c:429 [inline]<br /> kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491<br /> cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138<br /> notifier_call_chain+0xb5/0x200 kernel/notifier.c:87<br /> call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1945<br /> call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]<br /> call_netdevice_notifiers net/core/dev.c:1997 [inline]<br /> netdev_wait_allrefs_any net/core/dev.c:10227 [inline]<br /> netdev_run_todo+0xbc0/0x10f0 net/core/dev.c:10341<br /> default_device_exit_batch+0x44e/0x590 net/core/dev.c:11334<br /> ops_exit_list+0x125/0x170 net/core/net_namespace.c:167<br /> cleanup_net+0x4ea/0xb00 net/core/net_namespace.c:594<br /> process_one_work+0x996/0x1610 kernel/workqueue.c:2289<br /> worker_thread+0x665/0x1080 kernel/workqueue.c:2436<br /> kthread+0x2e9/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302<br /> <br /> <br /> When unregistering a net device, unregister_netdevice_many_notify()<br /> sets the device&amp;#39;s reg_state to NETREG_UNREGISTERING, calls notifiers<br /> with NETDEV_UNREGISTER, and adds the device to the todo list.<br /> <br /> Later on, devices in the todo list are processed by netdev_run_todo().<br /> netdev_run_todo() waits devices&amp;#39; reference count become 1 while<br /> rebdoadcasting NETDEV_UNREGISTER notification.<br /> <br /> When cfusbl_device_notify() is called with NETDEV_UNREGISTER multiple<br /> times, the parent device might be freed. This could cause UAF.<br /> Processing NETDEV_UNREGISTER multiple times also causes inbalance of<br /> reference count for the module.<br /> <br /> This patch fixes the issue by accepting only first NETDEV_UNREGISTER<br /> notification.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: fdp: add null check of devm_kmalloc_array in fdp_nci_i2c_read_device_properties<br /> <br /> devm_kmalloc_array may fails, *fw_vsc_cfg might be null and cause<br /> out-of-bounds write in device_property_read_u8_array later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Remove the /proc/scsi/${proc_name} directory earlier<br /> <br /> Remove the /proc/scsi/${proc_name} directory earlier to fix a race<br /> condition between unloading and reloading kernel modules. This fixes a bug<br /> introduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak in<br /> the SCSI core").<br /> <br /> Fix the following kernel warning:<br /> <br /> proc_dir_entry &amp;#39;scsi/scsi_debug&amp;#39; already registered<br /> WARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0<br /> Call Trace:<br /> proc_mkdir+0xb5/0xe0<br /> scsi_proc_hostdir_add+0xb5/0x170<br /> scsi_host_alloc+0x683/0x6c0<br /> sdebug_driver_probe+0x6b/0x2d0 [scsi_debug]<br /> really_probe+0x159/0x540<br /> __driver_probe_device+0xdc/0x230<br /> driver_probe_device+0x4f/0x120<br /> __device_attach_driver+0xef/0x180<br /> bus_for_each_drv+0xe5/0x130<br /> __device_attach+0x127/0x290<br /> device_initial_probe+0x17/0x20<br /> bus_probe_device+0x110/0x130<br /> device_add+0x673/0xc80<br /> device_register+0x1e/0x30<br /> sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug]<br /> scsi_debug_init+0x64f/0x1000 [scsi_debug]<br /> do_one_initcall+0xd7/0x470<br /> do_init_module+0xe7/0x330<br /> load_module+0x122a/0x12c0<br /> __do_sys_finit_module+0x124/0x1a0<br /> __x64_sys_finit_module+0x46/0x50<br /> do_syscall_64+0x38/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix config page DMA memory leak<br /> <br /> A fix for:<br /> <br /> DMA-API: pci 0000:83:00.0: device driver has pending DMA allocations while released from device [count=1]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: tcp_make_synack() can be called from process context<br /> <br /> tcp_rtx_synack() now could be called in process context as explained in<br /> 0a375c822497 ("tcp: tcp_rtx_synack() can be called from process<br /> context").<br /> <br /> tcp_rtx_synack() might call tcp_make_synack(), which will touch per-CPU<br /> variables with preemption enabled. This causes the following BUG:<br /> <br /> BUG: using __this_cpu_add() in preemptible [00000000] code: ThriftIO1/5464<br /> caller is tcp_make_synack+0x841/0xac0<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x10d/0x1a0<br /> check_preemption_disabled+0x104/0x110<br /> tcp_make_synack+0x841/0xac0<br /> tcp_v6_send_synack+0x5c/0x450<br /> tcp_rtx_synack+0xeb/0x1f0<br /> inet_rtx_syn_ack+0x34/0x60<br /> tcp_check_req+0x3af/0x9e0<br /> tcp_rcv_state_process+0x59b/0x2030<br /> tcp_v6_do_rcv+0x5f5/0x700<br /> release_sock+0x3a/0xf0<br /> tcp_sendmsg+0x33/0x40<br /> ____sys_sendmsg+0x2f2/0x490<br /> __sys_sendmsg+0x184/0x230<br /> do_syscall_64+0x3d/0x90<br /> <br /> Avoid calling __TCP_INC_STATS() with will touch per-cpu variables. Use<br /> TCP_INC_STATS() which is safe to be called from context switch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: s390: Fix use-after-free of PCI resources with per-function hotplug<br /> <br /> On s390 PCI functions may be hotplugged individually even when they<br /> belong to a multi-function device. In particular on an SR-IOV device VFs<br /> may be removed and later re-added.<br /> <br /> In commit a50297cf8235 ("s390/pci: separate zbus creation from<br /> scanning") it was missed however that struct pci_bus and struct<br /> zpci_bus&amp;#39;s resource list retained a reference to the PCI functions MMIO<br /> resources even though those resources are released and freed on<br /> hot-unplug. These stale resources may subsequently be claimed when the<br /> PCI function re-appears resulting in use-after-free.<br /> <br /> One idea of fixing this use-after-free in s390 specific code that was<br /> investigated was to simply keep resources around from the moment a PCI<br /> function first appeared until the whole virtual PCI bus created for<br /> a multi-function device disappears. The problem with this however is<br /> that due to the requirement of artificial MMIO addreesses (address<br /> cookies) extra logic is then needed to keep the address cookies<br /> compatible on re-plug. At the same time the MMIO resources semantically<br /> belong to the PCI function so tying their lifecycle to the function<br /> seems more logical.<br /> <br /> Instead a simpler approach is to remove the resources of an individually<br /> hot-unplugged PCI function from the PCI bus&amp;#39;s resource list while<br /> keeping the resources of other PCI functions on the PCI bus untouched.<br /> <br /> This is done by introducing pci_bus_remove_resource() to remove an<br /> individual resource. Similarly the resource also needs to be removed<br /> from the struct zpci_bus&amp;#39;s resource list. It turns out however, that<br /> there is really no need to add the MMIO resources to the struct<br /> zpci_bus&amp;#39;s resource list at all and instead we can simply use the<br /> zpci_bar_struct&amp;#39;s resource pointer directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpt3sas: Fix NULL pointer access in mpt3sas_transport_port_add()<br /> <br /> Port is allocated by sas_port_alloc_num() and rphy is allocated by either<br /> sas_end_device_alloc() or sas_expander_alloc(), all of which may return<br /> NULL. So we need to check the rphy to avoid possible NULL pointer access.<br /> <br /> If sas_rphy_add() returned with failure, rphy is set to NULL. We would<br /> access the rphy in the following lines which would also result NULL pointer<br /> access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: smsc75xx: Limit packet length to skb-&gt;len<br /> <br /> Packet length retrieved from skb data may be larger than<br /> the actual socket buffer length (up to 9026 bytes). In such<br /> case the cloned skb passed up the network stack will leak<br /> kernel memory contents.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix sas_hba.phy memory leak in mpi3mr_remove()<br /> <br /> Free mrioc-&gt;sas_hba.phy at .remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix expander node leak in mpi3mr_remove()<br /> <br /> Add a missing resource clean up in .remove.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix throttle_groups memory leak<br /> <br /> Add a missing kfree().