CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-46695 – selinux,smack: don't bypass permissions check in inode_setsecctx hook
https://notcve.org/view.php?id=CVE-2024-46695
In the Linux kernel, the following vulnerability has been resolved: selinux,smack: don't bypass permissions check in inode_setsecctx hook Marek Gresko reports that the root user on an NFS client is able to change the security labels on files on an NFS filesystem that is exported with root squashing enabled. The end of the kerneldoc comment for __vfs_setxattr_noperm() states: * This function requires the caller to lock the inode's i_mutex before it * is executed. It also assumes that the caller will make the appropriate * permission checks. nfsd_setattr() does do permissions checking via fh_verify() and nfsd_permission(), but those don't do all the same permissions checks that are done by security_inode_setxattr() and its related LSM hooks do. Since nfsd_setattr() is the only consumer of security_inode_setsecctx(), simplest solution appears to be to replace the call to __vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). This fixes the above issue and has the added benefit of causing nfsd to recall conflicting delegations on a file when a client tries to change its security label. • https://git.kernel.org/stable/c/2dbc4b7bac60b02cc6e70d05bf6a7dfd551f9dda https://git.kernel.org/stable/c/fe0cd53791119f6287b6532af8ce41576d664930 https://git.kernel.org/stable/c/eebec98791d0137e455cc006411bb92a54250924 https://git.kernel.org/stable/c/459584258d47ec3cc6245a82e8a49c9d08eb8b57 https://git.kernel.org/stable/c/f71ec019257ba4f7ab198bd948c5902a207bad96 https://git.kernel.org/stable/c/76a0e79bc84f466999fa501fce5bf7a07641b8a7 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-46689 – soc: qcom: cmd-db: Map shared memory as WC, not WB
https://notcve.org/view.php?id=CVE-2024-46689
In the Linux kernel, the following vulnerability has been resolved: soc: qcom: cmd-db: Map shared memory as WC, not WB Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone. The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings. Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC. I tested this on SA8155P with Xen. • https://git.kernel.org/stable/c/312416d9171a1460b7ed8d182b5b540c910ce80d https://git.kernel.org/stable/c/0ee9594c974368a17e85a431e9fe1c14fb65c278 https://git.kernel.org/stable/c/f5a5a5a0e95f36e2792d48e6e4b64e665eb01374 https://git.kernel.org/stable/c/eaff392c1e34fb77cc61505a31b0191e5e46e271 https://git.kernel.org/stable/c/d9d48d70e922b272875cda60d2ada89291c840cf https://git.kernel.org/stable/c/ef80520be0ff78ae5ed44cb6eee1525e65bebe70 https://git.kernel.org/stable/c/62c2d63605ca25b5db78a347ed303c0a0a77d5b4 https://git.kernel.org/stable/c/f9bb896eab221618927ae6a2f1d566567 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-46685 – pinctrl: single: fix potential NULL dereference in pcs_get_function()
https://notcve.org/view.php?id=CVE-2024-46685
In the Linux kernel, the following vulnerability has been resolved: pinctrl: single: fix potential NULL dereference in pcs_get_function() pinmux_generic_get_function() can return NULL and the pointer 'function' was dereferenced without checking against NULL. Add checking of pointer 'function' in pcs_get_function(). Found by code review. • https://git.kernel.org/stable/c/571aec4df5b72a80f80d1e524da8fbd7ff525c98 https://git.kernel.org/stable/c/0a2bab5ed161318f57134716accba0a30f3af191 https://git.kernel.org/stable/c/2cea369a5c2e85ab14ae716da1d1cc6d25c85e11 https://git.kernel.org/stable/c/4e9436375fcc9bd2a60ee96aba6ed53f7a377d10 https://git.kernel.org/stable/c/6341c2856785dca7006820b127278058a180c075 https://git.kernel.org/stable/c/8f0bd526921b6867c2f10a83cd4fd14139adcd92 https://git.kernel.org/stable/c/4ed45fe99ec9e3c9478bd634624cd05a57d002f7 https://git.kernel.org/stable/c/292151af6add3e5ab11b2e9916cffa5f5 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-46681 – pktgen: use cpus_read_lock() in pg_net_init()
https://notcve.org/view.php?id=CVE-2024-46681
In the Linux kernel, the following vulnerability has been resolved: pktgen: use cpus_read_lock() in pg_net_init() I have seen the WARN_ON(smp_processor_id() != cpu) firing in pktgen_thread_worker() during tests. We must use cpus_read_lock()/cpus_read_unlock() around the for_each_online_cpu(cpu) loop. While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/5f5f7366dda8ae870e8305d6e7b3c0c2686cd2cf https://git.kernel.org/stable/c/979b581e4c69257acab1af415ddad6b2d78a2fa5 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-46679 – ethtool: check device is present when getting link settings
https://notcve.org/view.php?id=CVE-2024-46679
In the Linux kernel, the following vulnerability has been resolved: ethtool: check device is present when getting link settings A sysfs reader can race with a device reset or removal, attempting to read device state when the device is not actually present. eg: [exception RIP: qed_get_current_link+17] #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede] #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb crash> struct net_device.state ffff9a9d21336000 state = 5, state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100). The device is not present, note lack of __LINK_STATE_PRESENT (0b10). This is the same sort of panic as observed in commit 4224cfd7fb65 ("net-sysfs: add check for netdevice being present to speed_show"). There are many other callers of __ethtool_get_link_ksettings() which don't have a device presence check. Move this check into ethtool to protect all callers. • https://git.kernel.org/stable/c/d519e17e2d01a0ee9abe083019532061b4438065 https://git.kernel.org/stable/c/ec7b4f7f644018ac293cb1b02528a40a32917e62 https://git.kernel.org/stable/c/842a40c7273ba1c1cb30dda50405b328de1d860e https://git.kernel.org/stable/c/7a8d98b6d6484d3ad358510366022da080c37cbc https://git.kernel.org/stable/c/9bba5955eed160102114d4cc00c3d399be9bdae4 https://git.kernel.org/stable/c/94ab317024ba373d37340893d1c0358638935fbb https://git.kernel.org/stable/c/1d6d9b5b1b95bfeccb84386a51b7e6c510ec13b2 https://git.kernel.org/stable/c/a699781c79ecf6cfe67fb00a0331b4088 •