Vulnerabilities

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---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params<br /> <br /> Each cpu DAI should associate with a widget. However, the topology might<br /> not create the right number of DAI widgets for aggregated amps. And it<br /> will cause NULL pointer deference.<br /> Check that the DAI widget associated with the CPU DAI is valid to prevent<br /> NULL pointer deference due to missing DAI widgets in topologies with<br /> aggregated amps.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Fix for out-of bound access error<br /> <br /> Selfgen stats are placed in a buffer using print_array_to_buf_index() function.<br /> Array length parameter passed to the function is too big, resulting in possible<br /> out-of bound memory error.<br /> Decreasing buffer size by one fixes faulty upper bound of passed array.<br /> <br /> Discovered in coverity scan, CID 1600742 and CID 1600758

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvkm: correctly calculate the available space of the GSP cmdq buffer<br /> <br /> r535_gsp_cmdq_push() waits for the available page in the GSP cmdq<br /> buffer when handling a large RPC request. When it sees at least one<br /> available page in the cmdq, it quits the waiting with the amount of<br /> free buffer pages in the queue.<br /> <br /> Unfortunately, it always takes the [write pointer, buf_size) as<br /> available buffer pages before rolling back and wrongly calculates the<br /> size of the data should be copied. Thus, it can overwrite the RPC<br /> request that GSP is currently reading, which causes GSP hang due<br /> to corrupted RPC request:<br /> <br /> [ 549.209389] ------------[ cut here ]------------<br /> [ 549.214010] WARNING: CPU: 8 PID: 6314 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c:116 r535_gsp_msgq_wait+0xd0/0x190 [nvkm]<br /> [ 549.225678] 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) mlx5_ib(E) amd64_edac(E) edac_mce_amd(E) kvm_amd(E) ib_uverbs(E) kvm(E) ib_core(E) acpi_ipmi(E) ipmi_si(E) mxm_wmi(E) ipmi_devintf(E) rapl(E) i2c_piix4(E) wmi_bmof(E) joydev(E) ptdma(E) acpi_cpufreq(E) k10temp(E) pcspkr(E) ipmi_msghandler(E) xfs(E) libcrc32c(E) ast(E) i2c_algo_bit(E) crct10dif_pclmul(E) drm_shmem_helper(E) nvme_tcp(E) crc32_pclmul(E) ahci(E) drm_kms_helper(E) libahci(E) nvme_fabrics(E) crc32c_intel(E) nvme(E) cdc_ether(E) mlx5_core(E) nvme_core(E) usbnet(E) drm(E) libata(E) ccp(E) ghash_clmulni_intel(E) mii(E) t10_pi(E) mlxfw(E) sp5100_tco(E) psample(E) pci_hyperv_intf(E) wmi(E) dm_multipath(E) sunrpc(E) dm_mirror(E) dm_region_hash(E) dm_log(E) dm_mod(E) be2iscsi(E) bnx2i(E) cnic(E) uio(E) cxgb4i(E) cxgb4(E) tls(E) libcxgbi(E) libcxgb(E) qla4xxx(E)<br /> [ 549.225752] iscsi_boot_sysfs(E) iscsi_tcp(E) libiscsi_tcp(E) libiscsi(E) scsi_transport_iscsi(E) fuse(E) [last unloaded: gsp_log(E)]<br /> [ 549.326293] CPU: 8 PID: 6314 Comm: insmod Tainted: G E 6.9.0-rc6+ #1<br /> [ 549.334039] Hardware name: ASRockRack 1U1G-MILAN/N/ROMED8-NL, BIOS L3.12E 09/06/2022<br /> [ 549.341781] RIP: 0010:r535_gsp_msgq_wait+0xd0/0x190 [nvkm]<br /> [ 549.347343] Code: 08 00 00 89 da c1 e2 0c 48 8d ac 11 00 10 00 00 48 8b 0c 24 48 85 c9 74 1f c1 e0 0c 4c 8d 6d 30 83 e8 30 89 01 e9 68 ff ff ff 0b 49 c7 c5 92 ff ff ff e9 5a ff ff ff ba ff ff ff ff be c0 0c<br /> [ 549.366090] RSP: 0018:ffffacbccaaeb7d0 EFLAGS: 00010246<br /> [ 549.371315] RAX: 0000000000000000 RBX: 0000000000000012 RCX: 0000000000923e28<br /> [ 549.378451] RDX: 0000000000000000 RSI: 0000000055555554 RDI: ffffacbccaaeb730<br /> [ 549.385590] RBP: 0000000000000001 R08: ffff8bd14d235f70 R09: ffff8bd14d235f70<br /> [ 549.392721] R10: 0000000000000002 R11: ffff8bd14d233864 R12: 0000000000000020<br /> [ 549.399854] R13: ffffacbccaaeb818 R14: 0000000000000020 R15: ffff8bb298c67000<br /> [ 549.406988] FS: 00007f5179244740(0000) GS:ffff8bd14d200000(0000) knlGS:0000000000000000<br /> [ 549.415076] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 549.420829] CR2: 00007fa844000010 CR3: 00000001567dc005 CR4: 0000000000770ef0<br /> [ 549.427963] PKRU: 55555554<br /> [ 549.430672] Call Trace:<br /> [ 549.433126] <br /> [ 549.435233] ? __warn+0x7f/0x130<br /> [ 549.438473] ? r535_gsp_msgq_wait+0xd0/0x190 [nvkm]<br /> [ 549.443426] ? report_bug+0x18a/0x1a0<br /> [ 549.447098] ? handle_bug+0x3c/0x70<br /> [ 549.450589] ? exc_invalid_op+0x14/0x70<br /> [ 549.454430] ? asm_exc_invalid_op+0x16/0x20<br /> [ 549.458619] ? r535_gsp_msgq_wait+0xd0/0x190 [nvkm]<br /> [ 549.463565] r535_gsp_msg_recv+0x46/0x230 [nvkm]<br /> [ 549.468257] r535_gsp_rpc_push+0x106/0x160 [nvkm]<br /> [ 549.473033] r535_gsp_rpc_rm_ctrl_push+0x40/0x130 [nvkm]<br /> [ 549.478422] nvidia_grid_init_vgpu_types+0xbc/0xe0 [nvkm]<br /> [ 549.483899] nvidia_grid_init+0xb1/0xd0 [nvkm]<br /> [ 549.488420] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 549.493213] nvkm_device_pci_probe+0x305/0x420 [nvkm]<br /> [ 549.498338] local_pci_probe+0x46/<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: int3472: Check for adev == NULL<br /> <br /> Not all devices have an ACPI companion fwnode, so adev might be NULL. This<br /> can e.g. (theoretically) happen when a user manually binds one of<br /> the int3472 drivers to another i2c/platform device through sysfs.<br /> <br /> Add a check for adev not being set and return -ENODEV in that case to<br /> avoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: Fix slab-use-after-free Read in mgmt_remove_adv_monitor_sync<br /> <br /> This fixes the following crash:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543<br /> Read of size 8 at addr ffff88814128f898 by task kworker/u9:4/5961<br /> <br /> CPU: 1 UID: 0 PID: 5961 Comm: kworker/u9:4 Not tainted 6.12.0-syzkaller-10684-gf1cd565ce577 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Workqueue: hci0 hci_cmd_sync_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:489<br /> kasan_report+0x143/0x180 mm/kasan/report.c:602<br /> mgmt_remove_adv_monitor_sync+0x3a/0xd0 net/bluetooth/mgmt.c:5543<br /> hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332<br /> process_one_work kernel/workqueue.c:3229 [inline]<br /> process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310<br /> worker_thread+0x870/0xd30 kernel/workqueue.c:3391<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> <br /> Allocated by task 16026:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:377 [inline]<br /> __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394<br /> kasan_kmalloc include/linux/kasan.h:260 [inline]<br /> __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4314<br /> kmalloc_noprof include/linux/slab.h:901 [inline]<br /> kzalloc_noprof include/linux/slab.h:1037 [inline]<br /> mgmt_pending_new+0x65/0x250 net/bluetooth/mgmt_util.c:269<br /> mgmt_pending_add+0x36/0x120 net/bluetooth/mgmt_util.c:296<br /> remove_adv_monitor+0x102/0x1b0 net/bluetooth/mgmt.c:5568<br /> hci_mgmt_cmd+0xc47/0x11d0 net/bluetooth/hci_sock.c:1712<br /> hci_sock_sendmsg+0x7b8/0x11c0 net/bluetooth/hci_sock.c:1832<br /> sock_sendmsg_nosec net/socket.c:711 [inline]<br /> __sock_sendmsg+0x221/0x270 net/socket.c:726<br /> sock_write_iter+0x2d7/0x3f0 net/socket.c:1147<br /> new_sync_write fs/read_write.c:586 [inline]<br /> vfs_write+0xaeb/0xd30 fs/read_write.c:679<br /> ksys_write+0x18f/0x2b0 fs/read_write.c:731<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 16022:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582<br /> poison_slab_object mm/kasan/common.c:247 [inline]<br /> __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264<br /> kasan_slab_free include/linux/kasan.h:233 [inline]<br /> slab_free_hook mm/slub.c:2338 [inline]<br /> slab_free mm/slub.c:4598 [inline]<br /> kfree+0x196/0x420 mm/slub.c:4746<br /> mgmt_pending_foreach+0xd1/0x130 net/bluetooth/mgmt_util.c:259<br /> __mgmt_power_off+0x183/0x430 net/bluetooth/mgmt.c:9550<br /> hci_dev_close_sync+0x6c4/0x11c0 net/bluetooth/hci_sync.c:5208<br /> hci_dev_do_close net/bluetooth/hci_core.c:483 [inline]<br /> hci_dev_close+0x112/0x210 net/bluetooth/hci_core.c:508<br /> sock_do_ioctl+0x158/0x460 net/socket.c:1209<br /> sock_ioctl+0x626/0x8e0 net/socket.c:1328<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:906 [inline]<br /> __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmsmac: add gain range check to wlc_phy_iqcal_gainparams_nphy()<br /> <br /> In &amp;#39;wlc_phy_iqcal_gainparams_nphy()&amp;#39;, add gain range check to WARN()<br /> instead of possible out-of-bounds &amp;#39;tbl_iqcal_gainparams_nphy&amp;#39; access.<br /> Compile tested only.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.