Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci: Check endpoint is valid before dereferencing it<br /> <br /> When the host controller is not responding, all URBs queued to all<br /> endpoints need to be killed. This can cause a kernel panic if we<br /> dereference an invalid endpoint.<br /> <br /> Fix this by using xhci_get_virt_ep() helper to find the endpoint and<br /> checking if the endpoint is valid before dereferencing it.<br /> <br /> [233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead<br /> [233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8<br /> <br /> [233311.853964] pc : xhci_hc_died+0x10c/0x270<br /> [233311.853971] lr : xhci_hc_died+0x1ac/0x270<br /> <br /> [233311.854077] Call trace:<br /> [233311.854085] xhci_hc_died+0x10c/0x270<br /> [233311.854093] xhci_stop_endpoint_command_watchdog+0x100/0x1a4<br /> [233311.854105] call_timer_fn+0x50/0x2d4<br /> [233311.854112] expire_timers+0xac/0x2e4<br /> [233311.854118] run_timer_softirq+0x300/0xabc<br /> [233311.854127] __do_softirq+0x148/0x528<br /> [233311.854135] irq_exit+0x194/0x1a8<br /> [233311.854143] __handle_domain_irq+0x164/0x1d0<br /> [233311.854149] gic_handle_irq.22273+0x10c/0x188<br /> [233311.854156] el1_irq+0xfc/0x1a8<br /> [233311.854175] lpm_cpuidle_enter+0x25c/0x418 [msm_pm]<br /> [233311.854185] cpuidle_enter_state+0x1f0/0x764<br /> [233311.854194] do_idle+0x594/0x6ac<br /> [233311.854201] cpu_startup_entry+0x7c/0x80<br /> [233311.854209] secondary_start_kernel+0x170/0x198

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nommu: fix memory leak in do_mmap() error path<br /> <br /> The preallocation of the maple tree nodes may leak if the error path to<br /> "error_just_free" is taken. Fix this by moving the freeing of the maple<br /> tree nodes to a shared location for all error paths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: lock overflowing for IOPOLL<br /> <br /> syzbot reports an issue with overflow filling for IOPOLL:<br /> <br /> WARNING: CPU: 0 PID: 28 at io_uring/io_uring.c:734 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734<br /> CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0<br /> Workqueue: events_unbound io_ring_exit_work<br /> Call trace:<br />  io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734<br />  io_req_cqe_overflow+0x5c/0x70 io_uring/io_uring.c:773<br />  io_fill_cqe_req io_uring/io_uring.h:168 [inline]<br />  io_do_iopoll+0x474/0x62c io_uring/rw.c:1065<br />  io_iopoll_try_reap_events+0x6c/0x108 io_uring/io_uring.c:1513<br />  io_uring_try_cancel_requests+0x13c/0x258 io_uring/io_uring.c:3056<br />  io_ring_exit_work+0xec/0x390 io_uring/io_uring.c:2869<br />  process_one_work+0x2d8/0x504 kernel/workqueue.c:2289<br />  worker_thread+0x340/0x610 kernel/workqueue.c:2436<br />  kthread+0x12c/0x158 kernel/kthread.c:376<br />  ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863<br /> <br /> There is no real problem for normal IOPOLL as flush is also called with<br /> uring_lock taken, but it&amp;#39;s getting more complicated for IOPOLL|SQPOLL,<br /> for which __io_cqring_overflow_flush() happens from the CQ waiting path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Fix possible NULL pointer dereference in snd_usb_pcm_has_fixed_rate()<br /> <br /> The subs function argument may be NULL, so do not use it before the NULL check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-pf: Fix resource leakage in VF driver unbind<br /> <br /> resources allocated like mcam entries to support the Ntuple feature<br /> and hash tables for the tc feature are not getting freed in driver<br /> unbind. This patch fixes the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_mpls: Fix warning during failed attribute validation<br /> <br /> The &amp;#39;TCA_MPLS_LABEL&amp;#39; attribute is of &amp;#39;NLA_U32&amp;#39; type, but has a<br /> validation type of &amp;#39;NLA_VALIDATE_FUNCTION&amp;#39;. This is an invalid<br /> combination according to the comment above &amp;#39;struct nla_policy&amp;#39;:<br /> <br /> "<br /> Meaning of `validate&amp;#39; field, use via NLA_POLICY_VALIDATE_FN:<br /> NLA_BINARY Validation function called for the attribute.<br /> All other Unused - but note that it&amp;#39;s a union<br /> "<br /> <br /> This can trigger the warning [1] in nla_get_range_unsigned() when<br /> validation of the attribute fails. Despite being of &amp;#39;NLA_U32&amp;#39; type, the<br /> associated &amp;#39;min&amp;#39;/&amp;#39;max&amp;#39; fields in the policy are negative as they are<br /> aliased by the &amp;#39;validate&amp;#39; field.<br /> <br /> Fix by changing the attribute type to &amp;#39;NLA_BINARY&amp;#39; which is consistent<br /> with the above comment and all other users of NLA_POLICY_VALIDATE_FN().<br /> As a result, move the length validation to the validation function.<br /> <br /> No regressions in MPLS tests:<br /> <br /> # ./tdc.py -f tc-tests/actions/mpls.json<br /> [...]<br /> # echo $?<br /> 0<br /> <br /> [1]<br /> WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118<br /> nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117<br /> Modules linked in:<br /> CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117<br /> [...]<br /> Call Trace:<br /> <br /> __netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310<br /> netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411<br /> netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline]<br /> netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506<br /> netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546<br /> rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345<br /> netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]<br /> ____sys_sendmsg+0x38f/0x500 net/socket.c:2482<br /> ___sys_sendmsg net/socket.c:2536 [inline]<br /> __sys_sendmsg+0x197/0x230 net/socket.c:2565<br /> __do_sys_sendmsg net/socket.c:2574 [inline]<br /> __se_sys_sendmsg net/socket.c:2572 [inline]<br /> __x64_sys_sendmsg+0x42/0x50 net/socket.c:2572<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: pn533: Wait for out_urb&amp;#39;s completion in pn533_usb_send_frame()<br /> <br /> Fix a use-after-free that occurs in hcd when in_urb sent from<br /> pn533_usb_send_frame() is completed earlier than out_urb. Its callback<br /> frees the skb data in pn533_send_async_complete() that is used as a<br /> transfer buffer of out_urb. Wait before sending in_urb until the<br /> callback of out_urb is called. To modify the callback of out_urb alone,<br /> separate the complete function of out_urb and ack_urb.<br /> <br /> Found by a modified version of syzkaller.<br /> <br /> BUG: KASAN: use-after-free in dummy_timer<br /> Call Trace:<br /> memcpy (mm/kasan/shadow.c:65)<br /> dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352)<br /> transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453)<br /> dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972)<br /> arch_static_branch (arch/x86/include/asm/jump_label.h:27)<br /> static_key_false (include/linux/jump_label.h:207)<br /> timer_expire_exit (include/trace/events/timer.h:127)<br /> call_timer_fn (kernel/time/timer.c:1475)<br /> expire_timers (kernel/time/timer.c:1519)<br /> __run_timers (kernel/time/timer.c:1790)<br /> run_timer_softirq (kernel/time/timer.c:1803)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix potential NULL dereference<br /> <br /> Fix potential NULL dereference, in the case when "man", the resource manager<br /> might be NULL, when/if we print debug information.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix handling of cached open files in nfsd4_open codepath<br /> <br /> Commit fb70bf124b05 ("NFSD: Instantiate a struct file when creating a<br /> regular NFSv4 file") added the ability to cache an open fd over a<br /> compound. There are a couple of problems with the way this currently<br /> works:<br /> <br /> It&amp;#39;s racy, as a newly-created nfsd_file can end up with its PENDING bit<br /> cleared while the nf is hashed, and the nf_file pointer is still zeroed<br /> out. Other tasks can find it in this state and they expect to see a<br /> valid nf_file, and can oops if nf_file is NULL.<br /> <br /> Also, there is no guarantee that we&amp;#39;ll end up creating a new nfsd_file<br /> if one is already in the hash. If an extant entry is in the hash with a<br /> valid nf_file, nfs4_get_vfs_file will clobber its nf_file pointer with<br /> the value of op_file and the old nf_file will leak.<br /> <br /> Fix both issues by making a new nfsd_file_acquirei_opened variant that<br /> takes an optional file pointer. If one is present when this is called,<br /> we&amp;#39;ll take a new reference to it instead of trying to open the file. If<br /> the nfsd_file already has a valid nf_file, we&amp;#39;ll just ignore the<br /> optional file and pass the nfsd_file back as-is.<br /> <br /> Also rework the tracepoints a bit to allow for an "opened" variant and<br /> don&amp;#39;t try to avoid counting acquisitions in the case where we already<br /> have a cached open file.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/iova: Fix alloc iova overflows issue<br /> <br /> In __alloc_and_insert_iova_range, there is an issue that retry_pfn<br /> overflows. The value of iovad-&gt;anchor.pfn_hi is ~0UL, then when<br /> iovad-&gt;cached_node is iovad-&gt;anchor, curr_iova-&gt;pfn_hi + 1 will<br /> overflow. As a result, if the retry logic is executed, low_pfn is<br /> updated to 0, and then new_pfn cached_node is assigned as iovad-&gt;anchor. For<br /> example, the iova domain size is 10M, start_pfn is 0x1_F000_0000,<br /> and the iova size allocated for the first time is 11M. The<br /> following is the log information, new-&gt;pfn_lo is smaller than<br /> iovad-&gt;cached_node.<br /> <br /> Example log as follows:<br /> [ 223.798112][T1705487] sh: [name:iova&amp;]__alloc_and_insert_iova_range<br /> start_pfn:0x1f0000,retry_pfn:0x0,size:0xb00,limit_pfn:0x1f0a00<br /> [ 223.799590][T1705487] sh: [name:iova&amp;]__alloc_and_insert_iova_range<br /> success start_pfn:0x1f0000,new-&gt;pfn_lo:0x1efe00,new-&gt;pfn_hi:0x1f08ff<br /> <br /> 2. The node with the largest iova-&gt;pfn_lo value in the iova domain<br /> is deleted, iovad-&gt;cached_node will be updated to iovad-&gt;anchor,<br /> and then the alloc iova size exceeds the maximum iova size that can<br /> be allocated in the domain.<br /> <br /> After judging that retry_pfn is less than limit_pfn, call retry_pfn+1<br /> to fix the overflow issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: another fix for the headless Adreno GPU<br /> <br /> Fix another oops reproducible when rebooting the board with the Adreno<br /> GPU working in the headless mode (e.g. iMX platforms).<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read<br /> [00000000] *pgd=74936831, *pte=00000000, *ppte=00000000<br /> Internal error: Oops: 17 [#1] ARM<br /> CPU: 0 PID: 51 Comm: reboot Not tainted 6.2.0-rc1-dirty #11<br /> Hardware name: Freescale i.MX53 (Device Tree Support)<br /> PC is at msm_atomic_commit_tail+0x50/0x970<br /> LR is at commit_tail+0x9c/0x188<br /> pc : [] lr : [] psr: 600e0013<br /> sp : e0851d30 ip : ee4eb7eb fp : 00090acc<br /> r10: 00000058 r9 : c2193014 r8 : c4310000<br /> r7 : c4759380 r6 : 07bef61d r5 : 00000000 r4 : 00000000<br /> r3 : c44cc440 r2 : 00000000 r1 : 00000000 r0 : 00000000<br /> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none<br /> Control: 10c5387d Table: 74910019 DAC: 00000051<br /> Register r0 information: NULL pointer<br /> Register r1 information: NULL pointer<br /> Register r2 information: NULL pointer<br /> Register r3 information: slab kmalloc-1k start c44cc400 pointer offset 64 size 1024<br /> Register r4 information: NULL pointer<br /> Register r5 information: NULL pointer<br /> Register r6 information: non-paged memory<br /> Register r7 information: slab kmalloc-128 start c4759380 pointer offset 0 size 128<br /> Register r8 information: slab kmalloc-2k start c4310000 pointer offset 0 size 2048<br /> Register r9 information: non-slab/vmalloc memory<br /> Register r10 information: non-paged memory<br /> Register r11 information: non-paged memory<br /> Register r12 information: non-paged memory<br /> Process reboot (pid: 51, stack limit = 0xc80046d9)<br /> Stack: (0xe0851d30 to 0xe0852000)<br /> 1d20: c4759380 fbd77200 000005ff 002b9c70<br /> 1d40: c4759380 c4759380 00000000 07bef61d 00000600 c0d6fe7c c2193014 00000058<br /> 1d60: 00090acc c067a214 00000000 c4759380 c4310000 00000000 c44cc854 c067a89c<br /> 1d80: 00000000 00000000 00000000 c4310468 00000000 c4759380 c4310000 c4310468<br /> 1da0: c4310470 c0643258 c4759380 00000000 00000000 c0c4ee24 00000000 c44cc810<br /> 1dc0: 00000000 c0c4ee24 00000000 c44cc810 00000000 0347d2a8 e0851e00 e0851e00<br /> 1de0: c4759380 c067ad20 c4310000 00000000 c44cc810 c27f8718 c44cc854 c067adb8<br /> 1e00: c4933000 00000002 00000001 00000000 00000000 c2130850 00000000 c2130854<br /> 1e20: c25fc488 00000000 c0ff162c 00000000 00000001 00000002 00000000 00000000<br /> 1e40: c43102c0 c43102c0 00000000 0347d2a8 c44cc810 c44cc814 c2133da8 c06d1a60<br /> 1e60: 00000000 00000000 00079028 c2012f24 fee1dead c4933000 00000058 c01431e4<br /> 1e80: 01234567 c0143a20 00000000 00000000 00000000 00000000 00000000 00000000<br /> 1ea0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> 1ec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> 1ee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> 1f00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> 1f20: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> 1f40: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> 1f60: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000<br /> 1f80: 00000000 00000000 00000000 0347d2a8 00000002 00000004 00000078 00000058<br /> 1fa0: c010028c c0100060 00000002 00000004 fee1dead 28121969 01234567 00079028<br /> 1fc0: 00000002 00000004 00000078 00000058 0002fdc5 00000000 00000000 00090acc<br /> 1fe0: 00000058 becc9c64 b6e97e05 b6e0e5f6 600e0030 fee1dead 00000000 00000000<br /> msm_atomic_commit_tail from commit_tail+0x9c/0x188<br /> commit_tail from drm_atomic_helper_commit+0x160/0x188<br /> drm_atomic_helper_commit from drm_atomic_commit+0xac/0xe0<br /> drm_atomic_commit from drm_atomic_helper_disable_all+0x1b0/0x1c0<br /> drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x88/0x140<br /> drm_atomic_helper_shutdown from device_shutdown+0x16c/0x240<br /> device_shutdown from kernel_restart+0x38/0x90<br /> kernel_restart from __do_sys_reboot+0x<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Fix potential memory leak in ice_gnss_tty_write()<br /> <br /> The ice_gnss_tty_write() return directly if the write_buf alloc failed,<br /> leaking the cmd_buf.<br /> <br /> Fix by free cmd_buf if write_buf alloc failed.