Vulnerabilities

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 /> 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: 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 /> 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 /> 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 /> 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 /> nfc: pn533: initialize struct pn533_out_arg properly<br /> <br /> struct pn533_out_arg used as a temporary context for out_urb is not<br /> initialized properly. Its uninitialized &amp;#39;phy&amp;#39; field can be dereferenced in<br /> error cases inside pn533_out_complete() callback function. It causes the<br /> following failure:<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.2.0-rc3-next-20230110-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> RIP: 0010:pn533_out_complete.cold+0x15/0x44 drivers/nfc/pn533/usb.c:441<br /> Call Trace:<br /> <br /> __usb_hcd_giveback_urb+0x2b6/0x5c0 drivers/usb/core/hcd.c:1671<br /> usb_hcd_giveback_urb+0x384/0x430 drivers/usb/core/hcd.c:1754<br /> dummy_timer+0x1203/0x32d0 drivers/usb/gadget/udc/dummy_hcd.c:1988<br /> call_timer_fn+0x1da/0x800 kernel/time/timer.c:1700<br /> expire_timers+0x234/0x330 kernel/time/timer.c:1751<br /> __run_timers kernel/time/timer.c:2022 [inline]<br /> __run_timers kernel/time/timer.c:1995 [inline]<br /> run_timer_softirq+0x326/0x910 kernel/time/timer.c:2035<br /> __do_softirq+0x1fb/0xaf6 kernel/softirq.c:571<br /> invoke_softirq kernel/softirq.c:445 [inline]<br /> __irq_exit_rcu+0x123/0x180 kernel/softirq.c:650<br /> irq_exit_rcu+0x9/0x20 kernel/softirq.c:662<br /> sysvec_apic_timer_interrupt+0x97/0xc0 arch/x86/kernel/apic/apic.c:1107<br /> <br /> Initialize the field with the pn533_usb_phy currently used.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: Fix a procfs host directory removal regression<br /> <br /> scsi_proc_hostdir_rm() decreases a reference counter and hence must only be<br /> called once per host that is removed. This change does not require a<br /> scsi_add_host_with_dma() change since scsi_add_host_with_dma() will return<br /> 0 (success) if scsi_proc_host_add() is called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: prevent out-of-bounds array speculation when closing a file descriptor<br /> <br /> Google-Bug-Id: 114199369

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: avoid potential UAF in nvmet_req_complete()<br /> <br /> An nvme target -&gt;queue_response() operation implementation may free the<br /> request passed as argument. Such implementation potentially could result<br /> in a use after free of the request pointer when percpu_ref_put() is<br /> called in nvmet_req_complete().<br /> <br /> Avoid such problem by using a local variable to save the sq pointer<br /> before calling __nvmet_req_complete(), thus avoiding dereferencing the<br /> req pointer after that function call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Fix memory leaks in mpi3mr_init_ioc()<br /> <br /> Don&amp;#39;t allocate memory again when IOC is being reinitialized.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix kernel crash during reboot when adapter is in recovery mode<br /> <br /> If the driver detects during probe that firmware is in recovery<br /> mode then i40e_init_recovery_mode() is called and the rest of<br /> probe function is skipped including pci_set_drvdata(). Subsequent<br /> i40e_shutdown() called during shutdown/reboot dereferences NULL<br /> pointer as pci_get_drvdata() returns NULL.<br /> <br /> To fix call pci_set_drvdata() also during entering to recovery mode.<br /> <br /> Reproducer:<br /> 1) Lets have i40e NIC with firmware in recovery mode<br /> 2) Run reboot<br /> <br /> Result:<br /> [ 139.084698] i40e: Intel(R) Ethernet Connection XL710 Network Driver<br /> [ 139.090959] i40e: Copyright (c) 2013 - 2019 Intel Corporation.<br /> [ 139.108438] i40e 0000:02:00.0: Firmware recovery mode detected. Limiting functionality.<br /> [ 139.116439] i40e 0000:02:00.0: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.<br /> [ 139.129499] i40e 0000:02:00.0: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]<br /> [ 139.215932] i40e 0000:02:00.0 enp2s0f0: renamed from eth0<br /> [ 139.223292] i40e 0000:02:00.1: Firmware recovery mode detected. Limiting functionality.<br /> [ 139.231292] i40e 0000:02:00.1: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.<br /> [ 139.244406] i40e 0000:02:00.1: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]<br /> [ 139.329209] i40e 0000:02:00.1 enp2s0f1: renamed from eth0<br /> ...<br /> [ 156.311376] BUG: kernel NULL pointer dereference, address: 00000000000006c2<br /> [ 156.318330] #PF: supervisor write access in kernel mode<br /> [ 156.323546] #PF: error_code(0x0002) - not-present page<br /> [ 156.328679] PGD 0 P4D 0<br /> [ 156.331210] Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> [ 156.335567] CPU: 26 PID: 15119 Comm: reboot Tainted: G E 6.2.0+ #1<br /> [ 156.343126] Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.4 04/13/2022<br /> [ 156.353369] RIP: 0010:i40e_shutdown+0x15/0x130 [i40e]<br /> [ 156.358430] Code: c1 fc ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 55 48 89 fd 53 48 8b 9f 48 01 00 00 80 8b c2 06 00 00 04 f0 80 8b c0 06 00 00 08 48 8d bb 08 08 00<br /> [ 156.377168] RSP: 0018:ffffb223c8447d90 EFLAGS: 00010282<br /> [ 156.382384] RAX: ffffffffc073ee70 RBX: 0000000000000000 RCX: 0000000000000001<br /> [ 156.389510] RDX: 0000000080000001 RSI: 0000000000000246 RDI: ffff95db49988000<br /> [ 156.396634] RBP: ffff95db49988000 R08: ffffffffffffffff R09: ffffffff8bd17d40<br /> [ 156.403759] R10: 0000000000000001 R11: ffffffff8a5e3d28 R12: ffff95db49988000<br /> [ 156.410882] R13: ffffffff89a6fe17 R14: ffff95db49988150 R15: 0000000000000000<br /> [ 156.418007] FS: 00007fe7c0cc3980(0000) GS:ffff95ea8ee80000(0000) knlGS:0000000000000000<br /> [ 156.426083] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 156.431819] CR2: 00000000000006c2 CR3: 00000003092fc005 CR4: 0000000000770ee0<br /> [ 156.438944] PKRU: 55555554<br /> [ 156.441647] Call Trace:<br /> [ 156.444096] <br /> [ 156.446199] pci_device_shutdown+0x38/0x60<br /> [ 156.450297] device_shutdown+0x163/0x210<br /> [ 156.454215] kernel_restart+0x12/0x70<br /> [ 156.457872] __do_sys_reboot+0x1ab/0x230<br /> [ 156.461789] ? vfs_writev+0xa6/0x1a0<br /> [ 156.465362] ? __pfx_file_free_rcu+0x10/0x10<br /> [ 156.469635] ? __call_rcu_common.constprop.85+0x109/0x5a0<br /> [ 156.475034] do_syscall_64+0x3e/0x90<br /> [ 156.478611] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> [ 156.483658] RIP: 0033:0x7fe7bff37ab7