p PatchFirst

PatchFirst · Latest vulnerabilities

linux-oracle-5.15 vulnerabilities · Page 62

Vulnerabilities published for linux-oracle-5.15 in the last 30 days: 0. Listed in the KEV catalogue: 0.

Filter vulnerabilities
Clear filters

Vulnerabilities: 4250

  1. CVE-2022-50020

    Medium · CVSS 6.7EPSS 0.21%Fix available

    ext4: avoid resizing to a partial cluster size

    In the Linux kernel, the following vulnerability has been resolved: ext4: avoid resizing to a partial cluster size This patch avoids an attempt to resize the filesystem to an unaligned cluster boundary. An online resize to a size that is not integral to cluster size results in the last iteration attempting to grow the fs by a negative amount, which trips a BUG_ON and leaves the fs with a corrupted in-memory superblock.

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated
  2. CVE-2022-50019

    Medium · CVSS 5.5EPSS 0.19%Fix available

    tty: serial: Fix refcount leak bug in ucc_uart.c

    In the Linux kernel, the following vulnerability has been resolved: tty: serial: Fix refcount leak bug in ucc_uart.c In soc_info(), of_find_node_by_type() will return a node pointer with refcount incremented. We should use of_node_put() when it is not used anymore.

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated
  3. CVE-2022-50017

    Medium · CVSS 5.5EPSS 0.19%Fix available

    mips: cavium-octeon: Fix missing of_node_put() in octeon2_usb_clocks_start

    In the Linux kernel, the following vulnerability has been resolved: mips: cavium-octeon: Fix missing of_node_put() in octeon2_usb_clocks_start We should call of_node_put() for the reference 'uctl_node' returned by of_get_parent() which will increase the refcount. Otherwise, there will be a refcount leak bug.

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated
  4. CVE-2022-50013

    Medium · CVSS 6EPSS 0.25%Fix available

    f2fs: fix to avoid use f2fs_bug_on() in f2fs_new_node_page()

    In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use f2fs_bug_on() in f2fs_new_node_page() As Dipanjan Das <[email protected]> reported, syzkaller found a f2fs bug as below: RIP: 0010:f2fs_new_node_page+0x19ac/0x1fc0 fs/f2fs/node.c:1295 Call Trace: write_all_xattrs fs/f2fs/xattr.c:487 [inline] __f2fs_setxattr+0xe76/0x2e10 fs/f2fs/xattr.c:743 f2fs_setxattr+0x233/0xab0 fs/f2fs/xattr.c:790 f2fs_xattr_generic_set+0x133/0x170 fs/f2fs/xattr.c:86 __vfs_setxattr+0x115/0x180 fs/xattr.c:182 __vfs_setxattr_noperm+0x125/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1cf/0x260 fs/xattr.c:277 vfs_set

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated
  5. CVE-2022-50012

    Medium · CVSS 5.5EPSS 0.25%Fix available

    powerpc/64: Init jump labels before parse_early_param()

    In the Linux kernel, the following vulnerability has been resolved: powerpc/64: Init jump labels before parse_early_param() On 64-bit, calling jump_label_init() in setup_feature_keys() is too late because static keys may be used in subroutines of parse_early_param() which is again subroutine of early_init_devtree(). For example booting with "threadirqs": static_key_enable_cpuslocked(): static key '0xc000000002953260' used before call to jump_label_init() WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120 ... NIP static_key_enable_cpuslocked+0xfc/0x120 LR static_key_enable_cpuslocked+0xf8/0

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated
  6. CVE-2022-50011

    Medium · CVSS 5.5EPSS 0.24%Fix available

    venus: pm_helpers: Fix warning in OPP during probe

    In the Linux kernel, the following vulnerability has been resolved: venus: pm_helpers: Fix warning in OPP during probe Fix the following WARN triggered during Venus driver probe on 5.19.0-rc8-next-20220728: WARNING: CPU: 7 PID: 339 at drivers/opp/core.c:2471 dev_pm_opp_set_config+0x49c/0x610 Modules linked in: qcom_spmi_adc5 rtc_pm8xxx qcom_spmi_adc_tm5 leds_qcom_lpg led_class_multicolor qcom_pon qcom_vadc_common venus_core(+) qcom_spmi_temp_alarm v4l2_mem2mem videobuf2_v4l2 msm(+) videobuf2_common crct10dif_ce spi_geni_qcom snd_soc_sm8250 i2c_qcom_geni gpu_sched snd_soc_qcom_common videodev qcom_q6v5_pas soundwire_qcom drm_dp_aux_

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated
  7. CVE-2022-50010

    Medium · CVSS 6.7EPSS 0.25%Fix available

    video: fbdev: i740fb: Check the argument of i740_calc_vclk()

    In the Linux kernel, the following vulnerability has been resolved: video: fbdev: i740fb: Check the argument of i740_calc_vclk() Since the user can control the arguments of the ioctl() from the user space, under special arguments that may result in a divide-by-zero bug. If the user provides an improper 'pixclock' value that makes the argumet of i740_calc_vclk() less than 'I740_RFREQ_FIX', it will cause a divide-by-zero bug in: drivers/video/fbdev/i740fb.c:353 p_best = min(15, ilog2(I740_MAX_VCO_FREQ / (freq / I740_RFREQ_FIX))); The following log can reveal it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:i740_calc_vclk dri

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated
  8. CVE-2022-50008

    Medium · CVSS 5.5EPSS 0.25%Fix available

    kprobes: don't call disarm_kprobe() for disabled kprobes

    In the Linux kernel, the following vulnerability has been resolved: kprobes: don't call disarm_kprobe() for disabled kprobes The assumption in __disable_kprobe() is wrong, and it could try to disarm an already disarmed kprobe and fire the WARN_ONCE() below. [0] We can easily reproduce this issue. 1. Write 0 to /sys/kernel/debug/kprobes/enabled. # echo 0 > /sys/kernel/debug/kprobes/enabled 2. Run execsnoop. At this time, one kprobe is disabled. # /usr/share/bcc/tools/execsnoop & [1] 2460 PCOMM PID PPID RET ARGS # cat /sys/kernel/debug/kprobes/list ffffffff91345650 r __x64_sys_execve+0x0 [FTRACE] ffff

    • Update to 5.15.0-1027.33~20.04.1
    Published Updated
  9. CVE-2022-50007

    Medium · CVSS 5.5EPSS 0.25%Fix available

    xfrm: fix refcount leak in __xfrm_policy_check()

    In the Linux kernel, the following vulnerability has been resolved: xfrm: fix refcount leak in __xfrm_policy_check() The issue happens on an error path in __xfrm_policy_check(). When the fetching process of the object `pols[1]` fails, the function simply returns 0, forgetting to decrement the reference count of `pols[0]`, which is incremented earlier by either xfrm_sk_policy_lookup() or xfrm_policy_lookup(). This may result in memory leaks. Fix it by decreasing the reference count of `pols[0]` in that path.

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated
  10. CVE-2022-50006

    Medium · CVSS 5.5EPSS 0.24%Fix available

    NFSv4.2 fix problems with __nfs42_ssc_open

    In the Linux kernel, the following vulnerability has been resolved: NFSv4.2 fix problems with __nfs42_ssc_open A destination server while doing a COPY shouldn't accept using the passed in filehandle if its not a regular filehandle. If alloc_file_pseudo() has failed, we need to decrement a reference on the newly created inode, otherwise it leaks.

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated
  11. CVE-2022-50005

    High · CVSS 7.8EPSS 0.25%Fix available

    nfc: pn533: Fix use-after-free bugs caused by pn532_cmd_timeout

    In the Linux kernel, the following vulnerability has been resolved: nfc: pn533: Fix use-after-free bugs caused by pn532_cmd_timeout When the pn532 uart device is detaching, the pn532_uart_remove() is called. But there are no functions in pn532_uart_remove() that could delete the cmd_timeout timer, which will cause use-after-free bugs. The process is shown below: (thread 1) | (thread 2) | pn532_uart_send_frame pn532_uart_remove | mod_timer(&pn532->cmd_timeout,...) ... | (wait a time) kfree(pn532) //FREE | pn532_cmd_tim

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated
  12. CVE-2022-50004

    Medium · CVSS 6.8EPSS 0.25%Fix available

    xfrm: policy: fix metadata dst->dev xmit null pointer dereference

    In the Linux kernel, the following vulnerability has been resolved: xfrm: policy: fix metadata dst->dev xmit null pointer dereference When we try to transmit an skb with metadata_dst attached (i.e. dst->dev == NULL) through xfrm interface we can hit a null pointer dereference[1] in xfrmi_xmit2() -> xfrm_lookup_with_ifid() due to the check for a loopback skb device when there's no policy which dereferences dst->dev unconditionally. Not having dst->dev can be interepreted as it not being a loopback device, so just add a check for a null dst_orig->dev. With this fix xfrm interface's Tx error counters go up as usual. [1] net-next calltrace ca

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated
  13. CVE-2022-50003

    Medium · CVSS 6.7EPSS 0.19%Fix available

    ice: xsk: prohibit usage of non-balanced queue id

    In the Linux kernel, the following vulnerability has been resolved: ice: xsk: prohibit usage of non-balanced queue id Fix the following scenario: 1. ethtool -L $IFACE rx 8 tx 96 2. xdpsock -q 10 -t -z Above refers to a case where user would like to attach XSK socket in txonly mode at a queue id that does not have a corresponding Rx queue. At this moment ice's XSK logic is tightly bound to act on a "queue pair", e.g. both Tx and Rx queues at a given queue id are disabled/enabled and both of them will get XSK pool assigned, which is broken for the presented queue configuration. This results in the splat included at the bottom, which is basic

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated
  14. CVE-2022-50001

    Medium · CVSS 6.8EPSS 0.19%Fix available

    netfilter: nft_tproxy: restrict to prerouting hook

    In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tproxy: restrict to prerouting hook TPROXY is only allowed from prerouting, but nft_tproxy doesn't check this. This fixes a crash (null dereference) when using tproxy from e.g. output.

    • Update to 5.15.0-1035.41~20.04.1
    Published Updated
  15. CVE-2022-50000

    High · CVSS 7.8EPSS 0.25%Fix available

    netfilter: flowtable: fix stuck flows on cleanup due to pending work

    In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix stuck flows on cleanup due to pending work To clear the flow table on flow table free, the following sequence normally happens in order: 1) gc_step work is stopped to disable any further stats/del requests. 2) All flow table entries are set to teardown state. 3) Run gc_step which will queue HW del work for each flow table entry. 4) Waiting for the above del work to finish (flush). 5) Run gc_step again, deleting all entries from the flow table. 6) Flow table is freed. But if a flow table entry already has pending HW stats or HW add wor

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated
  16. CVE-2022-49999

    High · CVSS 7.8EPSS 0.26%Fix available

    btrfs: fix space cache corruption and potential double allocations

    In the Linux kernel, the following vulnerability has been resolved: btrfs: fix space cache corruption and potential double allocations When testing space_cache v2 on a large set of machines, we encountered a few symptoms: 1. "unable to add free space :-17" (EEXIST) errors. 2. Missing free space info items, sometimes caught with a "missing free space info for X" error. 3. Double-accounted space: ranges that were allocated in the extent tree and also marked as free in the free space tree, ranges that were marked as allocated twice in the extent tree, or ranges that were marked as free twice in the free space tree. If the latter m

    • Update to 5.15.0-1027.33~20.04.1
    Published Updated
  17. CVE-2022-49998

    High · CVSS 7.8EPSS 0.2%Fix available

    rxrpc: Fix locking in rxrpc's sendmsg

    In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix locking in rxrpc's sendmsg Fix three bugs in the rxrpc's sendmsg implementation: (1) rxrpc_new_client_call() should release the socket lock when returning an error from rxrpc_get_call_slot(). (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex held in the event that we're interrupted by a signal whilst waiting for tx space on the socket or relocking the call mutex afterwards. Fix this by: (a) moving the unlock/lock of the call mutex up to rxrpc_send_data() such that the lock is not held around all of rxrpc_wai

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated
  18. CVE-2022-49996

    Medium · CVSS 5.5EPSS 0.24%Fix available

    btrfs: fix possible memory leak in btrfs_get_dev_args_from_path()

    In the Linux kernel, the following vulnerability has been resolved: btrfs: fix possible memory leak in btrfs_get_dev_args_from_path() In btrfs_get_dev_args_from_path(), btrfs_get_bdev_and_sb() can fail if the path is invalid. In this case, btrfs_get_dev_args_from_path() returns directly without freeing args->uuid and args->fsid allocated before, which causes memory leak. To fix these possible leaks, when btrfs_get_bdev_and_sb() fails, btrfs_put_dev_args_from_path() is called to clean up the memory.

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated
  19. CVE-2022-49995

    High · CVSS 7.8EPSS 0.26%Fix available

    writeback: avoid use-after-free after removing device

    In the Linux kernel, the following vulnerability has been resolved: writeback: avoid use-after-free after removing device When a disk is removed, bdi_unregister gets called to stop further writeback and wait for associated delayed work to complete. However, wb_inode_writeback_end() may schedule bandwidth estimation dwork after this has completed, which can result in the timer attempting to access the just freed bdi_writeback. Fix this by checking if the bdi_writeback is alive, similar to when scheduling writeback work. Since this requires wb->work_lock, and wb_inode_writeback_end() may get called from interrupt, switch wb->work_lock to a

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated
  20. CVE-2022-49994

    Medium · CVSS 5.5EPSS 0.24%Fix available

    bootmem: remove the vmemmap pages from kmemleak in put_page_bootmem

    In the Linux kernel, the following vulnerability has been resolved: bootmem: remove the vmemmap pages from kmemleak in put_page_bootmem The vmemmap pages is marked by kmemleak when allocated from memblock. Remove it from kmemleak when freeing the page. Otherwise, when we reuse the page, kmemleak may report such an error and then stop working. kmemleak: Cannot insert 0xffff98fb6eab3d40 into the object search tree (overlaps existing) kmemleak: Kernel memory leak detector disabled kmemleak: Object 0xffff98fb6be00000 (size 335544320): kmemleak: comm "swapper", pid 0, jiffies 4294892296 kmemleak: min_count = 0 kmemleak: count = 0

    • Update to 5.15.0-1022.28~20.04.1
    Published Updated

Check your server

Check your installed stack and versions against the current vulnerability feeds.

Check your server →