Page 152 of 3010 results (0.007 seconds)

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: sof-nau8825: fix module alias overflow The maximum name length for a platform_device_id entry is 20 characters including the trailing NUL byte. The sof_nau8825.c file exceeds that, which causes an obscure error message: sound/soc/intel/boards/snd-soc-sof_nau8825.mod.c:35:45: error: illegal character encoding in string literal [-Werror,-Winvalid-source-encoding] MODULE_ALIAS("platform:adl_max98373_nau8825<U+0018><AA>"); ^~~~ include/linux/module.h:168:49: note: expanded from macro 'MODULE_ALIAS' ^~~~~~ include/linux/module.h:165:56: note: expanded from macro 'MODULE_INFO' ^~~~ include/linux/moduleparam.h:26:47: note: expanded from macro '__MODULE_INFO' = __MODULE_INFO_PREFIX __stringify(tag) "=" info I could not figure out how to make the module handling robust enough to handle this better, but as a quick fix, using slightly shorter names that are still unique avoids the build issue. • https://git.kernel.org/stable/c/8d0872f6239f9d067d538d8368bdec643bb0d255 https://git.kernel.org/stable/c/fba1b23befd88366fe646787b3797e64d7338fd2 https://git.kernel.org/stable/c/3e78986a840d59dd27e636eae3f52dc11125c835 •

CVSS: -EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Remove rcu locks from user resources User resource lookups used rcu to avoid two extra atomics. Unfortunately the rcu paths were buggy and it was easy to make the driver crash by submitting command buffers from two different threads. Because the lookups never show up in performance profiles replace them with a regular spin lock which fixes the races in accesses to those shared resources. Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and seen crashes with apps using shared resources. • https://git.kernel.org/stable/c/e14c02e6b6990e9f6ee18a214a22ac26bae1b25e https://git.kernel.org/stable/c/7ac9578e45b20e3f3c0c8eb71f5417a499a7226a https://git.kernel.org/stable/c/a309c7194e8a2f8bd4539b9449917913f6c2cd50 •

CVSS: 6.6EPSS: 0%CPEs: 2EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: IPoIB, Block PKEY interfaces with less rx queues than parent A user is able to configure an arbitrary number of rx queues when creating an interface via netlink. This doesn't work for child PKEY interfaces because the child interface uses the parent receive channels. Although the child shares the parent's receive channels, the number of rx queues is important for the channel_stats array: the parent's rx channel index is used to access the child's channel_stats. So the array has to be at least as large as the parent's rx queue size for the counting to work correctly and to prevent out of bound accesses. This patch checks for the mentioned scenario and returns an error when trying to create the interface. The error is propagated to the user. • https://git.kernel.org/stable/c/be98737a4faa3a0dc1781ced5bbf5c47865e29d7 https://git.kernel.org/stable/c/5844a46f09f768da866d6b0ffbf1a9073266bf24 https://git.kernel.org/stable/c/31c70bfe58ef09fe36327ddcced9143a16e9e83d https://access.redhat.com/security/cve/CVE-2022-48883 https://bugzilla.redhat.com/show_bug.cgi?id=2306404 • CWE-130: Improper Handling of Length Parameter Inconsistency •

CVSS: -EPSS: 0%CPEs: 3EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: platform/surface: aggregator: Add missing call to ssam_request_sync_free() Although rare, ssam_request_sync_init() can fail. In that case, the request should be freed via ssam_request_sync_free(). Currently it is leaked instead. Fix this. • https://git.kernel.org/stable/c/c167b9c7e3d6131b4a4865c112a3dbc86d2e997d https://git.kernel.org/stable/c/d2dc110deabe7142b60ebeed689e67f92795ee24 https://git.kernel.org/stable/c/50b3cdf8239b11545f311c4f7b89e0092e4feedb https://git.kernel.org/stable/c/c965daac370f08a9b71d573a71d13cda76f2a884 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: efi: fix NULL-deref in init error path In cases where runtime services are not supported or have been disabled, the runtime services workqueue will never have been allocated. Do not try to destroy the workqueue unconditionally in the unlikely event that EFI initialisation fails to avoid dereferencing a NULL pointer. • https://git.kernel.org/stable/c/2ff3c97b47521d6700cc6485c7935908dcd2c27c https://git.kernel.org/stable/c/5167f194da6947e19a3e970485ee3ccb44f7958d https://git.kernel.org/stable/c/98086df8b70c06234a8f4290c46064e44dafa0ed https://git.kernel.org/stable/c/f591a42b8f9a9d20e01d0462f4f55d2176ac52ec https://git.kernel.org/stable/c/e6584124b9823151ef586d10dedf565ade50cea6 https://git.kernel.org/stable/c/585a0b2b3ae7903c6abee3087d09c69e955a7794 https://git.kernel.org/stable/c/5fcf75a8a4c3e7ee9122d143684083c9faf20452 https://git.kernel.org/stable/c/4ca71bc0e1995d15486cd7b60845602a2 •