The function hso_get_config_data in drivers/net/usb/hso.c in the Linux kernel through 4.19.8 reads if_num from the USB device (as a u8) and uses it to index a small array, resulting in an object out-of-bounds (OOB) read that potentially allows arbitrary read in the kernel address space.

A flaw that boot CPU could be vulnerable for the speculative execution behavior kind of attacks in the Linux kernel X86 CPU Power management options functionality was found in the way user resuming CPU from suspend-to-RAM. A local user could use this flaw to potentially get unauthorized access to some memory of the CPU similar to the speculative execution behavior kind of attacks.

In the Linux kernel, the following vulnerability has been resolved: ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find() Syzbot reports a warning as follows: ============================================ WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290 Modules linked in: CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419 Call Trace: <TASK> ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375 generic_shutdown_super+0x136/0x2d0 fs/super.c:641 kill_block_super+0x44/0x90 fs/super.c:1675 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327 [...] ============================================ This is because when finding an entry in ext4_xattr_block_cache_find(), if ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown in the __entry_find(), won't be put away, and eventually trigger the above issue in mb_cache_destroy() due to reference count leakage. So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.

IBM GSKit (IBM DB2 for Linux, UNIX and Windows 9.7, 10.1, 10.5, and 11.1) uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. IBM X-Force ID: 139073.

In the Linux kernel, the following vulnerability has been resolved: swiotlb: fix info leak with DMA_FROM_DEVICE The problem I'm addressing was discovered by the LTP test covering cve-2018-1000204. A short description of what happens follows: 1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV and a corresponding dxferp. The peculiar thing about this is that TUR is not reading from the device. 2) In sg_start_req() the invocation of blk_rq_map_user() effectively bounces the user-space buffer. As if the device was to transfer into it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") we make sure this first bounce buffer is allocated with GFP_ZERO. 3) For the rest of the story we keep ignoring that we have a TUR, so the device won't touch the buffer we prepare as if the we had a DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device and the buffer allocated by SG is mapped by the function virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here scatter-gather and not scsi generics). This mapping involves bouncing via the swiotlb (we need swiotlb to do virtio in protected guest like s390 Secure Execution, or AMD SEV). 4) When the SCSI TUR is done, we first copy back the content of the second (that is swiotlb) bounce buffer (which most likely contains some previous IO data), to the first bounce buffer, which contains all zeros. Then we copy back the content of the first bounce buffer to the user-space buffer. 5) The test case detects that the buffer, which it zero-initialized, ain't all zeros and fails. One can argue that this is an swiotlb problem, because without swiotlb we leak all zeros, and the swiotlb should be transparent in a sense that it does not affect the outcome (if all other participants are well behaved). Copying the content of the original buffer into the swiotlb buffer is the only way I can think of to make swiotlb transparent in such scenarios. So let's do just that if in doubt, but allow the driver to tell us that the whole mapped buffer is going to be overwritten, in which case we can preserve the old behavior and avoid the performance impact of the extra bounce.

A missing address check in the callers of the show_opcodes() in the Linux kernel allows an attacker to dump the kernel memory at an arbitrary kernel address into the dmesg log.

IBM Security Guardium 11.2 stores user credentials in plain clear text which can be read by a local user. IBM X-Force ID: 195770.

IBM Security Verify Information Queue 1.0.6 and 1.0.7 could disclose highly sensitive information to a local user due to inproper storage of a plaintext cryptographic key. IBM X-Force ID: 198187.

The copy_from_user function in the uaccess code in Linux kernel 2.6 before 2.6.19-rc1, when running on s390, does not properly clear a kernel buffer, which allows local user space programs to read portions of kernel memory by "appending to a file from a bad address," which triggers a fault that prevents the unused memory from being cleared in the kernel buffer.

NVIDIA GPU and Tegra hardware contain a vulnerability in the internal microcontroller which may allow a user with elevated privileges to utilize debug mechanisms with insufficient access control, which may lead to information disclosure.

NVIDIA GPU and Tegra hardware contain a vulnerability in the internal microcontroller which may allow a user with elevated privileges to access debug registers during runtime, which may lead to information disclosure.

The report API in the crypto user configuration API in the Linux kernel through 3.8.2 uses an incorrect C library function for copying strings, which allows local users to obtain sensitive information from kernel stack memory by leveraging the CAP_NET_ADMIN capability.

The crypto_report_one function in crypto/crypto_user.c in the report API in the crypto user configuration API in the Linux kernel through 3.8.2 uses an incorrect length value during a copy operation, which allows local users to obtain sensitive information from kernel memory by leveraging the CAP_NET_ADMIN capability.

The crypto_report_one function in crypto/crypto_user.c in the report API in the crypto user configuration API in the Linux kernel through 3.8.2 does not initialize certain structure members, which allows local users to obtain sensitive information from kernel heap memory by leveraging the CAP_NET_ADMIN capability.

The __block_prepare_write function in fs/buffer.c for Linux kernel 2.6.x before 2.6.13 does not properly clear buffers during certain error conditions, which allows local users to read portions of files that have been unlinked.

The fill_event_metadata function in fs/notify/fanotify/fanotify_user.c in the Linux kernel through 3.9.4 does not initialize a certain structure member, which allows local users to obtain sensitive information from kernel memory via a read operation on the fanotify descriptor.

The HP Smart Array controller disk-array driver and Compaq SMART2 controller disk-array driver in the Linux kernel through 3.9.4 do not initialize certain data structures, which allows local users to obtain sensitive information from kernel memory via (1) a crafted IDAGETPCIINFO command for a /dev/ida device, related to the ida_locked_ioctl function in drivers/block/cpqarray.c or (2) a crafted CCISS_PASSTHRU32 command for a /dev/cciss device, related to the cciss_ioctl32_passthru function in drivers/block/cciss.c.

Directory traversal vulnerability in CIFS in Linux 2.6.16 and earlier allows local users to escape chroot restrictions for an SMB-mounted filesystem via "..\\" sequences, a similar vulnerability to CVE-2006-1864.

net/ipv4/af_inet.c in Linux kernel 2.4 does not clear sockaddr_in.sin_zero before returning IPv4 socket names from the (1) getsockname, (2) getpeername, and (3) accept functions, which allows local users to obtain portions of potentially sensitive memory.

The Linux kernel before 2.6.16.9 and the FreeBSD kernel, when running on AMD64 and other 7th and 8th generation AuthenticAMD processors, only save/restore the FOP, FIP, and FDP x87 registers in FXSAVE/FXRSTOR when an exception is pending, which allows one process to determine portions of the state of floating point instructions of other processes, which can be leveraged to obtain sensitive information such as cryptographic keys. NOTE: this is the documented behavior of AMD64 processors, but it is inconsistent with Intel processors in a security-relevant fashion that was not addressed by the kernels.

net/ipv4/netfilter/ip_conntrack_core.c in Linux kernel 2.4 and 2.6, and possibly net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c in 2.6, does not clear sockaddr_in.sin_zero before returning IPv4 socket names from the getsockopt function with SO_ORIGINAL_DST, which allows local users to obtain portions of potentially sensitive memory.

dm-crypt in Linux kernel 2.6.15 and earlier does not clear a structure before it is freed, which leads to a memory disclosure that could allow local users to obtain sensitive information about a cryptographic key.

drm.c in Linux kernel 2.6.10 to 2.6.13 creates a debug file in sysfs with world-readable and world-writable permissions, which allows local users to enable DRM debugging and obtain sensitive information.

In the Linux kernel, the following vulnerability has been resolved: iavf: Fix error handling in iavf_init_module() The iavf_init_module() won't destroy workqueue when pci_register_driver() failed. Call destroy_workqueue() when pci_register_driver() failed to prevent the resource leak. Similar to the handling of u132_hcd_init in commit f276e002793c ("usb: u132-hcd: fix resource leak")

cryptoloop on Linux kernel 2.6.x, when used on certain file systems with a block size 1024 or greater, has certain "IV computation" weaknesses that allow watermarked files to be detected without decryption.

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 update 32 and earlier, 5 update 35 and earlier, and 1.4.2_37 and earlier allows local users to affect confidentiality via unknown vectors related to printing on Solaris or Linux.

Signedness error in the copy_from_read_buf function in n_tty.c for Linux kernel 2.6.10 and 2.6.11rc1 allows local users to read kernel memory via a negative argument.

A "potential" buffer overflow exists in the panic() function in Linux 2.4.x, although it may not be exploitable due to the functionality of panic.

In the Linux kernel, the following vulnerability has been resolved: dma-buf: heaps: Fix potential spectre v1 gadget It appears like nr could be a Spectre v1 gadget as it's supplied by a user and used as an array index. Prevent the contents of kernel memory from being leaked to userspace via speculative execution by using array_index_nospec. [sumits: added fixes and cc: stable tags]

Linux kernel 2.6.10 and 2.6.11rc1-bk6 uses different size types for offset arguments to the proc_file_read and locks_read_proc functions, which leads to a heap-based buffer overflow when a signed comparison causes negative integers to be used in a positive context.

The JFS file system code in Linux 2.4.x has an information leak in which in-memory data is written to the device for the JFS file system, which allows local users to obtain sensitive information by reading the raw device.

Mozilla Firefox 4.x through 9.0 and SeaMonkey before 2.7 on Linux and Mac OS X set weak permissions for Firefox Recovery Key.html, which might allow local users to read a Firefox Sync key via standard filesystem operations.

In the Linux kernel, the following vulnerability has been resolved: igb: Initialize mailbox message for VF reset When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case.

A numeric casting discrepancy in sdla_xfer in Linux kernel 2.6.x up to 2.6.5 and 2.4 up to 2.4.29-rc1 allows local users to read portions of kernel memory via a large len argument, which is received as an int but cast to a short, which prevents a read loop from filling a buffer.

In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix out-of-bounds read when setting HMAC data. The SRv6 layer allows defining HMAC data that can later be used to sign IPv6 Segment Routing Headers. This configuration is realised via netlink through four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and SEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actual length of the SECRET attribute, it is possible to provide invalid combinations (e.g., secret = "", secretlen = 64). This case is not checked in the code and with an appropriately crafted netlink message, an out-of-bounds read of up to 64 bytes (max secret length) can occur past the skb end pointer and into skb_shared_info: Breakpoint 1, seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 208 memcpy(hinfo->secret, secret, slen); (gdb) bt #0 seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 #1 0xffffffff81e012e9 in genl_family_rcv_msg_doit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600, extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 <init_net>, family=<optimized out>, family=<optimized out>) at net/netlink/genetlink.c:731 #2 0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00, family=0xffffffff82fef6c0 <seg6_genl_family>) at net/netlink/genetlink.c:775 #3 genl_rcv_msg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792 #4 0xffffffff81dfffc3 in netlink_rcv_skb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 <genl_rcv_msg>) at net/netlink/af_netlink.c:2501 #5 0xffffffff81e00919 in genl_rcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803 #6 0xffffffff81dff6ae in netlink_unicast_kernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000) at net/netlink/af_netlink.c:1319 #7 netlink_unicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=<optimized out>) at net/netlink/af_netlink.c:1345 #8 0xffffffff81dff9a4 in netlink_sendmsg (sock=<optimized out>, msg=0xffffc90000ba7e48, len=<optimized out>) at net/netlink/af_netlink.c:1921 ... (gdb) p/x ((struct sk_buff *)0xffff88800b1f9f00)->head + ((struct sk_buff *)0xffff88800b1f9f00)->end $1 = 0xffff88800b1b76c0 (gdb) p/x secret $2 = 0xffff88800b1b76c0 (gdb) p slen $3 = 64 '@' The OOB data can then be read back from userspace by dumping HMAC state. This commit fixes this by ensuring SECRETLEN cannot exceed the actual length of SECRET.

The osf_getsysinfo function in arch/alpha/kernel/osf_sys.c in the Linux kernel before 2.6.39.4 on the Alpha platform does not properly restrict the data size for GSI_GET_HWRPB operations, which allows local users to obtain sensitive information from kernel memory via a crafted call.

Integer signedness error in the osf_getdomainname function in arch/alpha/kernel/osf_sys.c in the Linux kernel before 2.6.39.4 on the Alpha platform allows local users to obtain sensitive information from kernel memory via a crafted call.

fs/proc/base.c in the Linux kernel before 2.6.39.4 does not properly restrict access to /proc/#####/io files, which allows local users to obtain sensitive I/O statistics by polling a file, as demonstrated by discovering the length of another user's password.

The open_exec function in the execve functionality (exec.c) in Linux kernel 2.4.x up to 2.4.27, and 2.6.x up to 2.6.8, allows local users to read non-readable ELF binaries by using the interpreter (PT_INTERP) functionality.

The osf_partition function in fs/partitions/osf.c in the Linux kernel before 2.6.38 does not properly handle an invalid number of partitions, which might allow local users to obtain potentially sensitive information from kernel heap memory via vectors related to partition-table parsing.

Linux kernel does not properly convert 64-bit file offset pointers to 32 bits, which allows local users to access portions of kernel memory.

The e1000 driver for Linux kernel 2.4.26 and earlier does not properly initialize memory before using it, which allows local users to read portions of kernel memory. NOTE: this issue was originally incorrectly reported as a "buffer overflow" by some sources.

The do_task_stat function in fs/proc/array.c in the Linux kernel before 2.6.39-rc1 does not perform an expected uid check, which makes it easier for local users to defeat the ASLR protection mechanism by reading the start_code and end_code fields in the /proc/#####/stat file for a process executing a PIE binary.

The do_replace function in net/bridge/netfilter/ebtables.c in the Linux kernel before 2.6.39 does not ensure that a certain name field ends with a '\0' character, which allows local users to obtain potentially sensitive information from kernel stack memory by leveraging the CAP_NET_ADMIN capability to replace a table, and then reading a modprobe command line.

The XFS file system code in Linux 2.4.x has an information leak in which in-memory data is written to the device for the XFS file system, which allows local users to obtain sensitive information by reading the raw device.

The ib_uverbs_poll_cq function in drivers/infiniband/core/uverbs_cmd.c in the Linux kernel before 2.6.37 does not initialize a certain response buffer, which allows local users to obtain potentially sensitive information from kernel memory via vectors that cause this buffer to be only partially filled, a different vulnerability than CVE-2010-4649.

The ocfs2_prepare_page_for_write function in fs/ocfs2/aops.c in the Oracle Cluster File System 2 (OCFS2) subsystem in the Linux kernel before 2.6.39-rc1 does not properly handle holes that cross page boundaries, which allows local users to obtain potentially sensitive information from uninitialized disk locations by reading a file.

The /proc filesystem in Linux allows local users to obtain sensitive information by opening various entries in /proc/self before executing a setuid program, which causes the program to fail to change the ownership and permissions of those entries.

net/core/ethtool.c in the Linux kernel before 2.6.36 does not initialize certain data structures, which allows local users to obtain potentially sensitive information from kernel heap memory by leveraging the CAP_NET_ADMIN capability for an ethtool ioctl call.

ifconfig, when used on the Linux kernel 2.2 and later, does not report when the network interface is in promiscuous mode if it was put in promiscuous mode using PACKET_MR_PROMISC, which could allow attackers to sniff the network without detection, as demonstrated using libpcap.