Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: ipheth: fix DPE OoB read<br /> <br /> Fix an out-of-bounds DPE read, limit the number of processed DPEs to<br /> the amount that fits into the fixed-size NDP16 header.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: ipheth: use static NDP16 location in URB<br /> <br /> Original code allowed for the start of NDP16 to be anywhere within the<br /> URB based on the `wNdpIndex` value in NTH16. Only the start position of<br /> NDP16 was checked, so it was possible for even the fixed-length part<br /> of NDP16 to extend past the end of URB, leading to an out-of-bounds<br /> read.<br /> <br /> On iOS devices, the NDP16 header always directly follows NTH16. Rely on<br /> and check for this specific format.<br /> <br /> This, along with NCM-specific minimal URB length check that already<br /> exists, will ensure that the fixed-length part of NDP16 plus a set<br /> amount of DPEs fit within the URB.<br /> <br /> Note that this commit alone does not fully address the OoB read.<br /> The limit on the amount of DPEs needs to be enforced separately.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: ipheth: fix possible overflow in DPE length check<br /> <br /> Originally, it was possible for the DPE length check to overflow if<br /> wDatagramIndex + wDatagramLength &gt; U16_MAX. This could lead to an OoB<br /> read.<br /> <br /> Move the wDatagramIndex term to the other side of the inequality.<br /> <br /> An existing condition ensures that wDatagramIndex actual_length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Fix copy buffer page size<br /> <br /> For non-registered buffer, fastrpc driver copies the buffer and<br /> pass it to the remote subsystem. There is a problem with current<br /> implementation of page size calculation which is not considering<br /> the offset in the calculation. This might lead to passing of<br /> improper and out-of-bounds page size which could result in<br /> memory issue. Calculate page start and page end using the offset<br /> adjusted address instead of absolute address.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix possible int overflows in nilfs_fiemap()<br /> <br /> Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result<br /> by being prepared to go through potentially maxblocks == INT_MAX blocks,<br /> the value in n may experience an overflow caused by left shift of blkbits.<br /> <br /> While it is extremely unlikely to occur, play it safe and cast right hand<br /> expression to wider type to mitigate the issue.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with static analysis<br /> tool SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: libata-sff: Ensure that we cannot write outside the allocated buffer<br /> <br /> reveliofuzzing reported that a SCSI_IOCTL_SEND_COMMAND ioctl with out_len<br /> set to 0xd42, SCSI command set to ATA_16 PASS-THROUGH, ATA command set to<br /> ATA_NOP, and protocol set to ATA_PROT_PIO, can cause ata_pio_sector() to<br /> write outside the allocated buffer, overwriting random memory.<br /> <br /> While a ATA device is supposed to abort a ATA_NOP command, there does seem<br /> to be a bug either in libata-sff or QEMU, where either this status is not<br /> set, or the status is cleared before read by ata_sff_hsm_move().<br /> Anyway, that is most likely a separate bug.<br /> <br /> Looking at __atapi_pio_bytes(), it already has a safety check to ensure<br /> that __atapi_pio_bytes() cannot write outside the allocated buffer.<br /> <br /> Add a similar check to ata_pio_sector(), such that also ata_pio_sector()<br /> cannot write outside the allocated buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Fix use-after free in init error and remove paths<br /> <br /> devm_blk_crypto_profile_init() registers a cleanup handler to run when<br /> the associated (platform-) device is being released. For UFS, the<br /> crypto private data and pointers are stored as part of the ufs_hba&amp;#39;s<br /> data structure &amp;#39;struct ufs_hba::crypto_profile&amp;#39;. This structure is<br /> allocated as part of the underlying ufshcd and therefore Scsi_host<br /> allocation.<br /> <br /> During driver release or during error handling in ufshcd_pltfrm_init(),<br /> this structure is released as part of ufshcd_dealloc_host() before the<br /> (platform-) device associated with the crypto call above is released.<br /> Once this device is released, the crypto cleanup code will run, using<br /> the just-released &amp;#39;struct ufs_hba::crypto_profile&amp;#39;. This causes a<br /> use-after-free situation:<br /> <br /> Call trace:<br /> kfree+0x60/0x2d8 (P)<br /> kvfree+0x44/0x60<br /> blk_crypto_profile_destroy_callback+0x28/0x70<br /> devm_action_release+0x1c/0x30<br /> release_nodes+0x6c/0x108<br /> devres_release_all+0x98/0x100<br /> device_unbind_cleanup+0x20/0x70<br /> really_probe+0x218/0x2d0<br /> <br /> In other words, the initialisation code flow is:<br /> <br /> platform-device probe<br /> ufshcd_pltfrm_init()<br /> ufshcd_alloc_host()<br /> scsi_host_alloc()<br /> allocation of struct ufs_hba<br /> creation of scsi-host devices<br /> devm_blk_crypto_profile_init()<br /> devm registration of cleanup handler using platform-device<br /> <br /> and during error handling of ufshcd_pltfrm_init() or during driver<br /> removal:<br /> <br /> ufshcd_dealloc_host()<br /> scsi_host_put()<br /> put_device(scsi-host)<br /> release of struct ufs_hba<br /> put_device(platform-device)<br /> crypto cleanup handler<br /> <br /> To fix this use-after free, change ufshcd_alloc_host() to register a<br /> devres action to automatically cleanup the underlying SCSI device on<br /> ufshcd destruction, without requiring explicit calls to<br /> ufshcd_dealloc_host(). This way:<br /> <br /> * the crypto profile and all other ufs_hba-owned resources are<br /> destroyed before SCSI (as they&amp;#39;ve been registered after)<br /> * a memleak is plugged in tc-dwc-g210-pci.c remove() as a<br /> side-effect<br /> * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as<br /> it&amp;#39;s not needed anymore<br /> * no future drivers using ufshcd_alloc_host() could ever forget<br /> adding the cleanup

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFC: nci: Add bounds checking in nci_hci_create_pipe()<br /> <br /> The "pipe" variable is a u8 which comes from the network. If it&amp;#39;s more<br /> than 127, then it results in memory corruption in the caller,<br /> nci_hci_connect_gate().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error<br /> <br /> This patch addresses a race condition for an ODP MR that can result in a<br /> CQE with an error on the UMR QP.<br /> <br /> During the __mlx5_ib_dereg_mr() flow, the following sequence of calls<br /> occurs:<br /> <br /> mlx5_revoke_mr()<br /> mlx5r_umr_revoke_mr()<br /> mlx5r_umr_post_send_wait()<br /> <br /> At this point, the lkey is freed from the hardware&amp;#39;s perspective.<br /> <br /> However, concurrently, mlx5_ib_invalidate_range() might be triggered by<br /> another task attempting to invalidate a range for the same freed lkey.<br /> <br /> This task will:<br /> - Acquire the umem_odp-&gt;umem_mutex lock.<br /> - Call mlx5r_umr_update_xlt() on the UMR QP.<br /> - Since the lkey has already been freed, this can lead to a CQE error,<br /> causing the UMR QP to enter an error state [1].<br /> <br /> To resolve this race condition, the umem_odp-&gt;umem_mutex lock is now also<br /> acquired as part of the mlx5_revoke_mr() scope. Upon successful revoke,<br /> we set umem_odp-&gt;private which points to that MR to NULL, preventing any<br /> further invalidation attempts on its lkey.<br /> <br /> [1] From dmesg:<br /> <br /> infiniband rocep8s0f0: dump_cqe:277:(pid 0): WC error: 6, Message: memory bind operation error<br /> cqe_dump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> cqe_dump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> cqe_dump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2<br /> <br /> WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib]<br /> Modules linked in: ip6table_mangle ip6table_natip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core<br /> CPU: 15 UID: 0 PID: 1506 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1626<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib]<br /> [..]<br /> Call Trace:<br /> <br /> mlx5r_umr_update_xlt+0x23c/0x3e0 [mlx5_ib]<br /> mlx5_ib_invalidate_range+0x2e1/0x330 [mlx5_ib]<br /> __mmu_notifier_invalidate_range_start+0x1e1/0x240<br /> zap_page_range_single+0xf1/0x1a0<br /> madvise_vma_behavior+0x677/0x6e0<br /> do_madvise+0x1a2/0x4b0<br /> __x64_sys_madvise+0x25/0x30<br /> do_syscall_64+0x6b/0x140<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/osnoise: Fix resetting of tracepoints<br /> <br /> If a timerlat tracer is started with the osnoise option OSNOISE_WORKLOAD<br /> disabled, but then that option is enabled and timerlat is removed, the<br /> tracepoints that were enabled on timerlat registration do not get<br /> disabled. If the option is disabled again and timelat is started, then it<br /> triggers a warning in the tracepoint code due to registering the<br /> tracepoint again without ever disabling it.<br /> <br /> Do not use the same user space defined options to know to disable the<br /> tracepoints when timerlat is removed. Instead, set a global flag when it<br /> is enabled and use that flag to know to disable the events.<br /> <br /> ~# echo NO_OSNOISE_WORKLOAD &gt; /sys/kernel/tracing/osnoise/options<br /> ~# echo timerlat &gt; /sys/kernel/tracing/current_tracer<br /> ~# echo OSNOISE_WORKLOAD &gt; /sys/kernel/tracing/osnoise/options<br /> ~# echo nop &gt; /sys/kernel/tracing/current_tracer<br /> ~# echo NO_OSNOISE_WORKLOAD &gt; /sys/kernel/tracing/osnoise/options<br /> ~# echo timerlat &gt; /sys/kernel/tracing/current_tracer<br /> <br /> Triggers:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 6 PID: 1337 at kernel/tracepoint.c:294 tracepoint_add_func+0x3b6/0x3f0<br /> Modules linked in:<br /> CPU: 6 UID: 0 PID: 1337 Comm: rtla Not tainted 6.13.0-rc4-test-00018-ga867c441128e-dirty #73<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:tracepoint_add_func+0x3b6/0x3f0<br /> Code: 48 8b 53 28 48 8b 73 20 4c 89 04 24 e8 23 59 11 00 4c 8b 04 24 e9 36 fe ff ff 0f 0b b8 ea ff ff ff 45 84 e4 0f 84 68 fe ff ff 0b e9 61 fe ff ff 48 8b 7b 18 48 85 ff 0f 84 4f ff ff ff 49 8b<br /> RSP: 0018:ffffb9b003a87ca0 EFLAGS: 00010202<br /> RAX: 00000000ffffffef RBX: ffffffff92f30860 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffff9bf59e91ccd0 RDI: ffffffff913b6410<br /> RBP: 000000000000000a R08: 00000000000005c7 R09: 0000000000000002<br /> R10: ffffb9b003a87ce0 R11: 0000000000000002 R12: 0000000000000001<br /> R13: ffffb9b003a87ce0 R14: ffffffffffffffef R15: 0000000000000008<br /> FS: 00007fce81209240(0000) GS:ffff9bf6fdd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055e99b728000 CR3: 00000001277c0002 CR4: 0000000000172ef0<br /> Call Trace:<br /> <br /> ? __warn.cold+0xb7/0x14d<br /> ? tracepoint_add_func+0x3b6/0x3f0<br /> ? report_bug+0xea/0x170<br /> ? handle_bug+0x58/0x90<br /> ? exc_invalid_op+0x17/0x70<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? __pfx_trace_sched_migrate_callback+0x10/0x10<br /> ? tracepoint_add_func+0x3b6/0x3f0<br /> ? __pfx_trace_sched_migrate_callback+0x10/0x10<br /> ? __pfx_trace_sched_migrate_callback+0x10/0x10<br /> tracepoint_probe_register+0x78/0xb0<br /> ? __pfx_trace_sched_migrate_callback+0x10/0x10<br /> osnoise_workload_start+0x2b5/0x370<br /> timerlat_tracer_init+0x76/0x1b0<br /> tracing_set_tracer+0x244/0x400<br /> tracing_set_trace_write+0xa0/0xe0<br /> vfs_write+0xfc/0x570<br /> ? do_sys_openat2+0x9c/0xe0<br /> ksys_write+0x72/0xf0<br /> do_syscall_64+0x79/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: winwing: Add NULL check in winwing_init_led()<br /> <br /> devm_kasprintf() can return a NULL pointer on failure,but this<br /> returned value in winwing_init_led() is not checked.<br /> Add NULL check in winwing_init_led(), to handle kernel NULL<br /> pointer dereference error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvkm/gsp: correctly advance the read pointer of GSP message queue<br /> <br /> A GSP event message consists three parts: message header, RPC header,<br /> message body. GSP calculates the number of pages to write from the<br /> total size of a GSP message. This behavior can be observed from the<br /> movement of the write pointer.<br /> <br /> However, nvkm takes only the size of RPC header and message body as<br /> the message size when advancing the read pointer. When handling a<br /> two-page GSP message in the non rollback case, It wrongly takes the<br /> message body of the previous message as the message header of the next<br /> message. As the "message length" tends to be zero, in the calculation of<br /> size needs to be copied (0 - size of (message header)), the size needs to<br /> be copied will be "0xffffffxx". It also triggers a kernel panic due to a<br /> NULL pointer error.<br /> <br /> [ 547.614102] msg: 00000f90: ff ff ff ff ff ff ff ff 40 d7 18 fb 8b 00 00 00 ........@.......<br /> [ 547.622533] msg: 00000fa0: 00 00 00 00 ff ff ff ff ff ff ff ff 00 00 00 00 ................<br /> [ 547.630965] msg: 00000fb0: ff ff ff ff ff ff ff ff 00 00 00 00 ff ff ff ff ................<br /> [ 547.639397] msg: 00000fc0: ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff ................<br /> [ 547.647832] nvkm 0000:c1:00.0: gsp: peek msg rpc fn:0 len:0x0/0xffffffffffffffe0<br /> [ 547.655225] nvkm 0000:c1:00.0: gsp: get msg rpc fn:0 len:0x0/0xffffffffffffffe0<br /> [ 547.662532] BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> [ 547.669485] #PF: supervisor read access in kernel mode<br /> [ 547.674624] #PF: error_code(0x0000) - not-present page<br /> [ 547.679755] PGD 0 P4D 0<br /> [ 547.682294] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 547.686643] CPU: 22 PID: 322 Comm: kworker/22:1 Tainted: G E 6.9.0-rc6+ #1<br /> [ 547.694893] Hardware name: ASRockRack 1U1G-MILAN/N/ROMED8-NL, BIOS L3.12E 09/06/2022<br /> [ 547.702626] Workqueue: events r535_gsp_msgq_work [nvkm]<br /> [ 547.707921] RIP: 0010:r535_gsp_msg_recv+0x87/0x230 [nvkm]<br /> [ 547.713375] Code: 00 8b 70 08 48 89 e1 31 d2 4c 89 f7 e8 12 f5 ff ff 48 89 c5 48 85 c0 0f 84 cf 00 00 00 48 81 fd 00 f0 ff ff 0f 87 c4 00 00 00 55 10 41 8b 46 30 85 d2 0f 85 f6 00 00 00 83 f8 04 76 10 ba 05<br /> [ 547.732119] RSP: 0018:ffffabe440f87e10 EFLAGS: 00010203<br /> [ 547.737335] RAX: 0000000000000010 RBX: 0000000000000008 RCX: 000000000000003f<br /> [ 547.744461] RDX: 0000000000000000 RSI: ffffabe4480a8030 RDI: 0000000000000010<br /> [ 547.751585] RBP: 0000000000000010 R08: 0000000000000000 R09: ffffabe440f87bb0<br /> [ 547.758707] R10: ffffabe440f87dc8 R11: 0000000000000010 R12: 0000000000000000<br /> [ 547.765834] R13: 0000000000000000 R14: ffff9351df1e5000 R15: 0000000000000000<br /> [ 547.772958] FS: 0000000000000000(0000) GS:ffff93708eb00000(0000) knlGS:0000000000000000<br /> [ 547.781035] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 547.786771] CR2: 0000000000000020 CR3: 00000003cc220002 CR4: 0000000000770ef0<br /> [ 547.793896] PKRU: 55555554<br /> [ 547.796600] Call Trace:<br /> [ 547.799046] <br /> [ 547.801152] ? __die+0x20/0x70<br /> [ 547.804211] ? page_fault_oops+0x75/0x170<br /> [ 547.808221] ? print_hex_dump+0x100/0x160<br /> [ 547.812226] ? exc_page_fault+0x64/0x150<br /> [ 547.816152] ? asm_exc_page_fault+0x22/0x30<br /> [ 547.820341] ? r535_gsp_msg_recv+0x87/0x230 [nvkm]<br /> [ 547.825184] r535_gsp_msgq_work+0x42/0x50 [nvkm]<br /> [ 547.829845] process_one_work+0x196/0x3d0<br /> [ 547.833861] worker_thread+0x2fc/0x410<br /> [ 547.837613] ? __pfx_worker_thread+0x10/0x10<br /> [ 547.841885] kthread+0xdf/0x110<br /> [ 547.845031] ? __pfx_kthread+0x10/0x10<br /> [ 547.848775] ret_from_fork+0x30/0x50<br /> [ 547.852354] ? __pfx_kthread+0x10/0x10<br /> [ 547.856097] ret_from_fork_asm+0x1a/0x30<br /> [ 547.860019] <br /> [ 547.862208] Modules linked in: nvkm(E) gsp_log(E) snd_seq_dummy(E) snd_hrtimer(E) snd_seq(E) snd_timer(E) snd_seq_device(E) snd(E) soundcore(E) rfkill(E) qrtr(E) vfat(E) fat(E) ipmi_ssif(E) amd_atl(E) intel_rapl_msr(E) intel_rapl_common(E) amd64_edac(E) mlx5_ib(E) edac_mce_amd(E) kvm_amd<br /> ---truncated---