Page 157 of 2922 results (0.007 seconds)

CVSS: 3.3EPSS: 0%CPEs: 9EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: net: fix information leakage in /proc/net/ptype In one net namespace, after creating a packet socket without binding it to a device, users in other net namespaces can observe the new `packet_type` added by this packet socket by reading `/proc/net/ptype` file. This is minor information leakage as packet socket is namespace aware. Add a net pointer in `packet_type` to keep the net namespace of of corresponding packet socket. In `ptype_seq_show`, this net pointer must be checked when it is not NULL. • https://git.kernel.org/stable/c/2feb27dbe00cbb4f7d31f90acf6bd0d751dd0a50 https://git.kernel.org/stable/c/8f88c78d24f6f346919007cd459fd7e51a8c7779 https://git.kernel.org/stable/c/be1ca30331c7923c6f376610c1bd6059be9b1908 https://git.kernel.org/stable/c/c38023032a598ec6263e008d62c7f02def72d5c7 https://git.kernel.org/stable/c/b67ad6170c0ea87391bb253f35d1f78857736e54 https://git.kernel.org/stable/c/e372ecd455b6ebc7720f52bf4b5f5d44d02f2092 https://git.kernel.org/stable/c/db044d97460ea792110eb8b971e82569ded536c6 https://git.kernel.org/stable/c/e43669c77cb3a742b7d84ecdc7c68c416 • CWE-276: Incorrect Default Permissions •

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

In the Linux kernel, the following vulnerability has been resolved: drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable The function performs a check on the "phy" input parameter, however, it is used before the check. Initialize the "dev" variable after the sanity check to avoid a possible NULL pointer dereference. Addresses-Coverity-ID: 1493860 ("Null pointer dereference") • https://git.kernel.org/stable/c/5c8290284402bf7d2c12269402b3177b899c78b7 https://git.kernel.org/stable/c/6d9f8ba28f3747ca0f910a363e46f1114856dbbe https://git.kernel.org/stable/c/ca63eeb70fcb53c42e1fe54e1735a54d8e7759fd https://git.kernel.org/stable/c/581317b1f001b7509041544d7019b75571daa100 https://git.kernel.org/stable/c/79c0b5287ded74f4eacde4dfd8aa0a76cbd853b5 https://git.kernel.org/stable/c/56480fb10b976581a363fd168dc2e4fbee87a1a7 https://git.kernel.org/stable/c/2b7e7df1eacd280e561ede3e977853606871c951 https://git.kernel.org/stable/c/5e761a2287234bc402ba7ef07129f5103 •

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

In the Linux kernel, the following vulnerability has been resolved: powerpc64/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06 Johan reported the below crash with test_bpf on ppc64 e5500: test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited:1 Oops: Exception in kernel mode, sig: 4 [#1] BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500 Modules linked in: test_bpf(+) CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1 NIP: 8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18 REGS: c0000000032d3420 TRAP: 0700 Not tainted (5.14.0-03771-g98c2059e008a-dirty) MSR: 0000000080089000 <EE,ME> CR: 88002822 XER: 20000000 IRQMASK: 0 <...> NIP [8000000000061c3c] 0x8000000000061c3c LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf] Call Trace: .__run_one+0x60/0x17c [test_bpf] (unreliable) .test_bpf_init+0x6a8/0xdc8 [test_bpf] .do_one_initcall+0x6c/0x28c .do_init_module+0x68/0x28c .load_module+0x2460/0x2abc .__do_sys_init_module+0x120/0x18c .system_call_exception+0x110/0x1b8 system_call_common+0xf0/0x210 --- interrupt: c00 at 0x101d0acc <... • https://git.kernel.org/stable/c/156d0e290e969caba25f1851c52417c14d141b24 https://git.kernel.org/stable/c/129c71829d7f46423d95c19e8d87ce956d4c6e1c https://git.kernel.org/stable/c/3bfbc00587dc883eaed383558ae512a351c2cd09 https://git.kernel.org/stable/c/aaccfeeee1630b155e8ff0d6c449d3de1ef86e73 https://git.kernel.org/stable/c/3f5f766d5f7f95a69a630da3544a1a0cee1cdddf •

CVSS: 7.5EPSS: 0%CPEs: 5EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: block: Fix wrong offset in bio_truncate() bio_truncate() clears the buffer outside of last block of bdev, however current bio_truncate() is using the wrong offset of page. So it can return the uninitialized data. This happened when both of truncated/corrupted FS and userspace (via bdev) are trying to read the last of bdev. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bloque: corrige el desplazamiento incorrecto en bio_truncate() bio_truncate() borra el búfer fuera del último bloque de bdev, sin embargo, el bio_truncate() actual está usando el desplazamiento de página incorrecto. Entonces puede devolver los datos no inicializados. Esto sucedió cuando tanto el FS truncado/corrupto como el espacio de usuario (a través de bdev) intentaban leer lo último de bdev. • https://git.kernel.org/stable/c/6cbf4c731d7812518cd857c2cfc3da9fd120f6ae https://git.kernel.org/stable/c/b63e120189fd92aff00096d11e2fc5253f60248b https://git.kernel.org/stable/c/4633a79ff8bc82770486a063a08b55e5162521d8 https://git.kernel.org/stable/c/941d5180c430ce5b0f7a3622ef9b76077bfa3d82 https://git.kernel.org/stable/c/3ee859e384d453d6ac68bfd5971f630d9fa46ad3 https://access.redhat.com/security/cve/CVE-2022-48747 https://bugzilla.redhat.com/show_bug.cgi?id=2293312 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') CWE-908: Use of Uninitialized Resource •

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

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Avoid field-overflowing memcpy() In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Use flexible arrays instead of zero-element arrays (which look like they are always overflowing) and split the cross-field memcpy() into two halves that can be appropriately bounds-checked by the compiler. We were doing: #define ETH_HLEN 14 #define VLAN_HLEN 4 ... #define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN) ... struct mlx5e_tx_wqe *wqe = mlx5_wq_cyc_get_wqe(wq, pi); ... struct mlx5_wqe_eth_seg *eseg = &wqe->eth; struct mlx5_wqe_data_seg *dseg = wqe->data; ... memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE); target is wqe->eth.inline_hdr.start (which the compiler sees as being 2 bytes in size), but copying 18, intending to write across start (really vlan_tci, 2 bytes). The remaining 16 bytes get written into wqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr (8 bytes). struct mlx5e_tx_wqe { struct mlx5_wqe_ctrl_seg ctrl; /* 0 16 */ struct mlx5_wqe_eth_seg eth; /* 16 16 */ struct mlx5_wqe_data_seg data[]; /* 32 0 */ /* size: 32, cachelines: 1, members: 3 */ /* last cacheline: 32 bytes */ }; struct mlx5_wqe_eth_seg { u8 swp_outer_l4_offset; /* 0 1 */ u8 swp_outer_l3_offset; /* 1 1 */ u8 swp_inner_l4_offset; /* 2 1 */ u8 swp_inner_l3_offset; /* 3 1 */ u8 cs_flags; /* 4 1 */ u8 swp_flags; /* 5 1 */ __be16 mss; /* 6 2 */ __be32 flow_table_metadata; /* 8 4 */ union { struct { __be16 sz; /* 12 2 */ u8 start[2]; /* 14 2 */ } inline_hdr; /* 12 4 */ struct { __be16 type; /* 12 2 */ __be16 vlan_tci; /* 14 2 */ } insert; /* 12 4 */ __be32 trailer; /* 12 4 */ }; /* 12 4 */ /* size: 16, cachelines: 1, members: 9 */ /* last cacheline: 16 bytes */ }; struct mlx5_wqe_data_seg { __be32 byte_count; /* 0 4 */ __be32 lkey; /* 4 4 */ __be64 addr; /* 8 8 */ /* size: 16, cachelines: 1, members: 3 */ /* last cacheline: 16 bytes */ }; So, split the memcpy() so the compiler can reason about the buffer sizes. "pahole" shows no size nor member offset changes to struct mlx5e_tx_wqe nor struct mlx5e_umr_wqe. "objdump -d" shows no meaningful object code changes (i.e. only source line number induced differences and optimizations). • https://git.kernel.org/stable/c/b5503b994ed5ed8dbfe821317e7b5b38acb065c5 https://git.kernel.org/stable/c/8fbdf8c8b8ab82beab882175157650452c46493e https://git.kernel.org/stable/c/ad5185735f7dab342fdd0dd41044da4c9ccfef67 •