Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Check &amp;#39;folio&amp;#39; pointer for NULL<br /> <br /> It can be NULL if bmap is called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse: clear FR_SENT when re-adding requests into pending list<br /> <br /> The following warning was reported by lee bruce:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 8264 at fs/fuse/dev.c:300<br /> fuse_request_end+0x685/0x7e0 fs/fuse/dev.c:300<br /> Modules linked in:<br /> CPU: 0 PID: 8264 Comm: ab2 Not tainted 6.9.0-rc7<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> RIP: 0010:fuse_request_end+0x685/0x7e0 fs/fuse/dev.c:300<br /> ......<br /> Call Trace:<br /> <br /> fuse_dev_do_read.constprop.0+0xd36/0x1dd0 fs/fuse/dev.c:1334<br /> fuse_dev_read+0x166/0x200 fs/fuse/dev.c:1367<br /> call_read_iter include/linux/fs.h:2104 [inline]<br /> new_sync_read fs/read_write.c:395 [inline]<br /> vfs_read+0x85b/0xba0 fs/read_write.c:476<br /> ksys_read+0x12f/0x260 fs/read_write.c:619<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xce/0x260 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> ......<br /> <br /> <br /> The warning is due to the FUSE_NOTIFY_RESEND notify sent by the write()<br /> syscall in the reproducer program and it happens as follows:<br /> <br /> (1) calls fuse_dev_read() to read the INIT request<br /> The read succeeds. During the read, bit FR_SENT will be set on the<br /> request.<br /> (2) calls fuse_dev_write() to send an USE_NOTIFY_RESEND notify<br /> The resend notify will resend all processing requests, so the INIT<br /> request is moved from processing list to pending list again.<br /> (3) calls fuse_dev_read() with an invalid output address<br /> fuse_dev_read() will try to copy the same INIT request to the output<br /> address, but it will fail due to the invalid address, so the INIT<br /> request is ended and triggers the warning in fuse_request_end().<br /> <br /> Fix it by clearing FR_SENT when re-adding requests into pending list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind.<br /> <br /> Hang on to the control IDs instead of pointers since those are correctly<br /> handled with locks.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Avoid unnecessary destruction of file_ida<br /> <br /> file_ida is allocated during cdev open and is freed accordingly<br /> during cdev release. This sequence is guaranteed by driver file<br /> operations. Therefore, there is no need to destroy an already empty<br /> file_ida when the WQ cdev is removed.<br /> <br /> Worse, ida_free() in cdev release may happen after destruction of<br /> file_ida per WQ cdev. This can lead to accessing an id in file_ida<br /> after it has been destroyed, resulting in a kernel panic.<br /> <br /> Remove ida_destroy(&amp;file_ida) to address these issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger<br /> <br /> When the cpu5wdt module is removing, the origin code uses del_timer() to<br /> de-activate the timer. If the timer handler is running, del_timer() could<br /> not stop it and will return directly. If the port region is released by<br /> release_region() and then the timer handler cpu5wdt_trigger() calls outb()<br /> to write into the region that is released, the use-after-free bug will<br /> happen.<br /> <br /> Change del_timer() to timer_shutdown_sync() in order that the timer handler<br /> could be finished before the port region is released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: PAC1934: fix accessing out of bounds array index<br /> <br /> Fix accessing out of bounds array index for average<br /> current and voltage measurements. The device itself has<br /> only 4 channels, but in sysfs there are "fake"<br /> channels for the average voltages and currents too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/pci: fix potential memory leak in vfio_intx_enable()<br /> <br /> If vfio_irq_ctx_alloc() failed will lead to &amp;#39;name&amp;#39; memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: stk1160: fix bounds checking in stk1160_copy_video()<br /> <br /> The subtract in this condition is reversed. The -&gt;length is the length<br /> of the buffer. The -&gt;bytesused is how many bytes we have copied thus<br /> far. When the condition is reversed that means the result of the<br /> subtraction is always negative but since it&amp;#39;s unsigned then the result<br /> is a very high positive value. That means the overflow check is never<br /> true.<br /> <br /> Additionally, the -&gt;bytesused doesn&amp;#39;t actually work for this purpose<br /> because we&amp;#39;re not writing to "buf-&gt;mem + buf-&gt;bytesused". Instead, the<br /> math to calculate the destination where we are writing is a bit<br /> involved. You calculate the number of full lines already written,<br /> multiply by two, skip a line if necessary so that we start on an odd<br /> numbered line, and add the offset into the line.<br /> <br /> To fix this buffer overflow, just take the actual destination where we<br /> are writing, if the offset is already out of bounds print an error and<br /> return. Otherwise, write up to buf-&gt;length bytes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> stm class: Fix a double free in stm_register_device()<br /> <br /> The put_device(&amp;stm-&gt;dev) call will trigger stm_device_release() which<br /> frees "stm" so the vfree(stm) on the next line is a double free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: tproxy: bail out if IP has been disabled on the device<br /> <br /> syzbot reports:<br /> general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]<br /> [..]<br /> RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62<br /> Call Trace:<br /> nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline]<br /> nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168<br /> <br /> __in_dev_get_rcu() can return NULL, so check for this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Use mlx5_ipsec_rx_status_destroy to correctly delete status rules<br /> <br /> rx_create no longer allocates a modify_hdr instance that needs to be<br /> cleaned up. The mlx5_modify_header_dealloc call will lead to a NULL pointer<br /> dereference. A leak in the rules also previously occurred since there are<br /> now two rules populated related to status.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 109907067 P4D 109907067 PUD 116890067 PMD 0<br /> Oops: 0000 [#1] SMP<br /> CPU: 1 PID: 484 Comm: ip Not tainted 6.9.0-rc2-rrameshbabu+ #254<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Arch Linux 1.16.3-1-1 04/01/2014<br /> RIP: 0010:mlx5_modify_header_dealloc+0xd/0x70<br /> <br /> Call Trace:<br /> <br /> ? show_regs+0x60/0x70<br /> ? __die+0x24/0x70<br /> ? page_fault_oops+0x15f/0x430<br /> ? free_to_partial_list.constprop.0+0x79/0x150<br /> ? do_user_addr_fault+0x2c9/0x5c0<br /> ? exc_page_fault+0x63/0x110<br /> ? asm_exc_page_fault+0x27/0x30<br /> ? mlx5_modify_header_dealloc+0xd/0x70<br /> rx_create+0x374/0x590<br /> rx_add_rule+0x3ad/0x500<br /> ? rx_add_rule+0x3ad/0x500<br /> ? mlx5_cmd_exec+0x2c/0x40<br /> ? mlx5_create_ipsec_obj+0xd6/0x200<br /> mlx5e_accel_ipsec_fs_add_rule+0x31/0xf0<br /> mlx5e_xfrm_add_state+0x426/0xc00<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: relax socket state check at accept time.<br /> <br /> Christoph reported the following splat:<br /> <br /> WARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0<br /> Modules linked in:<br /> CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014<br /> RIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759<br /> Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80<br /> RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293<br /> RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64<br /> R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000<br /> R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800<br /> FS: 000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786<br /> do_accept+0x435/0x620 net/socket.c:1929<br /> __sys_accept4_file net/socket.c:1969 [inline]<br /> __sys_accept4+0x9b/0x110 net/socket.c:1999<br /> __do_sys_accept net/socket.c:2016 [inline]<br /> __se_sys_accept net/socket.c:2013 [inline]<br /> __x64_sys_accept+0x7d/0x90 net/socket.c:2013<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x4315f9<br /> Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00<br /> RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002b<br /> RAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004<br /> RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300<br /> R10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055<br /> <br /> <br /> The reproducer invokes shutdown() before entering the listener status.<br /> After commit 94062790aedb ("tcp: defer shutdown(SEND_SHUTDOWN) for<br /> TCP_SYN_RECV sockets"), the above causes the child to reach the accept<br /> syscall in FIN_WAIT1 status.<br /> <br /> Eric noted we can relax the existing assertion in __inet_accept()