SUSE SLED12 / SLES12 Security Update : kernel (SUSE-SU-2024:1648-1)

#%NASL_MIN_LEVEL 80900
##
# (C) Tenable, Inc.
#
# The package checks in this plugin were extracted from
# SUSE update advisory SUSE-SU-2024:1648-1. The text itself
# is copyright (C) SUSE.
##

include('compat.inc');

if (description)
{
  script_id(197048);
  script_version("1.2");
  script_set_attribute(attribute:"plugin_modification_date", value:"2024/05/24");

  script_cve_id(
    "CVE-2019-25160",
    "CVE-2020-36312",
    "CVE-2021-23134",
    "CVE-2021-46904",
    "CVE-2021-46905",
    "CVE-2021-46907",
    "CVE-2021-46909",
    "CVE-2021-46938",
    "CVE-2021-46939",
    "CVE-2021-46941",
    "CVE-2021-46950",
    "CVE-2021-46958",
    "CVE-2021-46960",
    "CVE-2021-46963",
    "CVE-2021-46964",
    "CVE-2021-46966",
    "CVE-2021-46975",
    "CVE-2021-46981",
    "CVE-2021-46988",
    "CVE-2021-46990",
    "CVE-2021-46998",
    "CVE-2021-47006",
    "CVE-2021-47015",
    "CVE-2021-47024",
    "CVE-2021-47034",
    "CVE-2021-47045",
    "CVE-2021-47049",
    "CVE-2021-47055",
    "CVE-2021-47056",
    "CVE-2021-47060",
    "CVE-2021-47061",
    "CVE-2021-47063",
    "CVE-2021-47068",
    "CVE-2021-47070",
    "CVE-2021-47071",
    "CVE-2021-47073",
    "CVE-2021-47100",
    "CVE-2021-47101",
    "CVE-2021-47104",
    "CVE-2021-47110",
    "CVE-2021-47112",
    "CVE-2021-47114",
    "CVE-2021-47117",
    "CVE-2021-47118",
    "CVE-2021-47119",
    "CVE-2021-47138",
    "CVE-2021-47141",
    "CVE-2021-47142",
    "CVE-2021-47143",
    "CVE-2021-47146",
    "CVE-2021-47149",
    "CVE-2021-47150",
    "CVE-2021-47153",
    "CVE-2021-47159",
    "CVE-2021-47161",
    "CVE-2021-47162",
    "CVE-2021-47165",
    "CVE-2021-47166",
    "CVE-2021-47167",
    "CVE-2021-47168",
    "CVE-2021-47169",
    "CVE-2021-47171",
    "CVE-2021-47173",
    "CVE-2021-47177",
    "CVE-2021-47179",
    "CVE-2021-47180",
    "CVE-2021-47181",
    "CVE-2021-47182",
    "CVE-2021-47183",
    "CVE-2021-47184",
    "CVE-2021-47185",
    "CVE-2021-47188",
    "CVE-2021-47189",
    "CVE-2021-47198",
    "CVE-2021-47202",
    "CVE-2021-47203",
    "CVE-2021-47204",
    "CVE-2021-47205",
    "CVE-2021-47207",
    "CVE-2021-47211",
    "CVE-2021-47216",
    "CVE-2021-47217",
    "CVE-2022-0487",
    "CVE-2022-48619",
    "CVE-2022-48626",
    "CVE-2022-48636",
    "CVE-2022-48650",
    "CVE-2022-48651",
    "CVE-2022-48667",
    "CVE-2022-48668",
    "CVE-2022-48687",
    "CVE-2022-48688",
    "CVE-2022-48695",
    "CVE-2022-48701",
    "CVE-2023-0160",
    "CVE-2023-6270",
    "CVE-2023-6356",
    "CVE-2023-6535",
    "CVE-2023-6536",
    "CVE-2023-7042",
    "CVE-2023-7192",
    "CVE-2023-28746",
    "CVE-2023-35827",
    "CVE-2023-52454",
    "CVE-2023-52469",
    "CVE-2023-52470",
    "CVE-2023-52474",
    "CVE-2023-52476",
    "CVE-2023-52477",
    "CVE-2023-52486",
    "CVE-2023-52488",
    "CVE-2023-52509",
    "CVE-2023-52515",
    "CVE-2023-52524",
    "CVE-2023-52528",
    "CVE-2023-52575",
    "CVE-2023-52583",
    "CVE-2023-52587",
    "CVE-2023-52590",
    "CVE-2023-52591",
    "CVE-2023-52595",
    "CVE-2023-52598",
    "CVE-2023-52607",
    "CVE-2023-52614",
    "CVE-2023-52620",
    "CVE-2023-52628",
    "CVE-2023-52635",
    "CVE-2023-52639",
    "CVE-2023-52644",
    "CVE-2023-52646",
    "CVE-2023-52650",
    "CVE-2023-52652",
    "CVE-2023-52653",
    "CVE-2024-2201",
    "CVE-2024-22099",
    "CVE-2024-23307",
    "CVE-2024-23848",
    "CVE-2024-24855",
    "CVE-2024-24861",
    "CVE-2024-26614",
    "CVE-2024-26642",
    "CVE-2024-26651",
    "CVE-2024-26671",
    "CVE-2024-26675",
    "CVE-2024-26689",
    "CVE-2024-26704",
    "CVE-2024-26733",
    "CVE-2024-26739",
    "CVE-2024-26743",
    "CVE-2024-26744",
    "CVE-2024-26747",
    "CVE-2024-26754",
    "CVE-2024-26763",
    "CVE-2024-26771",
    "CVE-2024-26772",
    "CVE-2024-26773",
    "CVE-2024-26777",
    "CVE-2024-26778",
    "CVE-2024-26779",
    "CVE-2024-26793",
    "CVE-2024-26805",
    "CVE-2024-26816",
    "CVE-2024-26817",
    "CVE-2024-26839",
    "CVE-2024-26840",
    "CVE-2024-26852",
    "CVE-2024-26855",
    "CVE-2024-26857",
    "CVE-2024-26859",
    "CVE-2024-26878",
    "CVE-2024-26883",
    "CVE-2024-26884",
    "CVE-2024-26898",
    "CVE-2024-26901",
    "CVE-2024-26903",
    "CVE-2024-26907",
    "CVE-2024-26922",
    "CVE-2024-26929",
    "CVE-2024-26930",
    "CVE-2024-26931",
    "CVE-2024-26948",
    "CVE-2024-26993",
    "CVE-2024-27013",
    "CVE-2024-27014",
    "CVE-2024-27043",
    "CVE-2024-27046",
    "CVE-2024-27054",
    "CVE-2024-27072",
    "CVE-2024-27073",
    "CVE-2024-27074",
    "CVE-2024-27075",
    "CVE-2024-27078",
    "CVE-2024-27388"
  );
  script_xref(name:"SuSE", value:"SUSE-SU-2024:1648-1");

  script_name(english:"SUSE SLED12 / SLES12 Security Update : kernel (SUSE-SU-2024:1648-1)");

  script_set_attribute(attribute:"synopsis", value:
"The remote SUSE host is missing one or more security updates.");
  script_set_attribute(attribute:"description", value:
"The remote SUSE Linux SLED12 / SLED_SAP12 / SLES12 / SLES_SAP12 host has packages installed that are affected by
multiple vulnerabilities as referenced in the SUSE-SU-2024:1648-1 advisory.

  - In the Linux kernel, the following vulnerability has been resolved: netlabel: fix out-of-bounds memory
    accesses There are two array out-of-bounds memory accesses, one in cipso_v4_map_lvl_valid(), the other in
    netlbl_bitmap_walk(). Both errors are embarassingly simple, and the fixes are straightforward. As a FYI
    for anyone backporting this patch to kernels prior to v4.8, you'll want to apply the netlbl_bitmap_walk()
    patch to cipso_v4_bitmap_walk() as netlbl_bitmap_walk() doesn't exist before Linux v4.8. (CVE-2019-25160)

  - An issue was discovered in the Linux kernel before 5.8.10. virt/kvm/kvm_main.c has a
    kvm_io_bus_unregister_dev memory leak upon a kmalloc failure, aka CID-f65886606c2d. (CVE-2020-36312)

  - Use After Free vulnerability in nfc sockets in the Linux Kernel before 5.12.4 allows local attackers to
    elevate their privileges. In typical configurations, the issue can only be triggered by a privileged local
    user with the CAP_NET_RAW capability. (CVE-2021-23134)

  - In the Linux kernel, the following vulnerability has been resolved: net: hso: fix null-ptr-deref during
    tty device unregistration Multiple ttys try to claim the same the minor number causing a double
    unregistration of the same device. The first unregistration succeeds but the next one results in a null-
    ptr-deref. The get_free_serial_index() function returns an available minor number but doesn't assign it
    immediately. The assignment is done by the caller later. But before this assignment, calls to
    get_free_serial_index() would return the same minor number. Fix this by modifying get_free_serial_index to
    assign the minor number immediately after one is found to be and rename it to obtain_minor() to better
    reflect what it does. Similary, rename set_serial_by_index() to release_minor() and modify it to free up
    the minor number of the given hso_serial. Every obtain_minor() should have corresponding release_minor()
    call. (CVE-2021-46904)

  - In the Linux kernel, the following vulnerability has been resolved: net: hso: fix NULL-deref on disconnect
    regression Commit 8a12f8836145 (net: hso: fix null-ptr-deref during tty device unregistration) fixed the
    racy minor allocation reported by syzbot, but introduced an unconditional NULL-pointer dereference on
    every disconnect instead. Specifically, the serial device table must no longer be accessed after the minor
    has been released by hso_serial_tty_unregister(). (CVE-2021-46905)

  - Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
    (CVE-2021-46907, CVE-2021-46975, CVE-2023-52575)

  - In the Linux kernel, the following vulnerability has been resolved: ARM: footbridge: fix PCI interrupt
    mapping Since commit 30fdfb929e82 (PCI: Add a call to pci_assign_irq() in pci_device_probe()), the PCI
    code will call the IRQ mapping function whenever a PCI driver is probed. If these are marked as __init,
    this causes an oops if a PCI driver is loaded or bound after the kernel has initialised. (CVE-2021-46909)

  - In the Linux kernel, the following vulnerability has been resolved: dm rq: fix double free of
    blk_mq_tag_set in dev remove after table load fails When loading a device-mapper table for a request-based
    mapped device, and the allocation/initialization of the blk_mq_tag_set for the device fails, a following
    device remove will cause a double free. E.g. (dmesg): device-mapper: core: Cannot initialize queue for
    request-based dm-mq mapped device device-mapper: ioctl: unable to set up device queue for new table.
    Unable to handle kernel pointer dereference in virtual kernel address space Failing address:
    0305e098835de000 TEID: 0305e098835de803 Fault in home space mode while using kernel ASCE.
    AS:000000025efe0007 R3:0000000000000024 Oops: 0038 ilc:3 [#1] SMP Modules linked in: ... lots of modules
    ... Supported: Yes, External CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G W X
    5.3.18-53-default #1 SLE15-SP3 Hardware name: IBM 8561 T01 7I2 (LPAR) Krnl PSW : 0704e00180000000
    000000025e368eca (kfree+0x42/0x330) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl
    GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000 000000025e520270
    000000025e8d1b40 0000000000000003 00000007aae10000 000000025e5202a2 0000000000000001 c1773200d779968d
    0305e098835de640 00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8 Krnl Code:
    000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58
    #000000025e368ec4: e3b010000008 ag %r11,0(%r1) >000000025e368eca: e310b0080004 lg %r1,8(%r11)
    000000025e368ed0: a7110001 tmll %r1,1 000000025e368ed4: a7740129 brc 7,25e369126 000000025e368ed8:
    e320b0080004 lg %r2,8(%r11) 000000025e368ede: b904001b lgr %r1,%r11 Call Trace: [<000000025e368eca>]
    kfree+0x42/0x330 [<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8 [<000003ff801316a8>]
    dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod] [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod]
    [<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod] [<000003ff8012bb9a>] dev_remove+0x162/0x1c0
    [dm_mod] [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod] [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38
    [dm_mod] [<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0 [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40
    [<000000025e8c15ac>] system_call+0xd8/0x2c8 Last Breaking-Event-Address: [<000000025e52029c>]
    blk_mq_free_tag_set+0x6c/0xb8 Kernel panic - not syncing: Fatal exception: panic_on_oops When
    allocation/initialization of the blk_mq_tag_set fails in dm_mq_init_request_queue(), it is
    uninitialized/freed, but the pointer is not reset to NULL; so when dev_remove() later gets into
    dm_mq_cleanup_mapped_device() it sees the pointer and tries to uninitialize and free it again. Fix this by
    setting the pointer to NULL in dm_mq_init_request_queue() error-handling. Also set it to NULL in
    dm_mq_cleanup_mapped_device(). (CVE-2021-46938)

  - In the Linux kernel, the following vulnerability has been resolved: tracing: Restructure
    trace_clock_global() to never block It was reported that a fix to the ring buffer recursion detection
    would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted
    from debugging that case: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460
    ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80
    trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ?
    pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ?
    trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ?
    trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ?
    trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ?
    pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ?
    trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0 With the following RIP: RIP:
    0010:native_queued_spin_lock_slowpath+0x69/0x200 Since the fix to the recursion detection would allow a
    single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and
    then trying to take it again: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() {
    queued_spin_lock_slowpath() { /* lock taken */ (something else gets traced by function graph tracer)
    ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /*
    DEAD LOCK! */ Tracing should *never* block, as it can lead to strange lockups like the above. Restructure
    the trace_clock_global() code to instead of simply taking a lock to update the recorded prev_time simply
    use it, as two events happening on two different CPUs that calls this at the same time, really doesn't
    matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails,
    simply try again the next time. If it failed to be taken, that means something else is already updating
    it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761 (CVE-2021-46939)

  - In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: Do core softreset
    when switch mode According to the programming guide, to switch mode for DRD controller, the driver needs
    to do the following. To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set
    GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing
    host registers sequence To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set
    GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing
    registers sequence Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from
    host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1].
    Similar issue is observed with Ferry's testing platform[2]. So, apply the required steps along with some
    fixes to Yu Chen's and John Stultz's version. The main fixes to their versions are the missing wait for
    clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from
    host to device. [1] https://lore.kernel.org/linux-usb/[email protected]/ [2]
    https://lore.kernel.org/linux-usb/[email protected]/ (CVE-2021-46941)

  - In the Linux kernel, the following vulnerability has been resolved: md/raid1: properly indicate failure
    when ending a failed write request This patch addresses a data corruption bug in raid1 arrays using
    bitmaps. Without this fix, the bitmap bits for the failed I/O end up being cleared. Since we are in the
    failure leg of raid1_end_write_request, the request either needs to be retried (R1BIO_WriteError) or
    failed (R1BIO_Degraded). (CVE-2021-46950)

  - In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race between transaction
    aborts and fsyncs leading to use-after-free There is a race between a task aborting a transaction during a
    commit, a task doing an fsync and the transaction kthread, which leads to an use-after-free of the log
    root tree. When this happens, it results in a stack trace like the following: BTRFS info (device dm-0):
    forced readonly BTRFS warning (device dm-0): Skipping commit of aborted transaction. BTRFS: error (device
    dm-0) in cleanup_transaction:1958: errno=-5 IO failure BTRFS warning (device dm-0): lost page write due to
    IO error on /dev/mapper/error-test (-5) BTRFS warning (device dm-0): Skipping commit of aborted
    transaction. BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0xa4e8 len 4096 err no 10
    BTRFS error (device dm-0): error writing primary super block to device 1 BTRFS warning (device dm-0):
    direct IO failed ino 261 rw 0,0 sector 0x12e000 len 4096 err no 10 BTRFS warning (device dm-0): direct IO
    failed ino 261 rw 0,0 sector 0x12e008 len 4096 err no 10 BTRFS warning (device dm-0): direct IO failed ino
    261 rw 0,0 sector 0x12e010 len 4096 err no 10 BTRFS: error (device dm-0) in write_all_supers:4110:
    errno=-5 IO failure (1 errors while writing supers) BTRFS: error (device dm-0) in btrfs_sync_log:3308:
    errno=-5 IO failure general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b68: 0000
    [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 2 PID: 2458471 Comm: fsstress Not tainted 5.12.0-rc5-btrfs-
    next-84 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
    rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x139/0xa40 Code: c0 74 19
    (...) RSP: 0018:ffff9f18830d7b00 EFLAGS: 00010202 RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000000001 RCX:
    0000000000000002 RDX: ffffffffb9c54d13 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff9f18830d7bc0
    R08: 0000000000000000 R09: 0000000000000000 R10: ffff9f18830d7be0 R11: 0000000000000001 R12:
    ffff8c6cd199c040 R13: ffff8c6c95821358 R14: 00000000fffffffb R15: ffff8c6cbcf01358 FS:
    00007fa9140c2b80(0000) GS:ffff8c6fac600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 00007fa913d52000 CR3: 000000013d2b4003 CR4: 0000000000370ee0 DR0: 0000000000000000
    DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 Call Trace: ? __btrfs_handle_fs_error+0xde/0x146 [btrfs] ? btrfs_sync_log+0x7c1/0xf20
    [btrfs] ? btrfs_sync_log+0x7c1/0xf20 [btrfs] btrfs_sync_log+0x7c1/0xf20 [btrfs]
    btrfs_sync_file+0x40c/0x580 [btrfs] do_fsync+0x38/0x70 __x64_sys_fsync+0x10/0x20 do_syscall_64+0x33/0x80
    entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fa9142a55c3 Code: 8b 15 09 (...) RSP:
    002b:00007fff26278d48 EFLAGS: 00000246 ORIG_RAX: 000000000000004a RAX: ffffffffffffffda RBX:
    0000563c83cb4560 RCX: 00007fa9142a55c3 RDX: 00007fff26278cb0 RSI: 00007fff26278cb0 RDI: 0000000000000005
    RBP: 0000000000000005 R08: 0000000000000001 R09: 00007fff26278d5c R10: 0000000000000000 R11:
    0000000000000246 R12: 0000000000000340 R13: 00007fff26278de0 R14: 00007fff26278d96 R15: 0000563c83ca57c0
    Modules linked in: btrfs dm_zero dm_snapshot dm_thin_pool (...) ---[ end trace ee2f1b19327d791d ]--- The
    steps that lead to this crash are the following: 1) We are at transaction N; 2) We have two tasks with a
    transaction handle attached to transaction N. Task A and Task B. Task B is doing an fsync; 3) Task B is at
    btrfs_sync_log(), and has saved fs_info->log_root_tree into a local variable named 'log_root_tree' at the
    top of btrfs_sync_log(). Task B is about to call write_all_supers(), but before that... 4) Task A calls
    btrfs_commit_transaction(), and after it sets the transaction state to TRANS_STATE_COMMIT_START, an error
    happens before it w ---truncated--- (CVE-2021-46958)

  - In the Linux kernel, the following vulnerability has been resolved: cifs: Return correct error code from
    smb2_get_enc_key Avoid a warning if the error percolates back up: [440700.376476] CIFS VFS:
    \\otters.example.com crypt_message: Could not get encryption key [440700.386947] ------------[ cut here
    ]------------ [440700.386948] err = 1 [440700.386977] WARNING: CPU: 11 PID: 2733 at /build/linux-
    hwe-5.4-p6lk6L/linux-hwe-5.4-5.4.0/lib/errseq.c:74 errseq_set+0x5c/0x70 ... [440700.397304] CPU: 11 PID:
    2733 Comm: tar Tainted: G OE 5.4.0-70-generic #78~18.04.1-Ubuntu ... [440700.397334] Call Trace:
    [440700.397346] __filemap_set_wb_err+0x1a/0x70 [440700.397419] cifs_writepages+0x9c7/0xb30 [cifs]
    [440700.397426] do_writepages+0x4b/0xe0 [440700.397444] __filemap_fdatawrite_range+0xcb/0x100
    [440700.397455] filemap_write_and_wait+0x42/0xa0 [440700.397486] cifs_setattr+0x68b/0xf30 [cifs]
    [440700.397493] notify_change+0x358/0x4a0 [440700.397500] utimes_common+0xe9/0x1c0 [440700.397510]
    do_utimes+0xc5/0x150 [440700.397520] __x64_sys_utimensat+0x88/0xd0 (CVE-2021-46960)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix crash in
    qla2xxx_mqueuecommand() RIP: 0010:kmem_cache_free+0xfa/0x1b0 Call Trace: qla2xxx_mqueuecommand+0x2b5/0x2c0
    [qla2xxx] scsi_queue_rq+0x5e2/0xa40 __blk_mq_try_issue_directly+0x128/0x1d0
    blk_mq_request_issue_directly+0x4e/0xb0 Fix incorrect call to free srb in qla2xxx_mqueuecommand(), as srb
    is now allocated by upper layers. This fixes smatch warning of srb unintended free. (CVE-2021-46963)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Reserve extra IRQ
    vectors Commit a6dcfe08487e (scsi: qla2xxx: Limit interrupt vectors to number of CPUs) lowers the number
    of allocated MSI-X vectors to the number of CPUs. That breaks vector allocation assumptions in
    qla83xx_iospace_config(), qla24xx_enable_msix() and qla2x00_iospace_config(). Either of the functions
    computes maximum number of qpairs as: ha->max_qpairs = ha->msix_count - 1 (MB interrupt) - 1 (default
    response queue) - 1 (ATIO, in dual or pure target mode) max_qpairs is set to zero in case of two CPUs and
    initiator mode. The number is then used to allocate ha->queue_pair_map inside qla2x00_alloc_queues(). No
    allocation happens and ha->queue_pair_map is left NULL but the driver thinks there are queue pairs
    available. qla2xxx_queuecommand() tries to find a qpair in the map and crashes: if (ha->mqenable) {
    uint32_t tag; uint16_t hwq; struct qla_qpair *qpair = NULL; tag = blk_mq_unique_tag(cmd->request); hwq =
    blk_mq_unique_tag_to_hwq(tag); qpair = ha->queue_pair_map[hwq]; # <- HERE if (qpair) return
    qla2xxx_mqueuecommand(host, cmd, qpair); } BUG: kernel NULL pointer dereference, address: 0000000000000000
    #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops:
    0000 [#1] SMP PTI CPU: 0 PID: 72 Comm: kworker/u4:3 Tainted: G W 5.10.0-rc1+ #25 Hardware name: QEMU
    Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Workqueue: scsi_wq_7
    fc_scsi_scan_rport [scsi_transport_fc] RIP: 0010:qla2xxx_queuecommand+0x16b/0x3f0 [qla2xxx] Call Trace:
    scsi_queue_rq+0x58c/0xa60 blk_mq_dispatch_rq_list+0x2b7/0x6f0 ? __sbitmap_get_word+0x2a/0x80
    __blk_mq_sched_dispatch_requests+0xb8/0x170 blk_mq_sched_dispatch_requests+0x2b/0x50
    __blk_mq_run_hw_queue+0x49/0xb0 __blk_mq_delay_run_hw_queue+0xfb/0x150
    blk_mq_sched_insert_request+0xbe/0x110 blk_execute_rq+0x45/0x70 __scsi_execute+0x10e/0x250
    scsi_probe_and_add_lun+0x228/0xda0 __scsi_scan_target+0xf4/0x620 ? __pm_runtime_resume+0x4f/0x70
    scsi_scan_target+0x100/0x110 fc_scsi_scan_rport+0xa1/0xb0 [scsi_transport_fc] process_one_work+0x1ea/0x3b0
    worker_thread+0x28/0x3b0 ? process_one_work+0x3b0/0x3b0 kthread+0x112/0x130 ? kthread_park+0x80/0x80
    ret_from_fork+0x22/0x30 The driver should allocate enough vectors to provide every CPU it's own HW queue
    and still handle reserved (MB, RSP, ATIO) interrupts. The change fixes the crash on dual core VM and
    prevents unbalanced QP allocation where nr_hw_queues is two less than the number of CPUs. (CVE-2021-46964)

  - In the Linux kernel, the following vulnerability has been resolved: ACPI: custom_method: fix potential
    use-after-free issue In cm_write(), buf is always freed when reaching the end of the function. If the
    requested count is less than table.length, the allocated buffer will be freed but subsequent calls to
    cm_write() will still try to access it. Remove the unconditional kfree(buf) at the end of the function and
    set the buf to NULL in the -EINVAL error path to match the rest of function. (CVE-2021-46966)

  - In the Linux kernel, the following vulnerability has been resolved: nbd: Fix NULL pointer in
    flush_workqueue Open /dev/nbdX first, the config_refs will be 1 and the pointers in nbd_device are still
    null. Disconnect /dev/nbdX, then reference a null recv_workq. The protection by config_refs in
    nbd_genl_disconnect is useless. [ 656.366194] BUG: kernel NULL pointer dereference, address:
    0000000000000020 [ 656.368943] #PF: supervisor write access in kernel mode [ 656.369844] #PF:
    error_code(0x0002) - not-present page [ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0 [
    656.371693] Oops: 0002 [#1] SMP [ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted
    5.11.0-rc5-00040-g76c057c84d28 #1 [ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
    BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 656.375904] RIP:
    0010:mutex_lock+0x29/0x60 [ 656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a
    c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 <f0> 48 0f b1 55 d [ 656.378934] RSP:
    0018:ffffc900005eb9b0 EFLAGS: 00010246 [ 656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
    0000000000000000 [ 656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020 [
    656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318 [ 656.381039] R10:
    00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40 [ 656.381599] R13: ffffc900005eb9e0 R14:
    ffffffffb2930680 R15: ffff88810770ef00 [ 656.382166] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000)
    knlGS:0000000000000000 [ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 656.383261] CR2:
    0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0 [ 656.383819] DR0: 0000000000000000 DR1:
    0000000000000000 DR2: 0000000000000000 [ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
    0000000000000400 [ 656.384927] Call Trace: [ 656.385111] flush_workqueue+0x92/0x6c0 [ 656.385395]
    nbd_disconnect_and_put+0x81/0xd0 [ 656.385716] nbd_genl_disconnect+0x125/0x2a0 [ 656.386034]
    genl_family_rcv_msg_doit.isra.0+0x102/0x1b0 [ 656.386422] genl_rcv_msg+0xfc/0x2b0 [ 656.386685] ?
    nbd_ioctl+0x490/0x490 [ 656.386954] ? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0 [ 656.387354]
    netlink_rcv_skb+0x62/0x180 [ 656.387638] genl_rcv+0x34/0x60 [ 656.387874] netlink_unicast+0x26d/0x590 [
    656.388162] netlink_sendmsg+0x398/0x6c0 [ 656.388451] ? netlink_rcv_skb+0x180/0x180 [ 656.388750]
    ____sys_sendmsg+0x1da/0x320 [ 656.389038] ? ____sys_recvmsg+0x130/0x220 [ 656.389334]
    ___sys_sendmsg+0x8e/0xf0 [ 656.389605] ? ___sys_recvmsg+0xa2/0xf0 [ 656.389889] ?
    handle_mm_fault+0x1671/0x21d0 [ 656.390201] __sys_sendmsg+0x6d/0xe0 [ 656.390464]
    __x64_sys_sendmsg+0x23/0x30 [ 656.390751] do_syscall_64+0x45/0x70 [ 656.391017]
    entry_SYSCALL_64_after_hwframe+0x44/0xa9 To fix it, just add if (nbd->recv_workq) to
    nbd_disconnect_and_put(). (CVE-2021-46981)

  - In the Linux kernel, the following vulnerability has been resolved: userfaultfd: release page in error
    path to avoid BUG_ON Consider the following sequence of events: 1. Userspace issues a UFFD ioctl, which
    ends up calling into shmem_mfill_atomic_pte(). We successfully account the blocks, we shmem_alloc_page(),
    but then the copy_from_user() fails. We return -ENOENT. We don't release the page we allocated. 2. Our
    caller detects this error code, tries the copy_from_user() after dropping the mmap_lock, and retries,
    calling back into shmem_mfill_atomic_pte(). 3. Meanwhile, let's say another process filled up the tmpfs
    being used. 4. So shmem_mfill_atomic_pte() fails to account blocks this time, and immediately returns -
    without releasing the page. This triggers a BUG_ON in our caller, which asserts that the page should
    always be consumed, unless -ENOENT is returned. To fix this, detect if we have such a dangling page when
    accounting fails, and if so, release it before returning. (CVE-2021-46988)

  - In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix crashes when toggling
    entry flush barrier The entry flush mitigation can be enabled/disabled at runtime via a debugfs file
    (entry_flush), which causes the kernel to patch itself to enable/disable the relevant mitigations. However
    depending on which mitigation we're using, it may not be safe to do that patching while other CPUs are
    active. For example the following crash: sleeper[15639]: segfault (11) at c000000000004c20 nip
    c000000000004c20 lr c000000000004c20 Shows that we returned to userspace with a corrupted LR that points
    into the kernel, due to executing the partially patched call to the fallback entry flush (ie. we missed
    the LR restore). Fix it by doing the patching under stop machine. The CPUs that aren't doing the patching
    will be spinning in the core of the stop machine logic. That is currently sufficient for our purposes,
    because none of the patching we do is to that code or anywhere in the vicinity. (CVE-2021-46990)

  - In the Linux kernel, the following vulnerability has been resolved: ethernet:enic: Fix a use after free
    bug in enic_hard_start_xmit In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside
    enic_queue_wq_skb, if some error happens, the skb will be freed by dev_kfree_skb(skb). But the freed skb
    is still used in skb_tx_timestamp(skb). My patch makes enic_queue_wq_skb() return error and goto
    spin_unlock() incase of error. The solution is provided by Govind. See
    https://lkml.org/lkml/2021/4/30/961. (CVE-2021-46998)

  - In the Linux kernel, the following vulnerability has been resolved: ARM: 9064/1: hw_breakpoint: Do not
    directly check the event's overflow_handler hook The commit 1879445dfa7b (perf/core: Set event's default
    ::overflow_handler()) set a default event->overflow_handler in perf_event_alloc(), and replace the check
    event->overflow_handler with is_default_overflow_handler(), but one is missing. Currently, the
    bp->overflow_handler can not be NULL. As a result, enable_single_step() is always not invoked. Comments
    from Zhen Lei: https://patchwork.kernel.org/project/linux-arm-
    kernel/patch/[email protected]/ (CVE-2021-47006)

  - In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix RX consumer index logic
    in the error path. In bnxt_rx_pkt(), the RX buffers are expected to complete in order. If the RX consumer
    index indicates an out of order buffer completion, it means we are hitting a hardware bug and the driver
    will abort all remaining RX packets and reset the RX ring. The RX consumer index that we pass to
    bnxt_discard_rx() is not correct. We should be passing the current index (tmp_raw_cons) instead of the old
    index (raw_cons). This bug can cause us to be at the wrong index when trying to abort the next RX packet.
    It can crash like this: #0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007 #1 [ffff9bbcdf5c3a00]
    __crash_kexec at ffffffff9b111232 #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e #3 [ffff9bbcdf5c3b50]
    oops_end at ffffffff9b030978 #4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0 #5 [ffff9bbcdf5c3bd8]
    __bad_area_nosemaphore at ffffffff9b06ae2e #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24
    #7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e #8 [ffff9bbcdf5c3cb0] do_page_fault at
    ffffffff9b06bb12 #9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5 [exception RIP: bnxt_rx_pkt+237]
    RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213 RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0
    RCX: ffffa923cf6e9000 RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000 RBP:
    ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83
    R12: ffff9ba4d6f928c0 R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000 ORIG_RAX:
    ffffffffffffffff CS: 0010 SS: 0018 (CVE-2021-47015)

  - In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: free queued packets when
    closing socket As reported by syzbot [1], there is a memory leak while closing the socket. We partially
    solved this issue with commit ac03046ece2b (vsock/virtio: free packets during the socket release), but
    we forgot to drain the RX queue when the socket is definitely closed by the scheduled work. To avoid
    future issues, let's use the new virtio_transport_remove_sock() to drain the RX queue before removing the
    socket from the af_vsock lists calling vsock_remove_sock(). [1]
    https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9 (CVE-2021-47024)

  - In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix pte update for kernel
    memory on radix When adding a PTE a ptesync is needed to order the update of the PTE with subsequent
    accesses otherwise a spurious fault may be raised. radix__set_pte_at() does not do this for performance
    gains. For non-kernel memory this is not an issue as any faults of this kind are corrected by the page
    fault handler. For kernel memory these faults are not handled. The current solution is that there is a
    ptesync in flush_cache_vmap() which should be called when mapping from the vmalloc region. However,
    map_kernel_page() does not call flush_cache_vmap(). This is troublesome in particular for code patching
    with Strict RWX on radix. In do_patch_instruction() the page frame that contains the instruction to be
    patched is mapped and then immediately patched. With no ordering or synchronization between setting up the
    PTE and writing to the page it is possible for faults. As the code patching is done using
    __put_user_asm_goto() the resulting fault is obscured - but using a normal store instead it can be seen:
    BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c Faulting instruction address:
    0xc00000000008bd74 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP
    NR_CPUS=2048 NUMA PowerNV Modules linked in: nop_module(PO+) [last unloaded: nop_module] CPU: 4 PID: 757
    Comm: sh Tainted: P O 5.10.0-rc5-01361-ge3c1b78c8440-dirty #43 NIP: c00000000008bd74 LR: c00000000008bd50
    CTR: c000000000025810 REGS: c000000016f634a0 TRAP: 0300 Tainted: P O
    (5.10.0-rc5-01361-ge3c1b78c8440-dirty) MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 44002884 XER:
    00000000 CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1 This results in the kind
    of issue reported here: https://lore.kernel.org/linuxppc-dev/[email protected]/
    Chris Riedl suggested a reliable way to reproduce the issue: $ mount -t debugfs none /sys/kernel/debug $
    (while true; do echo function > /sys/kernel/debug/tracing/current_tracer ; echo nop >
    /sys/kernel/debug/tracing/current_tracer ; done) & Turning ftrace on and off does a large amount of code
    patching which in usually less then 5min will crash giving a trace like: ftrace-powerpc: (____ptrval____):
    replaced (4b473b11) != old (60000000) ------------[ ftrace bug ]------------ ftrace failed to modify
    [<c000000000bf8e5c>] napi_busy_loop+0xc/0x390 actual: 11:3b:47:4b Setting ftrace call site to call ftrace
    function ftrace record flags: 80000001 (1) expected tramp: c00000000006c96c ------------[ cut here
    ]------------ WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8 Modules linked
    in: nop_module(PO-) [last unloaded: nop_module] CPU: 4 PID: 809 Comm: sh Tainted: P O
    5.10.0-rc5-01360-gf878ccaf250a #1 NIP: c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0 REGS:
    c000000004c8b760 TRAP: 0700 Tainted: P O (5.10.0-rc5-01360-gf878ccaf250a) MSR: 900000000282b033
    <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28008848 XER: 20040000 CFAR: c0000000001a9c98 IRQMASK: 0 GPR00:
    c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022 GPR04: 00000000ffff7fff
    c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8 GPR08: 0000000000000023 ffffffffffffffd8
    0000000000000027 c000000002613118 GPR12: 0000000000008000 c0000007fffdca00 0000000000000000
    0000000000000000 GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008 GPR20:
    c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8 GPR24: 0000000000000038
    0000000000000030 0000000000000028 0000000000000020 GPR28: c000000000ff1b68 c000000000bf8e5c
    c00000000312f700 c000000000fbb9b0 NIP ftrace_bug+0x28c/0x2e8 LR ftrace_bug+0x288/0x2e8 Call T
    ---truncated--- (CVE-2021-47034)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix null pointer
    dereference in lpfc_prep_els_iocb() It is possible to call lpfc_issue_els_plogi() passing a did for which
    no matching ndlp is found. A call is then made to lpfc_prep_els_iocb() with a null pointer to a
    lpfc_nodelist structure resulting in a null pointer dereference. Fix by returning an error status if no
    valid ndlp is found. Fix up comments regarding ndlp reference counting. (CVE-2021-47045)

  - In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Use after free in
    __vmbus_open() The open_info variable is added to the &vmbus_connection.chn_msg_list, but the error
    handling frees open_info without removing it from the list. This will result in a use after free. First
    remove it from the list, and then free it. (CVE-2021-47049)

  - In the Linux kernel, the following vulnerability has been resolved: mtd: require write permissions for
    locking and badblock ioctls MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require write
    permission. Depending on the hardware MEMLOCK might even be write-once, e.g. for SPI-NOR flashes with
    their WP# tied to GND. OTPLOCK is always write-once. MEMSETBADBLOCK modifies the bad block table.
    (CVE-2021-47055)

  - In the Linux kernel, the following vulnerability has been resolved: crypto: qat - ADF_STATUS_PF_RUNNING
    should be set after adf_dev_init ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown()
    before calling adf_iov_putmsg()->mutex_lock(vf2pf_lock), however the vf2pf_lock is initialized in
    adf_dev_init(), which can fail and when it fail, the vf2pf_lock is either not initialized or destroyed, a
    subsequent use of vf2pf_lock will cause issue. To fix this issue, only set this flag if adf_dev_init()
    returns 0. [ 7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0 [ 7.180345] Call
    Trace: [ 7.182576] mutex_lock+0xc9/0xd0 [ 7.183257] adf_iov_putmsg+0x118/0x1a0 [intel_qat] [ 7.183541]
    adf_vf2pf_shutdown+0x4d/0x7b [intel_qat] [ 7.183834] adf_dev_shutdown+0x172/0x2b0 [intel_qat] [ 7.184127]
    adf_probe+0x5e9/0x600 [qat_dh895xccvf] (CVE-2021-47056)

  - In the Linux kernel, the following vulnerability has been resolved: KVM: Stop looking for coalesced MMIO
    zones if the bus is destroyed Abort the walk of coalesced MMIO zones if kvm_io_bus_unregister_dev() fails
    to allocate memory for the new instance of the bus. If it can't instantiate a new bus, unregister_dev()
    destroys all devices _except_ the target device. But, it doesn't tell the caller that it obliterated the
    bus and invoked the destructor for all devices that were on the bus. In the coalesced MMIO case, this can
    result in a deleted list entry dereference due to attempting to continue iterating on coalesced_zones
    after future entries (in the walk) have been deleted. Opportunistically add curly braces to the for-loop,
    which encompasses many lines but sneaks by without braces due to the guts being a single if statement.
    (CVE-2021-47060)

  - In the Linux kernel, the following vulnerability has been resolved: KVM: Destroy I/O bus devices on
    unregister failure _after_ sync'ing SRCU If allocating a new instance of an I/O bus fails when
    unregistering a device, wait to destroy the device until after all readers are guaranteed to see the new
    null bus. Destroying devices before the bus is nullified could lead to use-after-free since readers expect
    the devices on their reference of the bus to remain valid. (CVE-2021-47061)

  - In the Linux kernel, the following vulnerability has been resolved: drm: bridge/panel: Cleanup connector
    on bridge detach If we don't call drm_connector_cleanup() manually in panel_bridge_detach(), the connector
    will be cleaned up with the other DRM objects in the call to drm_mode_config_cleanup(). However, since our
    drm_connector is devm-allocated, by the time drm_mode_config_cleanup() will be called, our connector will
    be long gone. Therefore, the connector must be cleaned up when the bridge is detached to avoid use-after-
    free conditions. v2: Cleanup connector only if it was created v3: Add FIXME v4: (Use connector->dev)
    directly in if() block (CVE-2021-47063)

  - In the Linux kernel, the following vulnerability has been resolved: net/nfc: fix use-after-free
    llcp_sock_bind/connect Commits 8a4cd82d (nfc: fix refcount leak in llcp_sock_connect()) and c33b1cc62
    (nfc: fix refcount leak in llcp_sock_bind()) fixed a refcount leak bug in bind/connect but introduced a
    use-after-free if the same local is assigned to 2 different sockets. This can be triggered by the
    following simple program: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 =
    socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) );
    addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) &addr,
    sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp)
    ) close(sock1); close(sock2); Fix this by assigning NULL to llcp_sock->local after calling
    nfc_llcp_local_put. This addresses CVE-2021-23134. (CVE-2021-47068)

  - In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix another memory
    leak in error handling paths Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe
    function is never freed in the error handling path. Add the missing 'vmbus_free_ring()' call. Note that it
    is already freed in the .remove function. (CVE-2021-47070)

  - In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix a memory leak in
    error handling paths If 'vmbus_establish_gpadl()' fails, the (recv|send)_gpadl will not be updated and
    'hv_uio_cleanup()' in the error handling path will not be able to free the corresponding buffer. In such a
    case, we need to free the buffer explicitly. (CVE-2021-47071)

  - In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-smbios-wmi: Fix
    oops on rmmod dell_smbios init_dell_smbios_wmi() only registers the dell_smbios_wmi_driver on systems
    where the Dell WMI interface is supported. While exit_dell_smbios_wmi() unregisters it unconditionally,
    this leads to the following oops: [ 175.722921] ------------[ cut here ]------------ [ 175.722925]
    Unexpected driver unregister! [ 175.722939] WARNING: CPU: 1 PID: 3630 at drivers/base/driver.c:194
    driver_unregister+0x38/0x40 ... [ 175.723089] Call Trace: [ 175.723094] cleanup_module+0x5/0xedd
    [dell_smbios] ... [ 175.723148] ---[ end trace 064c34e1ad49509d ]--- Make the unregister happen on the
    same condition the register happens to fix this. (CVE-2021-47073)

  - In the Linux kernel, the following vulnerability has been resolved: ipmi: Fix UAF when uninstall ipmi_si
    and ipmi_msghandler module Hi, When testing install and uninstall of ipmi_si.ko and ipmi_msghandler.ko,
    the system crashed. The log as follows: [ 141.087026] BUG: unable to handle kernel paging request at
    ffffffffc09b3a5a [ 141.087241] PGD 8fe4c0d067 P4D 8fe4c0d067 PUD 8fe4c0f067 PMD 103ad89067 PTE 0 [
    141.087464] Oops: 0010 [#1] SMP NOPTI [ 141.087580] CPU: 67 PID: 668 Comm: kworker/67:1 Kdump: loaded Not
    tainted 4.18.0.x86_64 #47 [ 141.088009] Workqueue: events 0xffffffffc09b3a40 [ 141.088009] RIP:
    0010:0xffffffffc09b3a5a [ 141.088009] Code: Bad RIP value. [ 141.088009] RSP: 0018:ffffb9094e2c3e88
    EFLAGS: 00010246 [ 141.088009] RAX: 0000000000000000 RBX: ffff9abfdb1f04a0 RCX: 0000000000000000 [
    141.088009] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 [ 141.088009] RBP:
    0000000000000000 R08: ffff9abfffee3cb8 R09: 00000000000002e1 [ 141.088009] R10: ffffb9094cb73d90 R11:
    00000000000f4240 R12: ffff9abfffee8700 [ 141.088009] R13: 0000000000000000 R14: ffff9abfdb1f04a0 R15:
    ffff9abfdb1f04a8 [ 141.088009] FS: 0000000000000000(0000) GS:ffff9abfffec0000(0000) knlGS:0000000000000000
    [ 141.088009] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 141.088009] CR2: ffffffffc09b3a30 CR3:
    0000008fe4c0a001 CR4: 00000000007606e0 [ 141.088009] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
    0000000000000000 [ 141.088009] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [
    141.088009] PKRU: 55555554 [ 141.088009] Call Trace: [ 141.088009] ? process_one_work+0x195/0x390 [
    141.088009] ? worker_thread+0x30/0x390 [ 141.088009] ? process_one_work+0x390/0x390 [ 141.088009] ?
    kthread+0x10d/0x130 [ 141.088009] ? kthread_flush_work_fn+0x10/0x10 [ 141.088009] ?
    ret_from_fork+0x35/0x40] BUG: unable to handle kernel paging request at ffffffffc0b28a5a [ 200.223240] PGD
    97fe00d067 P4D 97fe00d067 PUD 97fe00f067 PMD a580cbf067 PTE 0 [ 200.223464] Oops: 0010 [#1] SMP NOPTI [
    200.223579] CPU: 63 PID: 664 Comm: kworker/63:1 Kdump: loaded Not tainted 4.18.0.x86_64 #46 [ 200.224008]
    Workqueue: events 0xffffffffc0b28a40 [ 200.224008] RIP: 0010:0xffffffffc0b28a5a [ 200.224008] Code: Bad
    RIP value. [ 200.224008] RSP: 0018:ffffbf3c8e2a3e88 EFLAGS: 00010246 [ 200.224008] RAX: 0000000000000000
    RBX: ffffa0799ad6bca0 RCX: 0000000000000000 [ 200.224008] RDX: 0000000000000000 RSI: 0000000000000246 RDI:
    0000000000000246 [ 200.224008] RBP: 0000000000000000 R08: ffff9fe43fde3cb8 R09: 00000000000000d5 [
    200.224008] R10: ffffbf3c8cb53d90 R11: 00000000000f4240 R12: ffff9fe43fde8700 [ 200.224008] R13:
    0000000000000000 R14: ffffa0799ad6bca0 R15: ffffa0799ad6bca8 [ 200.224008] FS: 0000000000000000(0000)
    GS:ffff9fe43fdc0000(0000) knlGS:0000000000000000 [ 200.224008] CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 [ 200.224008] CR2: ffffffffc0b28a30 CR3: 00000097fe00a002 CR4: 00000000007606e0 [
    200.224008] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 200.224008] DR3:
    0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 200.224008] PKRU: 55555554 [ 200.224008]
    Call Trace: [ 200.224008] ? process_one_work+0x195/0x390 [ 200.224008] ? worker_thread+0x30/0x390 [
    200.224008] ? process_one_work+0x390/0x390 [ 200.224008] ? kthread+0x10d/0x130 [ 200.224008] ?
    kthread_flush_work_fn+0x10/0x10 [ 200.224008] ? ret_from_fork+0x35/0x40 [ 200.224008] kernel fault(0x1)
    notification starting on CPU 63 [ 200.224008] kernel fault(0x1) notification finished on CPU 63 [
    200.224008] CR2: ffffffffc0b28a5a [ 200.224008] ---[ end trace c82a412d93f57412 ]--- The reason is as
    follows: T1: rmmod ipmi_si. ->ipmi_unregister_smi() -> ipmi_bmc_unregister() -> __ipmi_bmc_unregister() ->
    kref_put(&bmc->usecount, cleanup_bmc_device); -> schedule_work(&bmc->remove_work); T2: rmmod ipmi_msghandl
    ---truncated--- (CVE-2021-47100)

  - In the Linux kernel, the following vulnerability has been resolved: asix: fix uninit-value in
    asix_mdio_read() asix_read_cmd() may read less than sizeof(smsr) bytes and in this case smsr will be
    uninitialized. Fail log: BUG: KMSAN: uninit-value in asix_check_host_enable
    drivers/net/usb/asix_common.c:82 [inline] BUG: KMSAN: uninit-value in asix_check_host_enable
    drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 BUG: KMSAN: uninit-value in
    asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497
    asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] asix_check_host_enable
    drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497 asix_mdio_read+0x3c1/0xb00
    drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497 (CVE-2021-47101)

  - In the Linux kernel, the following vulnerability has been resolved: IB/qib: Fix memory leak in
    qib_user_sdma_queue_pkts() The wrong goto label was used for the error case and missed cleanup of the pkt
    allocation. Addresses-Coverity-ID: 1493352 (Resource leak) (CVE-2021-47104)

  - In the Linux kernel, the following vulnerability has been resolved: x86/kvm: Disable kvmclock on all CPUs
    on shutdown Currenly, we disable kvmclock from machine_shutdown() hook and this only happens for boot CPU.
    We need to disable it for all CPUs to guard against memory corruption e.g. on restore from hibernate.
    Note, writing '0' to kvmclock MSR doesn't clear memory location, it just prevents hypervisor from updating
    the location so for the short while after write and while CPU is still alive, the clock remains usable and
    correct so we don't need to switch to some other clocksource. (CVE-2021-47110)

  - In the Linux kernel, the following vulnerability has been resolved: x86/kvm: Teardown PV features on boot
    CPU as well Various PV features (Async PF, PV EOI, steal time) work through memory shared with hypervisor
    and when we restore from hibernation we must properly teardown all these features to make sure hypervisor
    doesn't write to stale locations after we jump to the previously hibernated kernel (which can try to place
    anything there). For secondary CPUs the job is already done by kvm_cpu_down_prepare(), register syscore
    ops to do the same for boot CPU. (CVE-2021-47112)

  - In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix data corruption by
    fallocate When fallocate punches holes out of inode size, if original isize is in the middle of last
    cluster, then the part from isize to the end of the cluster will be zeroed with buffer write, at that time
    isize is not yet updated to match the new size, if writeback is kicked in, it will invoke
    ocfs2_writepage()->block_write_full_page() where the pages out of inode size will be dropped. That will
    cause file corruption. Fix this by zero out eof blocks when extending the inode size. Running the
    following command with qemu-image 4.2.1 can get a corrupted coverted image file easily. qemu-img convert
    -p -t none -T none -f qcow2 $qcow_image \ -O qcow2 -o compat=1.1 $qcow_image.conv The usage of fallocate
    in qemu is like this, it first punches holes out of inode size, then extend the inode size. fallocate(11,
    FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0 fallocate(11, 0, 2276196352, 65536) = 0
    v1: https://www.spinics.net/lists/linux-fsdevel/msg193999.html v2: https://lore.kernel.org/linux-
    fsdevel/[email protected]/T/ (CVE-2021-47114)

  - In the Linux kernel, the following vulnerability has been resolved: ext4: fix bug on in
    ext4_es_cache_extent as ext4_split_extent_at failed We got follow bug_on when run fsstress with injecting
    IO fault: [130747.323114] kernel BUG at fs/ext4/extents_status.c:762! [130747.323117] Internal error: Oops
    - BUG: 0 [#1] SMP ...... [130747.334329] Call trace: [130747.334553] ext4_es_cache_extent+0x150/0x168
    [ext4] [130747.334975] ext4_cache_extents+0x64/0xe8 [ext4] [130747.335368] ext4_find_extent+0x300/0x330
    [ext4] [130747.335759] ext4_ext_map_blocks+0x74/0x1178 [ext4] [130747.336179] ext4_map_blocks+0x2f4/0x5f0
    [ext4] [130747.336567] ext4_mpage_readpages+0x4a8/0x7a8 [ext4] [130747.336995] ext4_readpage+0x54/0x100
    [ext4] [130747.337359] generic_file_buffered_read+0x410/0xae8 [130747.337767]
    generic_file_read_iter+0x114/0x190 [130747.338152] ext4_file_read_iter+0x5c/0x140 [ext4] [130747.338556]
    __vfs_read+0x11c/0x188 [130747.338851] vfs_read+0x94/0x150 [130747.339110] ksys_read+0x74/0xf0 This
    patch's modification is according to Jan Kara's suggestion in: https://patchwork.ozlabs.org/project/linux-
    ext4/patch/[email protected]/ I see. Now I understand your patch. Honestly,
    seeing how fragile is trying to fix extent tree after split has failed in the middle, I would probably go
    even further and make sure we fix the tree properly in case of ENOSPC and EDQUOT (those are easily user
    triggerable). Anything else indicates a HW problem or fs corruption so I'd rather leave the extent tree as
    is and don't try to fix it (which also means we will not create overlapping extents). (CVE-2021-47117)

  - In the Linux kernel, the following vulnerability has been resolved: pid: take a reference when
    initializing `cad_pid` During boot, kernel_init_freeable() initializes `cad_pid` to the init task's struct
    pid. Later on, we may change `cad_pid` via a sysctl, and when this happens proc_do_cad_pid() will
    increment the refcount on the new pid via get_pid(), and will decrement the refcount on the old pid via
    put_pid(). As we never called get_pid() when we initialized `cad_pid`, we decrement a reference we never
    incremented, can therefore free the init task's struct pid early. As there can be dangling references to
    the struct pid, we can later encounter a use-after-free (e.g. when delivering signals). This was spotted
    when fuzzing v5.13-rc3 with Syzkaller, but seems to have been around since the conversion of `cad_pid` to
    struct pid in commit 9ec52099e4b8 ([PATCH] replace cad_pid by a struct pid) from the pre-KASAN stone age
    of v2.6.19. Fix this by getting a reference to the init task's struct pid when we assign it to `cad_pid`.
    Full KASAN splat below. ================================================================== BUG: KASAN:
    use-after-free in ns_of_pid include/linux/pid.h:153 [inline] BUG: KASAN: use-after-free in
    task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 Read of size 4 at addr ffff23794dda0004 by task syz-
    executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 Not tainted 5.12.0-00001-g9aef892b2d15 #1 Hardware
    name: linux,dummy-virt (DT) Call trace: ns_of_pid include/linux/pid.h:153 [inline]
    task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c:1950
    exit_notify kernel/exit.c:682 [inline] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8
    kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882
    [inline] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Allocated by
    task 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h:516 slab_alloc_node mm/slub.c:2907 [inline] slab_alloc
    mm/slub.c:2915 [inline] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180
    copy_process+0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500
    kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687
    arch_call_rest_init+0x1c/0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Freed by task 270:
    slab_free_hook mm/slub.c:1562 [inline] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free
    mm/slub.c:3161 [inline] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8
    kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/sysctl.c:1401
    proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48
    fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [inline] new_sync_write+0x3ac/0x510
    fs/read_write.c:518 vfs_write fs/read_write.c:605 [inline] vfs_write+0x9c4/0x1018 fs/read_write.c:585
    ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c:670 [inline] __se_sys_write
    fs/read_write.c:667 [inline] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall
    arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall arch/arm64/kernel/syscall.c:49 [inline]
    el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150
    arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/arm64/kernel/entry-common.c:416
    el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180
    arch/arm64/kernel/entry.S:701 The buggy address belongs to the object at ffff23794dda0000 which belongs to
    the cache pid of size 224 The buggy address is located 4 bytes inside of 224-byte region [ff
    ---truncated--- (CVE-2021-47118)

  - In the Linux kernel, the following vulnerability has been resolved: ext4: fix memory leak in
    ext4_fill_super Buffer head references must be released before calling kill_bdev(); otherwise the buffer
    head (and its page referenced by b_data) will not be freed by kill_bdev, and subsequently that bh will be
    leaked. If blocksizes differ, sb_set_blocksize() will kill current buffers and page cache by using
    kill_bdev(). And then super block will be reread again but using correct blocksize this time.
    sb_set_blocksize() didn't fully free superblock page and buffer head, and being busy, they were not freed
    and instead leaked. This can easily be reproduced by calling an infinite loop of: systemctl start
    <ext4_on_lvm>.mount, and systemctl stop <ext4_on_lvm>.mount ... since systemd creates a cgroup for each
    slice which it mounts, and the bh leak get amplified by a dying memory cgroup that also never gets freed,
    and memory consumption is much more easily noticed. (CVE-2021-47119)

  - In the Linux kernel, the following vulnerability has been resolved: cxgb4: avoid accessing registers when
    clearing filters Hardware register having the server TID base can contain invalid values when adapter is
    in bad state (for example, due to AER fatal error). Reading these invalid values in the register can lead
    to out-of-bound memory access. So, fix by using the saved server TID base when clearing filters.
    (CVE-2021-47138)

  - In the Linux kernel, the following vulnerability has been resolved: gve: Add NULL pointer checks when
    freeing irqs. When freeing notification blocks, we index priv->msix_vectors. If we failed to allocate
    priv->msix_vectors (see abort_with_msix_vectors) this could lead to a NULL pointer dereference if the
    driver is unloaded. (CVE-2021-47141)

  - In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: Fix a use-after-free looks
    like we forget to set ttm->sg to NULL. Hit panic below [ 1235.844104] general protection fault, probably
    for non-canonical address 0x6b6b6b6b6b6b7b4b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [ 1235.989074] Call
    Trace: [ 1235.991751] sg_free_table+0x17/0x20 [ 1235.995667] amdgpu_ttm_backend_unbind.cold+0x4d/0xf7
    [amdgpu] [ 1236.002288] amdgpu_ttm_backend_destroy+0x29/0x130 [amdgpu] [ 1236.008464]
    ttm_tt_destroy+0x1e/0x30 [ttm] [ 1236.013066] ttm_bo_cleanup_memtype_use+0x51/0xa0 [ttm] [ 1236.018783]
    ttm_bo_release+0x262/0xa50 [ttm] [ 1236.023547] ttm_bo_put+0x82/0xd0 [ttm] [ 1236.027766]
    amdgpu_bo_unref+0x26/0x50 [amdgpu] [ 1236.032809] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x7aa/0xd90
    [amdgpu] [ 1236.040400] kfd_ioctl_alloc_memory_of_gpu+0xe2/0x330 [amdgpu] [ 1236.046912]
    kfd_ioctl+0x463/0x690 [amdgpu] (CVE-2021-47142)

  - In the Linux kernel, the following vulnerability has been resolved: net/smc: remove device from
    smcd_dev_list after failed device_add() If the device_add() for a smcd_dev fails, there's no cleanup step
    that rolls back the earlier list_add(). The device subsequently gets freed, and we end up with a corrupted
    list. Add some error handling that removes the device from the list. (CVE-2021-47143)

  - In the Linux kernel, the following vulnerability has been resolved: mld: fix panic in mld_newpack()
    mld_newpack() doesn't allow to allocate high order page, only order-0 allocation is allowed. If headroom
    size is too large, a kernel panic could occur in skb_put(). Test commands: ip netns del A ip netns del B
    ip netns add A ip netns add B ip link add veth0 type veth peer name veth1 ip link set veth0 netns A ip
    link set veth1 netns B ip netns exec A ip link set lo up ip netns exec A ip link set veth0 up ip netns
    exec A ip -6 a a 2001:db8:0::1/64 dev veth0 ip netns exec B ip link set lo up ip netns exec B ip link set
    veth1 up ip netns exec B ip -6 a a 2001:db8:0::2/64 dev veth1 for i in {1..99} do let A=$i-1 ip netns exec
    A ip link add ip6gre$i type ip6gre \ local 2001:db8:$A::1 remote 2001:db8:$A::2 encaplimit 100 ip netns
    exec A ip -6 a a 2001:db8:$i::1/64 dev ip6gre$i ip netns exec A ip link set ip6gre$i up ip netns exec B ip
    link add ip6gre$i type ip6gre \ local 2001:db8:$A::2 remote 2001:db8:$A::1 encaplimit 100 ip netns exec B
    ip -6 a a 2001:db8:$i::2/64 dev ip6gre$i ip netns exec B ip link set ip6gre$i up done Splat looks like:
    kernel BUG at net/core/skbuff.c:110! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI CPU: 0 PID: 7
    Comm: kworker/0:1 Not tainted 5.12.0+ #891 Workqueue: ipv6_addrconf addrconf_dad_work RIP:
    0010:skb_panic+0x15d/0x15f Code: 92 fe 4c 8b 4c 24 10 53 8b 4d 70 45 89 e0 48 c7 c7 00 ae 79 83 41 57 41
    56 41 55 48 8b 54 24 a6 26 f9 ff <0f> 0b 48 8b 6c 24 20 89 34 24 e8 4a 4e 92 fe 8b 34 24 48 c7 c1 20 RSP:
    0018:ffff88810091f820 EFLAGS: 00010282 RAX: 0000000000000089 RBX: ffff8881086e9000 RCX: 0000000000000000
    RDX: 0000000000000089 RSI: 0000000000000008 RDI: ffffed1020123efb RBP: ffff888005f6eac0 R08:
    ffffed1022fc0031 R09: ffffed1022fc0031 R10: ffff888117e00187 R11: ffffed1022fc0030 R12: 0000000000000028
    R13: ffff888008284eb0 R14: 0000000000000ed8 R15: 0000000000000ec0 FS: 0000000000000000(0000)
    GS:ffff888117c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    00007f8b801c5640 CR3: 0000000033c2c006 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000
    DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ?
    ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 ? ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600
    skb_put.cold.104+0x22/0x22 ip6_mc_hdr.isra.26.constprop.46+0x12a/0x600 ?
    rcu_read_lock_sched_held+0x91/0xc0 mld_newpack+0x398/0x8f0 ? ip6_mc_hdr.isra.26.constprop.46+0x600/0x600 ?
    lock_contended+0xc40/0xc40 add_grhead.isra.33+0x280/0x380 add_grec+0x5ca/0xff0 ? mld_sendpack+0xf40/0xf40
    ? lock_downgrade+0x690/0x690 mld_send_initial_cr.part.34+0xb9/0x180 ipv6_mc_dad_complete+0x15d/0x1b0
    addrconf_dad_completed+0x8d2/0xbb0 ? lock_downgrade+0x690/0x690 ? addrconf_rs_timer+0x660/0x660 ?
    addrconf_dad_work+0x73c/0x10e0 addrconf_dad_work+0x73c/0x10e0 Allowing high order page allocation could
    fix this problem. (CVE-2021-47146)

  - In the Linux kernel, the following vulnerability has been resolved: net: fujitsu: fix potential null-ptr-
    deref In fmvj18x_get_hwinfo(), if ioremap fails there will be NULL pointer deref. To fix this, check the
    return value of ioremap and return -1 to the caller in case of failure. (CVE-2021-47149)

  - In the Linux kernel, the following vulnerability has been resolved: net: fec: fix the potential memory
    leak in fec_enet_init() If the memory allocated for cbd_base is failed, it should free the memory
    allocated for the queues, otherwise it causes memory leak. And if the memory allocated for the queues is
    failed, it can return error directly. (CVE-2021-47150)

  - In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Don't generate an interrupt
    on bus reset Now that the i2c-i801 driver supports interrupts, setting the KILL bit in a attempt to
    recover from a timed out transaction triggers an interrupt. Unfortunately, the interrupt handler
    (i801_isr) is not prepared for this situation and will try to process the interrupt as if it was signaling
    the end of a successful transaction. In the case of a block transaction, this can result in an out-of-
    range memory access. This condition was reproduced several times by syzbot:
    https://syzkaller.appspot.com/bug?extid=ed71512d469895b5b34e
    https://syzkaller.appspot.com/bug?extid=8c8dedc0ba9e03f6c79e
    https://syzkaller.appspot.com/bug?extid=c8ff0b6d6c73d81b610e
    https://syzkaller.appspot.com/bug?extid=33f6c360821c399d69eb
    https://syzkaller.appspot.com/bug?extid=be15dc0b1933f04b043a
    https://syzkaller.appspot.com/bug?extid=b4d3fd1dfd53e90afd79 So disable interrupts while trying to reset
    the bus. Interrupts will be enabled again for the following transaction. (CVE-2021-47153)

  - In the Linux kernel, the following vulnerability has been resolved: net: dsa: fix a crash if
    ->get_sset_count() fails If ds->ops->get_sset_count() fails then it count is a negative error code such
    as -EOPNOTSUPP. Because i is an unsigned int, the negative error code is type promoted to a very high
    value and the loop will corrupt memory until the system crashes. Fix this by checking for error codes and
    changing the type of i to just int. (CVE-2021-47159)

  - In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix a resource leak
    in an error handling path 'dspi_request_dma()' should be undone by a 'dspi_release_dma()' call in the
    error handling path of the probe function, as already done in the remove function (CVE-2021-47161)

  - In the Linux kernel, the following vulnerability has been resolved: tipc: skb_linearize the head skb when
    reassembling msgs It's not a good idea to append the frag skb to a skb's frag_list if the frag_list
    already has skbs from elsewhere, such as this skb was created by pskb_copy() where the frag_list was
    cloned (all the skbs in it were skb_get'ed) and shared by multiple skbs. However, the new appended frag
    skb should have been only seen by the current skb. Otherwise, it will cause use after free crashes as this
    appended frag skb are seen by multiple skbs but it only got skb_get called once. The same thing happens
    with a skb updated by pskb_may_pull() with a skb_cloned skb. Li Shuang has reported quite a few crashes
    caused by this when doing testing over macvlan devices: [] kernel BUG at net/core/skbuff.c:1970! [] Call
    Trace: [] skb_clone+0x4d/0xb0 [] macvlan_broadcast+0xd8/0x160 [macvlan] []
    macvlan_process_broadcast+0x148/0x150 [macvlan] [] process_one_work+0x1a7/0x360 []
    worker_thread+0x30/0x390 [] kernel BUG at mm/usercopy.c:102! [] Call Trace: []
    __check_heap_object+0xd3/0x100 [] __check_object_size+0xff/0x16b [] simple_copy_to_iter+0x1c/0x30 []
    __skb_datagram_iter+0x7d/0x310 [] __skb_datagram_iter+0x2a5/0x310 [] skb_copy_datagram_iter+0x3b/0x90 []
    tipc_recvmsg+0x14a/0x3a0 [tipc] [] ____sys_recvmsg+0x91/0x150 [] ___sys_recvmsg+0x7b/0xc0 [] kernel BUG at
    mm/slub.c:305! [] Call Trace: [] <IRQ> [] kmem_cache_free+0x3ff/0x400 []
    __netif_receive_skb_core+0x12c/0xc40 [] ? kmem_cache_alloc+0x12e/0x270 []
    netif_receive_skb_internal+0x3d/0xb0 [] ? get_rx_page_info+0x8e/0xa0 [be2net] [] be_poll+0x6ef/0xd00
    [be2net] [] ? irq_exit+0x4f/0x100 [] net_rx_action+0x149/0x3b0 ... This patch is to fix it by linearizing
    the head skb if it has frag_list set in tipc_buf_append(). Note that we choose to do this before calling
    skb_unshare(), as __skb_linearize() will avoid skb_copy(). Also, we can not just drop the frag_list either
    as the early time. (CVE-2021-47162)

  - In the Linux kernel, the following vulnerability has been resolved: drm/meson: fix shutdown crash when
    component not probed When main component is not probed, by example when the dw-hdmi module is not loaded
    yet or in probe defer, the following crash appears on shutdown: Unable to handle kernel NULL pointer
    dereference at virtual address 0000000000000038 ... pc : meson_drv_shutdown+0x24/0x50 lr :
    platform_drv_shutdown+0x20/0x30 ... Call trace: meson_drv_shutdown+0x24/0x50
    platform_drv_shutdown+0x20/0x30 device_shutdown+0x158/0x360 kernel_restart_prepare+0x38/0x48
    kernel_restart+0x18/0x68 __do_sys_reboot+0x224/0x250 __arm64_sys_reboot+0x24/0x30 ... Simply check if the
    priv struct has been allocated before using it. (CVE-2021-47165)

  - In the Linux kernel, the following vulnerability has been resolved: NFS: Don't corrupt the value of
    pg_bytes_written in nfs_do_recoalesce() The value of mirror->pg_bytes_written should only be updated after
    a successful attempt to flush out the requests on the list. (CVE-2021-47166)

  - In the Linux kernel, the following vulnerability has been resolved: NFS: Fix an Oopsable condition in
    __nfs_pageio_add_request() Ensure that nfs_pageio_error_cleanup() resets the mirror array contents, so
    that the structure reflects the fact that it is now empty. Also change the test in
    nfs_pageio_do_add_request() to be more robust by checking whether or not the list is empty rather than
    relying on the value of pg_count. (CVE-2021-47167)

  - In the Linux kernel, the following vulnerability has been resolved: NFS: fix an incorrect limit in
    filelayout_decode_layout() The sizeof(struct nfs_fh) is two bytes too large and could lead to memory
    corruption. It should be NFS_MAXFHSIZE because that's the size of the ->data[] buffer. I reversed the size
    of the arguments to put the variable on the left. (CVE-2021-47168)

  - In the Linux kernel, the following vulnerability has been resolved: serial: rp2: use 'request_firmware'
    instead of 'request_firmware_nowait' In 'rp2_probe', the driver registers 'rp2_uart_interrupt' then calls
    'rp2_fw_cb' through 'request_firmware_nowait'. In 'rp2_fw_cb', if the firmware don't exists, function just
    return without initializing ports of 'rp2_card'. But now the interrupt handler function has been
    registered, and when an interrupt comes, 'rp2_uart_interrupt' may access those ports then causing NULL
    pointer dereference or other bugs. Because the driver does some initialization work in 'rp2_fw_cb', in
    order to make the driver ready to handle interrupts, 'request_firmware' should be used instead of
    asynchronous 'request_firmware_nowait'. This report reveals it: INFO: trying to register non-static key.
    the code is fine but needs lockdep annotation. turning off the locking correctness validator. CPU: 2 PID:
    0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45 Hardware name: QEMU Standard PC (Q35 +
    ICH9, 2009), BIOS rel-1.12.0-59- gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> __dump_stack
    lib/dump_stack.c:77 [inline] dump_stack+0xec/0x156 lib/dump_stack.c:118 assign_lock_key
    kernel/locking/lockdep.c:727 [inline] register_lock_class+0x14e5/0x1ba0 kernel/locking/lockdep.c:753
    __lock_acquire+0x187/0x3750 kernel/locking/lockdep.c:3303 lock_acquire+0x124/0x340
    kernel/locking/lockdep.c:3907 __raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
    _raw_spin_lock+0x32/0x50 kernel/locking/spinlock.c:144 spin_lock include/linux/spinlock.h:329 [inline]
    rp2_ch_interrupt drivers/tty/serial/rp2.c:466 [inline] rp2_asic_interrupt.isra.9+0x15d/0x990
    drivers/tty/serial/rp2.c:493 rp2_uart_interrupt+0x49/0xe0 drivers/tty/serial/rp2.c:504
    __handle_irq_event_percpu+0xfb/0x770 kernel/irq/handle.c:149 handle_irq_event_percpu+0x79/0x150
    kernel/irq/handle.c:189 handle_irq_event+0xac/0x140 kernel/irq/handle.c:206 handle_fasteoi_irq+0x232/0x5c0
    kernel/irq/chip.c:725 generic_handle_irq_desc include/linux/irqdesc.h:155 [inline] handle_irq+0x230/0x3a0
    arch/x86/kernel/irq_64.c:87 do_IRQ+0xa7/0x1e0 arch/x86/kernel/irq.c:247 common_interrupt+0xf/0xf
    arch/x86/entry/entry_64.S:670 </IRQ> RIP: 0010:native_safe_halt+0x28/0x30
    arch/x86/include/asm/irqflags.h:61 Code: 00 00 55 be 04 00 00 00 48 c7 c7 00 c2 2f 8c 48 89 e5 e8 fb 31 e7
    f8 8b 05 75 af 8d 03 85 c0 7e 07 0f 00 2d 8a 61 65 00 fb f4 <5d> c3 90 90 90 90 90 90 0f 1f 44 00 00 55 48
    89 e5 41 57 41 56 41 RSP: 0018:ffff88806b71fcc8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde RAX:
    0000000000000000 RBX: ffffffff8bde7e48 RCX: ffffffff88a21285 RDX: 0000000000000000 RSI: 0000000000000004
    RDI: ffffffff8c2fc200 RBP: ffff88806b71fcc8 R08: fffffbfff185f840 R09: fffffbfff185f840 R10:
    0000000000000001 R11: fffffbfff185f840 R12: 0000000000000002 R13: ffffffff8bea18a0 R14: 0000000000000000
    R15: 0000000000000000 arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline] default_idle+0x6f/0x360
    arch/x86/kernel/process.c:557 arch_cpu_idle+0xf/0x20 arch/x86/kernel/process.c:548
    default_idle_call+0x3b/0x60 kernel/sched/idle.c:93 cpuidle_idle_call kernel/sched/idle.c:153 [inline]
    do_idle+0x2ab/0x3c0 kernel/sched/idle.c:263 cpu_startup_entry+0xcb/0xe0 kernel/sched/idle.c:369
    start_secondary+0x3b8/0x4e0 arch/x86/kernel/smpboot.c:271 secondary_startup_64+0xa4/0xb0
    arch/x86/kernel/head_64.S:243 BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
    PGD 8000000056d27067 P4D 8000000056d27067 PUD 56d28067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 2
    PID: 0 Comm: swapper/2 Not tainted 4.19.177-gdba4159c14ef-dirty #45 Hardware name: QEMU Standard PC (Q35 +
    ICH9, 2009), BIOS rel-1.12.0-59- gc9ba5276e321-prebuilt.qemu.org 04/01/2014 RIP: 0010:readl
    arch/x86/include/asm/io.h:59 [inline] RIP: 0010:rp2_ch_interrupt drivers/tty/serial/rp2.c:472 [inline]
    RIP: 0010:rp2_asic_interrupt.isra.9+0x181/0x990 drivers/tty/serial/rp2.c: 493 Co ---truncated---
    (CVE-2021-47169)

  - In the Linux kernel, the following vulnerability has been resolved: net: usb: fix memory leak in
    smsc75xx_bind Syzbot reported memory leak in smsc75xx_bind(). The problem was is non-freed memory in case
    of errors after memory allocation. backtrace: [<ffffffff84245b62>] kmalloc include/linux/slab.h:556
    [inline] [<ffffffff84245b62>] kzalloc include/linux/slab.h:686 [inline] [<ffffffff84245b62>]
    smsc75xx_bind+0x7a/0x334 drivers/net/usb/smsc75xx.c:1460 [<ffffffff82b5b2e6>] usbnet_probe+0x3b6/0xc30
    drivers/net/usb/usbnet.c:1728 (CVE-2021-47171)

  - In the Linux kernel, the following vulnerability has been resolved: misc/uss720: fix memory leak in
    uss720_probe uss720_probe forgets to decrease the refcount of usbdev in uss720_probe. Fix this by
    decreasing the refcount of usbdev by usb_put_dev. BUG: memory leak unreferenced object 0xffff888101113800
    (size 2048): comm kworker/0:1, pid 7, jiffies 4294956777 (age 28.870s) hex dump (first 32 bytes): ff ff
    ff ff 31 00 00 00 00 00 00 00 00 00 00 00 ....1........... 00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00
    ................ backtrace: [<ffffffff82b8e822>] kmalloc include/linux/slab.h:554 [inline]
    [<ffffffff82b8e822>] kzalloc include/linux/slab.h:684 [inline] [<ffffffff82b8e822>]
    usb_alloc_dev+0x32/0x450 drivers/usb/core/usb.c:582 [<ffffffff82b98441>] hub_port_connect
    drivers/usb/core/hub.c:5129 [inline] [<ffffffff82b98441>] hub_port_connect_change
    drivers/usb/core/hub.c:5363 [inline] [<ffffffff82b98441>] port_event drivers/usb/core/hub.c:5509 [inline]
    [<ffffffff82b98441>] hub_event+0x1171/0x20c0 drivers/usb/core/hub.c:5591 [<ffffffff81259229>]
    process_one_work+0x2c9/0x600 kernel/workqueue.c:2275 [<ffffffff81259b19>] worker_thread+0x59/0x5d0
    kernel/workqueue.c:2421 [<ffffffff81261228>] kthread+0x178/0x1b0 kernel/kthread.c:292 [<ffffffff8100227f>]
    ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 (CVE-2021-47173)

  - In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix sysfs leak in
    alloc_iommu() iommu_device_sysfs_add() is called before, so is has to be cleaned on subsequent errors.
    (CVE-2021-47177)

  - In the Linux kernel, the following vulnerability has been resolved: NFSv4: Fix a NULL pointer dereference
    in pnfs_mark_matching_lsegs_return() Commit de144ff4234f changes _pnfs_return_layout() to call
    pnfs_mark_matching_lsegs_return() passing NULL as the struct pnfs_layout_range argument. Unfortunately,
    pnfs_mark_matching_lsegs_return() doesn't check if we have a value here before dereferencing it, causing
    an oops. I'm able to hit this crash consistently when running connectathon basic tests on NFS v4.1/v4.2
    against Ontap. (CVE-2021-47179)

  - In the Linux kernel, the following vulnerability has been resolved: NFC: nci: fix memory leak in
    nci_allocate_device nfcmrvl_disconnect fails to free the hci_dev field in struct nci_dev. Fix this by
    freeing hci_dev in nci_free_device. BUG: memory leak unreferenced object 0xffff888111ea6800 (size 1024):
    comm kworker/1:0, pid 19, jiffies 4294942308 (age 13.580s) hex dump (first 32 bytes): 00 00 00 00 00 00
    00 00 00 60 fd 0c 81 88 ff ff .........`...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    ................ backtrace: [<000000004bc25d43>] kmalloc include/linux/slab.h:552 [inline]
    [<000000004bc25d43>] kzalloc include/linux/slab.h:682 [inline] [<000000004bc25d43>]
    nci_hci_allocate+0x21/0xd0 net/nfc/nci/hci.c:784 [<00000000c59cff92>] nci_allocate_device
    net/nfc/nci/core.c:1170 [inline] [<00000000c59cff92>] nci_allocate_device+0x10b/0x160
    net/nfc/nci/core.c:1132 [<00000000006e0a8e>] nfcmrvl_nci_register_dev+0x10a/0x1c0
    drivers/nfc/nfcmrvl/main.c:153 [<000000004da1b57e>] nfcmrvl_probe+0x223/0x290
    drivers/nfc/nfcmrvl/usb.c:345 [<00000000d506aed9>] usb_probe_interface+0x177/0x370
    drivers/usb/core/driver.c:396 [<00000000bc632c92>] really_probe+0x159/0x4a0 drivers/base/dd.c:554
    [<00000000f5009125>] driver_probe_device+0x84/0x100 drivers/base/dd.c:740 [<000000000ce658ca>]
    __device_attach_driver+0xee/0x110 drivers/base/dd.c:846 [<000000007067d05f>] bus_for_each_drv+0xb7/0x100
    drivers/base/bus.c:431 [<00000000f8e13372>] __device_attach+0x122/0x250 drivers/base/dd.c:914
    [<000000009cf68860>] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:491 [<00000000359c965a>]
    device_add+0x5be/0xc30 drivers/base/core.c:3109 [<00000000086e4bd3>] usb_set_configuration+0x9d9/0xb90
    drivers/usb/core/message.c:2164 [<00000000ca036872>] usb_generic_driver_probe+0x8c/0xc0
    drivers/usb/core/generic.c:238 [<00000000d40d36f6>] usb_probe_device+0x5c/0x140
    drivers/usb/core/driver.c:293 [<00000000bc632c92>] really_probe+0x159/0x4a0 drivers/base/dd.c:554
    (CVE-2021-47180)

  - In the Linux kernel, the following vulnerability has been resolved: usb: musb: tusb6010: check return
    value after calling platform_get_resource() It will cause null-ptr-deref if platform_get_resource()
    returns NULL, we need check the return value. (CVE-2021-47181)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: core: Fix scsi_mode_sense()
    buffer length handling Several problems exist with scsi_mode_sense() buffer length handling: 1) The
    allocation length field of the MODE SENSE(10) command is 16-bits, occupying bytes 7 and 8 of the CDB. With
    this command, access to mode pages larger than 255 bytes is thus possible. However, the CDB allocation
    length field is set by assigning len to byte 8 only, thus truncating buffer length larger than 255. 2) If
    scsi_mode_sense() is called with len smaller than 8 with sdev->use_10_for_ms set, or smaller than 4
    otherwise, the buffer length is increased to 8 and 4 respectively, and the buffer is zero filled with
    these increased values, thus corrupting the memory following the buffer. Fix these 2 problems by using
    put_unaligned_be16() to set the allocation length field of MODE SENSE(10) CDB and by returning an error
    when len is too small. Furthermore, if len is larger than 255B, always try MODE SENSE(10) first, even if
    the device driver did not set sdev->use_10_for_ms. In case of invalid opcode error for MODE SENSE(10),
    access to mode pages larger than 255 bytes are not retried using MODE SENSE(6). To avoid buffer length
    overflows for the MODE_SENSE(10) case, check that len is smaller than 65535 bytes. While at it, also fix
    the folowing: * Use get_unaligned_be16() to retrieve the mode data length and block descriptor length
    fields of the mode sense reply header instead of using an open coded calculation. * Fix the kdoc dbd
    argument explanation: the DBD bit stands for Disable Block Descriptor, which is the opposite of what the
    dbd argument description was. (CVE-2021-47182)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix link down processing
    to address NULL pointer dereference If an FC link down transition while PLOGIs are outstanding to fabric
    well known addresses, outstanding ABTS requests may result in a NULL pointer dereference. Driver unload
    requests may hang with repeated 2878 log messages. The Link down processing results in ABTS requests for
    outstanding ELS requests. The Abort WQEs are sent for the ELSs before the driver had set the link state to
    down. Thus the driver is sending the Abort with the expectation that an ABTS will be sent on the wire. The
    Abort request is stalled waiting for the link to come up. In some conditions the driver may auto-complete
    the ELSs thus if the link does come up, the Abort completions may reference an invalid structure. Fix by
    ensuring that Abort set the flag to avoid link traffic if issued due to conditions where the link failed.
    (CVE-2021-47183)

  - In the Linux kernel, the following vulnerability has been resolved: i40e: Fix NULL ptr dereference on VSI
    filter sync Remove the reason of null pointer dereference in sync VSI filters. Added new
    I40E_VSI_RELEASING flag to signalize deleting and releasing of VSI resources to sync this thread with sync
    filters subtask. Without this patch it is possible to start update the VSI filter list after VSI is
    removed, that's causing a kernel oops. (CVE-2021-47184)

  - In the Linux kernel, the following vulnerability has been resolved: tty: tty_buffer: Fix the softlockup
    issue in flush_to_ldisc When running ltp testcase(ltp/testcases/kernel/pty/pty04.c) with arm64, there is a
    soft lockup, which look like this one: Workqueue: events_unbound flush_to_ldisc Call trace:
    dump_backtrace+0x0/0x1ec show_stack+0x24/0x30 dump_stack+0xd0/0x128 panic+0x15c/0x374
    watchdog_timer_fn+0x2b8/0x304 __run_hrtimer+0x88/0x2c0 __hrtimer_run_queues+0xa4/0x120
    hrtimer_interrupt+0xfc/0x270 arch_timer_handler_phys+0x40/0x50 handle_percpu_devid_irq+0x94/0x220
    __handle_domain_irq+0x88/0xf0 gic_handle_irq+0x84/0xfc el1_irq+0xc8/0x180 slip_unesc+0x80/0x214 [slip]
    tty_ldisc_receive_buf+0x64/0x80 tty_port_default_receive_buf+0x50/0x90 flush_to_ldisc+0xbc/0x110
    process_one_work+0x1d4/0x4b0 worker_thread+0x180/0x430 kthread+0x11c/0x120 In the testcase pty04, The
    first process call the write syscall to send data to the pty master. At the same time, the workqueue will
    do the flush_to_ldisc to pop data in a loop until there is no more data left. When the sender and
    workqueue running in different core, the sender sends data fastly in full time which will result in
    workqueue doing work in loop for a long time and occuring softlockup in flush_to_ldisc with kernel
    configured without preempt. So I add need_resched check and cond_resched in the flush_to_ldisc loop to
    avoid it. (CVE-2021-47185)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Improve SCSI abort
    handling The following has been observed on a test setup: WARNING: CPU: 4 PID: 250 at
    drivers/scsi/ufs/ufshcd.c:2737 ufshcd_queuecommand+0x468/0x65c Call trace: ufshcd_queuecommand+0x468/0x65c
    scsi_send_eh_cmnd+0x224/0x6a0 scsi_eh_test_devices+0x248/0x418 scsi_eh_ready_devs+0xc34/0xe58
    scsi_error_handler+0x204/0x80c kthread+0x150/0x1b4 ret_from_fork+0x10/0x30 That warning is triggered by
    the following statement: WARN_ON(lrbp->cmd); Fix this warning by clearing lrbp->cmd from the abort
    handler. (CVE-2021-47188)

  - In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory ordering between
    normal and ordered work functions Ordered work functions aren't guaranteed to be handled by the same
    thread which executed the normal work functions. The only way execution between normal/ordered functions
    is synchronized is via the WORK_DONE_BIT, unfortunately the used bitops don't guarantee any ordering
    whatsoever. This manifested as seemingly inexplicable crashes on ARM64, where async_chunk::inode is seen
    as non-null in async_cow_submit which causes submit_compressed_extents to be called and crash occurs
    because async_chunk::inode suddenly became NULL. The call trace was similar to: pc :
    submit_compressed_extents+0x38/0x3d0 lr : async_cow_submit+0x50/0xd0 sp : ffff800015d4bc20 <registers
    omitted for brevity> Call trace: submit_compressed_extents+0x38/0x3d0 async_cow_submit+0x50/0xd0
    run_ordered_work+0xc8/0x280 btrfs_work_helper+0x98/0x250 process_one_work+0x1f0/0x4ac
    worker_thread+0x188/0x504 kthread+0x110/0x114 ret_from_fork+0x10/0x18 Fix this by adding respective
    barrier calls which ensure that all accesses preceding setting of WORK_DONE_BIT are strictly ordered
    before setting the flag. At the same time add a read barrier after reading of WORK_DONE_BIT in
    run_ordered_work which ensures all subsequent loads would be strictly ordered after reading the bit. This
    in turn ensures are all accesses before WORK_DONE_BIT are going to be strictly ordered before any access
    that can occur in ordered_func. (CVE-2021-47189)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix use-after-free in
    lpfc_unreg_rpi() routine An error is detected with the following report when unloading the driver: KASAN:
    use-after-free in lpfc_unreg_rpi+0x1b1b The NLP_REG_LOGIN_SEND nlp_flag is set in
    lpfc_reg_fab_ctrl_node(), but the flag is not cleared upon completion of the login. This allows a second
    call to lpfc_unreg_rpi() to proceed with nlp_rpi set to LPFC_RPI_ALLOW_ERROR. This results in a use after
    free access when used as an rpi_ids array index. Fix by clearing the NLP_REG_LOGIN_SEND nlp_flag in
    lpfc_mbx_cmpl_fc_reg_login(). (CVE-2021-47198)

  - In the Linux kernel, the following vulnerability has been resolved: thermal: Fix NULL pointer dereferences
    in of_thermal_ functions of_parse_thermal_zones() parses the thermal-zones node and registers a
    thermal_zone device for each subnode. However, if a thermal zone is consuming a thermal sensor and that
    thermal sensor device hasn't probed yet, an attempt to set trip_point_*_temp for that thermal zone device
    can cause a NULL pointer dereference. Fix it. console:/sys/class/thermal/thermal_zone87 # echo 120000 >
    trip_point_0_temp ... Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020
    ... Call trace: of_thermal_set_trip_temp+0x40/0xc4 trip_point_temp_store+0xc0/0x1dc
    dev_attr_store+0x38/0x88 sysfs_kf_write+0x64/0xc0 kernfs_fop_write_iter+0x108/0x1d0 vfs_write+0x2f4/0x368
    ksys_write+0x7c/0xec __arm64_sys_write+0x20/0x30 el0_svc_common.llvm.7279915941325364641+0xbc/0x1bc
    do_el0_svc+0x28/0xa0 el0_svc+0x14/0x24 el0_sync_handler+0x88/0xec el0_sync+0x1c0/0x200 While at it, fix
    the possible NULL pointer dereference in other functions as well: of_thermal_get_temp(),
    of_thermal_set_emul_temp(), of_thermal_get_trend(). (CVE-2021-47202)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix list_add() corruption
    in lpfc_drain_txq() When parsing the txq list in lpfc_drain_txq(), the driver attempts to pass the
    requests to the adapter. If such an attempt fails, a local fail_msg string is set and a log message
    output. The job is then added to a completions list for cancellation. Processing of any further jobs from
    the txq list continues, but since fail_msg remains set, jobs are added to the completions list
    regardless of whether a wqe was passed to the adapter. If successfully added to txcmplq, jobs are added to
    both lists resulting in list corruption. Fix by clearing the fail_msg string after adding a job to the
    completions list. This stops the subsequent jobs from being added to the completions list unless they had
    an appropriate failure. (CVE-2021-47203)

  - In the Linux kernel, the following vulnerability has been resolved: net: dpaa2-eth: fix use-after-free in
    dpaa2_eth_remove Access to netdev after free_netdev() will cause use-after-free bug. Move debug log before
    free_netdev() call to avoid it. (CVE-2021-47204)

  - In the Linux kernel, the following vulnerability has been resolved: clk: sunxi-ng: Unregister
    clocks/resets when unbinding Currently, unbinding a CCU driver unmaps the device's MMIO region, while
    leaving its clocks/resets and their providers registered. This can cause a page fault later when some
    clock operation tries to perform MMIO. Fix this by separating the CCU initialization from the memory
    allocation, and then using a devres callback to unregister the clocks and resets. This also fixes a memory
    leak of the `struct ccu_reset`, and uses the correct owner (the specific platform driver) for the clocks
    and resets. Early OF clock providers are never unregistered, and limited error handling is possible, so
    they are mostly unchanged. The error reporting is made more consistent by moving the message inside
    of_sunxi_ccu_probe. (CVE-2021-47205)

  - In the Linux kernel, the following vulnerability has been resolved: ALSA: gus: fix null pointer
    dereference on pointer block The pointer block return from snd_gf1_dma_next_block could be null, so there
    is a potential null pointer dereference issue. Fix this by adding a null check before dereference.
    (CVE-2021-47207)

  - In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: fix null pointer
    dereference on pointer cs_desc The pointer cs_desc return from snd_usb_find_clock_source could be null, so
    there is a potential null pointer dereference issue. Fix this by adding a null check before dereference.
    (CVE-2021-47211)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: advansys: Fix kernel pointer
    leak Pointers should be printed with %p or %px rather than cast to 'unsigned long' and printed with %lx.
    Change %lx to %p to print the hashed pointer. (CVE-2021-47216)

  - In the Linux kernel, the following vulnerability has been resolved: x86/hyperv: Fix NULL deref in
    set_hv_tscchange_cb() if Hyper-V setup fails Check for a valid hv_vp_index array prior to derefencing
    hv_vp_index when setting Hyper-V's TSC change callback. If Hyper-V setup failed in hyperv_init(), the
    kernel will still report that it's running under Hyper-V, but will have silently disabled nearly all
    functionality. BUG: kernel NULL pointer dereference, address: 0000000000000010 #PF: supervisor read access
    in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 4 PID: 1
    Comm: swapper/0 Not tainted 5.15.0-rc2+ #75 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0
    02/06/2015 RIP: 0010:set_hv_tscchange_cb+0x15/0xa0 Code: <8b> 04 82 8b 15 12 17 85 01 48 c1 e0 20 48 0d ee
    00 01 00 f6 c6 08 ... Call Trace: kvm_arch_init+0x17c/0x280 kvm_init+0x31/0x330 vmx_init+0xba/0x13a
    do_one_initcall+0x41/0x1c0 kernel_init_freeable+0x1f2/0x23b kernel_init+0x16/0x120 ret_from_fork+0x22/0x30
    (CVE-2021-47217)

  - A use-after-free vulnerability was found in rtsx_usb_ms_drv_remove in drivers/memstick/host/rtsx_usb_ms.c
    in memstick in the Linux kernel. In this flaw, a local attacker with a user privilege may impact system
    Confidentiality. This flaw affects kernel versions prior to 5.14 rc1. (CVE-2022-0487)

  - An issue was discovered in drivers/input/input.c in the Linux kernel before 5.17.10. An attacker can cause
    a denial of service (panic) because input_set_capability mishandles the situation in which an event code
    falls outside of a bitmap. (CVE-2022-48619)

  - In the Linux kernel, the following vulnerability has been resolved: moxart: fix potential use-after-free
    on remove path It was reported that the mmc host structure could be accessed after it was freed in
    moxart_remove(), so fix this by saving the base register of the device and using it instead of the pointer
    dereference. (CVE-2022-48626)

  - In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix Oops in
    dasd_alias_get_start_dev due to missing pavgroup Fix Oops in dasd_alias_get_start_dev() function caused by
    the pavgroup pointer being NULL. The pavgroup pointer is checked on the entrance of the function but
    without the lcu->lock being held. Therefore there is a race window between dasd_alias_get_start_dev() and
    _lcu_update() which sets pavgroup to NULL with the lcu->lock held. Fix by checking the pavgroup pointer
    with lcu->lock held. (CVE-2022-48636)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix memory leak in
    __qlt_24xx_handle_abts() Commit 8f394da36a36 (scsi: qla2xxx: Drop TARGET_SCF_LOOKUP_LUN_FROM_TAG) made
    the __qlt_24xx_handle_abts() function return early if tcm_qla2xxx_find_cmd_by_tag() didn't find a command,
    but it missed to clean up the allocated memory for the management command. (CVE-2022-48650)

  - In the Linux kernel, the following vulnerability has been resolved: ipvlan: Fix out-of-bound bugs caused
    by unset skb->mac_header If an AF_PACKET socket is used to send packets through ipvlan and the default
    xmit function of the AF_PACKET socket is changed from dev_queue_xmit() to packet_direct_xmit() via
    setsockopt() with the option name of PACKET_QDISC_BYPASS, the skb->mac_header may not be reset and remains
    as the initial value of 65535, this may trigger slab-out-of-bounds bugs as following:
    ================================================================= UG: KASAN: slab-out-of-bounds in
    ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] PU: 2 PID: 1768 Comm: raw_send Kdump: loaded Not tainted
    6.0.0-rc4+ #6 ardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 all Trace:
    print_address_description.constprop.0+0x1d/0x160 print_report.cold+0x4f/0x112 kasan_report+0xa3/0x130
    ipvlan_xmit_mode_l2+0xdb/0x330 [ipvlan] ipvlan_start_xmit+0x29/0xa0 [ipvlan] __dev_direct_xmit+0x2e2/0x380
    packet_direct_xmit+0x22/0x60 packet_snd+0x7c9/0xc40 sock_sendmsg+0x9a/0xa0 __sys_sendto+0x18a/0x230
    __x64_sys_sendto+0x74/0x90 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The root cause
    is: 1. packet_snd() only reset skb->mac_header when sock->type is SOCK_RAW and skb->protocol is not
    specified as in packet_parse_headers() 2. packet_direct_xmit() doesn't reset skb->mac_header as
    dev_queue_xmit() In this case, skb->mac_header is 65535 when ipvlan_xmit_mode_l2() is called. So when
    ipvlan_xmit_mode_l2() gets mac header with eth_hdr() which use skb->head + skb->mac_header, out-of-bound
    access occurs. This patch replaces eth_hdr() with skb_eth_hdr() in ipvlan_xmit_mode_l2() and reset mac
    header in multicast to solve this out-of-bound bug. (CVE-2022-48651)

  - In the Linux kernel, the following vulnerability has been resolved: smb3: fix temporary data corruption in
    insert range insert range doesn't discard the affected cached region so can risk temporarily corrupting
    file data. Also includes some minor cleanup (avoiding rereading inode size repeatedly unnecessarily) to
    make it clearer. (CVE-2022-48667)

  - In the Linux kernel, the following vulnerability has been resolved: smb3: fix temporary data corruption in
    collapse range collapse range doesn't discard the affected cached region so can risk temporarily
    corrupting the file data. This fixes xfstest generic/031 I also decided to merge a minor cleanup to this
    into the same patch (avoiding rereading inode size repeatedly unnecessarily) to make it clearer.
    (CVE-2022-48668)

  - 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. (CVE-2022-48687)

  - In the Linux kernel, the following vulnerability has been resolved: i40e: Fix kernel crash during module
    removal The driver incorrectly frees client instance and subsequent i40e module removal leads to kernel
    crash. Reproducer: 1. Do ethtool offline test followed immediately by another one host# ethtool -t eth0
    offline; ethtool -t eth0 offline 2. Remove recursively irdma module that also removes i40e module host#
    modprobe -r irdma Result: [ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting [ 8675.193774]
    i40e 0000:3d:00.0 eno1: testing finished [ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting [
    8675.358921] i40e 0000:3d:00.0 eno1: testing finished [ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware
    initialization FAILED init_state=2 status=-110 [ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed
    PHC on eno2 [ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01 [
    8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1 [ 8687.761787] BUG: kernel NULL pointer
    dereference, address: 0000000000000030 [ 8687.768755] #PF: supervisor read access in kernel mode [
    8687.773895] #PF: error_code(0x0000) - not-present page [ 8687.779034] PGD 0 P4D 0 [ 8687.781575] Oops:
    0000 [#1] PREEMPT SMP NOPTI [ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G W I
    5.19.0+ #2 [ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS
    SE5C620.86B.0X.02.0001.051420190324 05/14/2019 [ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0
    [i40e] [ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44
    00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb <48> 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f
    d5 48 8b [ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202 [ 8687.834689] RAX: 0000000000000000
    RBX: ffff8f43833b2000 RCX: 0000000000000000 [ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298
    RDI: ffff8f43833b2000 [ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000 [
    8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0 [ 8687.863218] R13:
    ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008 [ 8687.870342] FS: 00007f79501c3740(0000)
    GS:ffff8f4adffc0000(0000) knlGS:0000000000000000 [ 8687.878427] CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 [ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0 [
    8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 8687.898441] DR3:
    0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8687.905572] PKRU: 55555554 [ 8687.908286]
    Call Trace: [ 8687.910737] <TASK> [ 8687.912843] i40e_remove+0x2c0/0x330 [i40e] [ 8687.917040]
    pci_device_remove+0x33/0xa0 [ 8687.920962] device_release_driver_internal+0x1aa/0x230 [ 8687.926188]
    driver_detach+0x44/0x90 [ 8687.929770] bus_remove_driver+0x55/0xe0 [ 8687.933693]
    pci_unregister_driver+0x2a/0xb0 [ 8687.937967] i40e_exit_module+0xc/0xf48 [i40e] Two offline tests cause
    IRDMA driver failure (ETIMEDOUT) and this failure is indicated back to i40e_client_subtask() that calls
    i40e_client_del_instance() to free client instance referenced by pf->cinst and sets this pointer to NULL.
    During the module removal i40e_remove() calls i40e_lan_del_device() that dereferences pf->cinst that is
    NULL -> crash. Do not remove client instance when client open callbacks fails and just clear
    __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needs to take care about this situation (when netdev is
    up and client is NOT opened) in i40e_notify_client_of_netdev_close() and calls client close callback only
    when __I40E_CLIENT_INSTANCE_OPENED is set. (CVE-2022-48688)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: mpt3sas: Fix use-after-free
    warning Fix the following use-after-free warning which is observed during controller reset: refcount_t:
    underflow; use-after-free. WARNING: CPU: 23 PID: 5399 at lib/refcount.c:28
    refcount_warn_saturate+0xa6/0xf0 (CVE-2022-48695)

  - In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Fix an out-of-bounds
    bug in __snd_usb_parse_audio_interface() There may be a bad USB audio device with a USB ID of (0x04fa,
    0x4201) and the number of it's interfaces less than 4, an out-of-bounds read bug occurs when parsing the
    interface descriptor for this device. Fix this by checking the number of interfaces. (CVE-2022-48701)

  - A deadlock flaw was found in the Linux kernel's BPF subsystem. This flaw allows a local user to
    potentially crash the system. (CVE-2023-0160)

  - Information exposure through microarchitectural state after transient execution from some register files
    for some Intel(R) Atom(R) Processors may allow an authenticated user to potentially enable information
    disclosure via local access. (CVE-2023-28746)

  - An issue was discovered in the Linux kernel through 6.3.8. A use-after-free was found in ravb_remove in
    drivers/net/ethernet/renesas/ravb_main.c. (CVE-2023-35827)

  - In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix a kernel panic when
    host sends an invalid H2C PDU length If the host sends an H2CData command with an invalid DATAL, the
    kernel may crash in nvmet_tcp_build_pdu_iovec(). Unable to handle kernel NULL pointer dereference at
    virtual address 0000000000000000 lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp] Call trace:
    process_one_work+0x174/0x3c8 worker_thread+0x2d0/0x3e8 kthread+0x104/0x110 Fix the bug by raising a fatal
    error if DATAL isn't coherent with the packet size. Also, the PDU length should never exceed the
    MAXH2CDATA parameter which has been communicated to the host in nvmet_tcp_handle_icreq(). (CVE-2023-52454)

  - In the Linux kernel, the following vulnerability has been resolved: drivers/amd/pm: fix a use-after-free
    in kv_parse_power_table When ps allocated by kzalloc equals to NULL, kv_parse_power_table frees
    adev->pm.dpm.ps that allocated before. However, after the control flow goes through the following call
    chains: kv_parse_power_table |-> kv_dpm_init |-> kv_dpm_sw_init |-> kv_dpm_fini The adev->pm.dpm.ps is
    used in the for loop of kv_dpm_fini after its first free in kv_parse_power_table and causes a use-after-
    free bug. (CVE-2023-52469)

  - In the Linux kernel, the following vulnerability has been resolved: drm/radeon: check the alloc_workqueue
    return value in radeon_crtc_init() check the alloc_workqueue return value in radeon_crtc_init() to avoid
    null-ptr-deref. (CVE-2023-52470)

  - In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix bugs with non-PAGE_SIZE-
    end multi-iovec user SDMA requests hfi1 user SDMA request processing has two bugs that can cause data
    corruption for user SDMA requests that have multiple payload iovecs where an iovec other than the tail
    iovec does not run up to the page boundary for the buffer pointed to by that iovec.a Here are the specific
    bugs: 1. user_sdma_txadd() does not use struct user_sdma_iovec->iov.iov_len. Rather, user_sdma_txadd()
    will add up to PAGE_SIZE bytes from iovec to the packet, even if some of those bytes are past
    iovec->iov.iov_len and are thus not intended to be in the packet. 2. user_sdma_txadd() and
    user_sdma_send_pkts() fail to advance to the next iovec in user_sdma_request->iovs when the current iovec
    is not PAGE_SIZE and does not contain enough data to complete the packet. The transmitted packet will
    contain the wrong data from the iovec pages. This has not been an issue with SDMA packets from hfi1 Verbs
    or PSM2 because they only produce iovecs that end short of PAGE_SIZE as the tail iovec of an SDMA request.
    Fixing these bugs exposes other bugs with the SDMA pin cache (struct mmu_rb_handler) that get in way of
    supporting user SDMA requests with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So this
    commit fixes those issues as well. Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec
    payload user SDMA requests can hit: 1. Overlapping memory ranges in mmu_rb_handler will result in
    duplicate pinnings. 2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node), the mmu_rb
    code (1) removes the existing entry under a lock, (2) releases that lock, pins the new pages, (3) then
    reacquires the lock to insert the extended mmu_rb_node. If someone else comes in and inserts an
    overlapping entry between (2) and (3), insert in (3) will fail. The failure path code in this case unpins
    _all_ pages in either the original mmu_rb_node or the new mmu_rb_node that was inserted between (2) and
    (3). 3. In hfi1_mmu_rb_remove_unless_exact(), mmu_rb_node->refcount is incremented outside of
    mmu_rb_handler->lock. As a result, mmu_rb_node could be evicted by another thread that gets
    mmu_rb_handler->lock and checks mmu_rb_node->refcount before mmu_rb_node->refcount is incremented. 4.
    Related to #2 above, SDMA request submission failure path does not check mmu_rb_node->refcount before
    freeing mmu_rb_node object. If there are other SDMA requests in progress whose iovecs have pointers to the
    now-freed mmu_rb_node(s), those pointers to the now-freed mmu_rb nodes will be dereferenced when those
    SDMA requests complete. (CVE-2023-52474)

  - In the Linux kernel, the following vulnerability has been resolved: perf/x86/lbr: Filter vsyscall
    addresses We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the
    vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top):
    __insn_get_emulate_prefix() insn_get_emulate_prefix() insn_get_prefixes() insn_get_opcode()
    decode_branch_type() get_branch_type() intel_pmu_lbr_filter() intel_pmu_handle_irq()
    perf_event_nmi_handler() Within __insn_get_emulate_prefix() at frame 0, a macro is called:
    peek_nbyte_next(insn_byte_t, insn, i) Within this macro, this dereference occurs: (insn)->next_byte
    Inspecting registers at this point, the value of the next_byte field is the address of the vsyscall made,
    for example the location of the vsyscall version of gettimeofday() at 0xffffffffff600000. The access to an
    address in the vsyscall region will trigger an oops due to an unhandled page fault. To fix the bug,
    filtering for vsyscalls can be done when determining the branch type. This patch will return a none
    branch if a kernel address if found to lie in the vsyscall region. (CVE-2023-52476)

  - In the Linux kernel, the following vulnerability has been resolved: usb: hub: Guard against accesses to
    uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access
    fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor()
    fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel
    NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5
    PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name:
    Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP:
    0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88
    92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02
    00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000
    RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP:
    ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000
    R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS:
    0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace:
    hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288
    kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70
    ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn't accessible and skip
    all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2
    states setup. (CVE-2023-52477)

  - In the Linux kernel, the following vulnerability has been resolved: drm: Don't unref the same fb many
    times by mistake due to deadlock handling If we get a deadlock after the fb lookup in
    drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we
    forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before
    the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end
    result is that the fb will (eventually) end up being freed while it's still in use. Reset fb to NULL once
    we've unreffed it to avoid doing it again until we've done another fb lookup. This turned out to be pretty
    easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I
    saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I
    was able to convince it to oops instead, and from there it was easier to track down the culprit.
    (CVE-2023-52486)

  - In the Linux kernel, the following vulnerability has been resolved: serial: sc16is7xx: convert from _raw_
    to _noinc_ regmap functions for FIFO The SC16IS7XX IC supports a burst mode to access the FIFOs where the
    initial register address is sent ($00), followed by all the FIFO data without having to resend the
    register address each time. In this mode, the IC doesn't increment the register address for each R/W byte.
    The regmap_raw_read() and regmap_raw_write() are functions which can perform IO over multiple registers.
    They are currently used to read/write from/to the FIFO, and although they operate correctly in this burst
    mode on the SPI bus, they would corrupt the regmap cache if it was not disabled manually. The reason is
    that when the R/W size is more than 1 byte, these functions assume that the register address is
    incremented and handle the cache accordingly. Convert FIFO R/W functions to use the regmap _noinc_
    versions in order to remove the manual cache control which was a workaround when using the _raw_ versions.
    FIFO registers are properly declared as volatile so cache will not be used/updated for FIFO accesses.
    (CVE-2023-52488)

  - In the Linux kernel, the following vulnerability has been resolved: ravb: Fix use-after-free issue in
    ravb_tx_timeout_work() The ravb_stop() should call cancel_work_sync(). Otherwise, ravb_tx_timeout_work()
    is possible to use the freed priv after ravb_remove() was called like below: CPU0 CPU1 ravb_tx_timeout()
    ravb_remove() unregister_netdev() free_netdev(ndev) // free priv ravb_tx_timeout_work() // use priv
    unregister_netdev() will call .ndo_stop() so that ravb_stop() is called. And, after phy_stop() is called,
    netif_carrier_off() is also called. So that .ndo_tx_timeout() will not be called after phy_stop().
    (CVE-2023-52509)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: Do not call scsi_done() from
    srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs
    one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call
    scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions
    would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the
    srp_free_req() call before returning SUCCESS because we may not see the command again if SUCCESS is
    returned. (CVE-2023-52515)

  - In the Linux kernel, the following vulnerability has been resolved: net: nfc: llcp: Add lock when
    modifying device list The device list needs its associated lock held when modifying it, or the list could
    become corrupted, as syzbot discovered. (CVE-2023-52524)

  - In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Fix uninit-value
    access in __smsc75xx_read_reg syzbot reported the following uninit-value access issue:
    ===================================================== BUG: KMSAN: uninit-value in smsc75xx_wait_ready
    drivers/net/usb/smsc75xx.c:975 [inline] BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0
    drivers/net/usb/smsc75xx.c:1482 CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue:
    usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280
    lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0
    mm/kmsan/kmsan_instr.c:215 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
    smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 usbnet_probe+0x1152/0x3f90
    drivers/net/usb/usbnet.c:1737 usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374
    really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701
    __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0
    drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60
    drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0
    drivers/base/core.c:2680 usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032
    usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241 usb_probe_device+0x311/0x490
    drivers/usb/core/driver.c:272 really_probe+0xf20/0x20b0 drivers/base/dd.c:529
    driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830
    drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0
    drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0
    drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_new_device+0x1bd4/0x2a30
    drivers/usb/core/hub.c:2554 hub_port_connect drivers/usb/core/hub.c:5208 [inline] hub_port_connect_change
    drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline]
    hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576 process_one_work+0x1688/0x2140 kernel/workqueue.c:2269
    worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415 kthread+0x551/0x590 kernel/kthread.c:292
    ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Local variable ----buf.i87@smsc75xx_bind created at:
    __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready
    drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
    __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready
    drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 This
    issue is caused because usbnet_read_cmd() reads less bytes than requested (zero byte in the reproducer).
    In this case, 'buf' is not properly filled. This patch fixes the issue by returning -ENODATA if
    usbnet_read_cmd() reads less bytes than requested. (CVE-2023-52528)

  - In the Linux kernel, the following vulnerability has been resolved: ceph: fix deadlock or deadcode of
    misusing dget() The lock order is incorrect between denty and its parent, we should always make sure that
    the parent get the lock first. But since this deadcode is never used and the parent dir will always be set
    from the callers, let's just remove it. (CVE-2023-52583)

  - In the Linux kernel, the following vulnerability has been resolved: IB/ipoib: Fix mcast list locking
    Releasing the `priv->lock` while iterating the `priv->multicast_list` in `ipoib_mcast_join_task()` opens a
    window for `ipoib_mcast_dev_flush()` to remove the items while in the middle of iteration. If the mcast is
    removed while the lock was dropped, the for loop spins forever resulting in a hard lockup (as was reported
    on RHEL 4.18.0-372.75.1.el8_6 kernel): Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)
    -----------------------------------+----------------------------------- ipoib_mcast_join_task(work) |
    ipoib_ib_dev_flush_light(work) spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...)
    list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev) &priv->multicast_list, list) |
    ipoib_mcast_join(dev, mcast) | spin_unlock_irq(&priv->lock) | | spin_lock_irqsave(&priv->lock, flags) |
    list_for_each_entry_safe(mcast, tmcast, | &priv->multicast_list, list) | list_del(&mcast->list); |
    list_add_tail(&mcast->list, &remove_list) | spin_unlock_irqrestore(&priv->lock, flags)
    spin_lock_irq(&priv->lock) | | ipoib_mcast_remove_list(&remove_list) (Here, `mcast` is no longer on the |
    list_for_each_entry_safe(mcast, tmcast, `priv->multicast_list` and we keep | remove_list, list) spinning
    on the `remove_list` of | >>> wait_for_completion(&mcast->done) the other thread which is blocked | and
    the list is still valid on | it's stack.) Fix this by keeping the lock held and changing to GFP_ATOMIC to
    prevent eventual sleeps. Unfortunately we could not reproduce the lockup and confirm this fix but based on
    the code review I think this fix should address such lockups. crash> bc 31 PID: 747 TASK: ff1c6a1a007e8000
    CPU: 31 COMMAND: kworker/u72:2 -- [exception RIP: ipoib_mcast_join_task+0x1b1] RIP: ffffffffc0944ac1
    RSP: ff646f199a8c7e00 RFLAGS: 00000002 RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000
    work (&priv->mcast_task{,.work}) RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000
    &mcast->list RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000 R10: ff646f199a8c7e00 R11:
    ff1c6a191a7d9800 R12: ff1c6a192d60ac00 mcast R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15:
    ff1c6a1a04dc82d8 dev priv (&priv->lock) &priv->multicast_list (aka head) ORIG_RAX: ffffffffffffffff CS:
    0010 SS: 0018 --- <NMI exception stack> --- #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at
    ffffffffc0944ac1 [ib_ipoib] #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967 crash> rx
    ff646f199a8c7e68 ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work crash> list -hO
    ipoib_dev_priv.multicast_list ff1c6a1a04dc8000 (empty) crash>
    ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000 mcast_task.work.func =
    0xffffffffc0944910 <ipoib_mcast_join_task>, mcast_mutex.owner.counter = 0xff1c69998efec000 crash> b 8 PID:
    8 TASK: ff1c69998efec000 CPU: 33 COMMAND: kworker/u72:0 -- #3 [ff646f1980153d50]
    wait_for_completion+0x96 at ffffffff9c7d7646 #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at
    ffffffffc0944dc6 [ib_ipoib] #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7
    [ib_ipoib] #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib] #7 [ff
    ---truncated--- (CVE-2023-52587)

  - In the Linux kernel, the following vulnerability has been resolved: ocfs2: Avoid touching renamed
    directory if parent does not change The VFS will not be locking moved directory if its parent does not
    change. Change ocfs2 rename code to avoid touching renamed directory if its parent does not change as
    without locking that can corrupt the filesystem. (CVE-2023-52590)

  - In the Linux kernel, the following vulnerability has been resolved: reiserfs: Avoid touching renamed
    directory if parent does not change The VFS will not be locking moved directory if its parent does not
    change. Change reiserfs rename code to avoid touching renamed directory if its parent does not change as
    without locking that can corrupt the filesystem. (CVE-2023-52591)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00: restart beacon queue
    when hardware reset When a hardware reset is triggered, all registers are reset, so all queues are forced
    to stop in hardware interface. However, mac80211 will not automatically stop the queue. If we don't
    manually stop the beacon queue, the queue will be deadlocked and unable to start again. This patch fixes
    the issue where Apple devices cannot connect to the AP after calling ieee80211_restart_hw().
    (CVE-2023-52595)

  - In the Linux kernel, the following vulnerability has been resolved: s390/ptrace: handle setting of fpc
    register correctly If the content of the floating point control (fpc) register of a traced process is
    modified with the ptrace interface the new value is tested for validity by temporarily loading it into the
    fpc register. This may lead to corruption of the fpc register of the tracing process: if an interrupt
    happens while the value is temporarily loaded into the fpc register, and within interrupt context floating
    point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming
    they belong to user space and will be loaded into fp/vx registers when returning to user space.
    test_fp_ctl() restores the original user space fpc register value, however it will be discarded, when
    returning to user space. In result the tracer will incorrectly continue to run with the value that was
    supposed to be used for the traced process. Fix this by saving fpu register contents with save_fpu_regs()
    before using test_fp_ctl(). (CVE-2023-52598)

  - In the Linux kernel, the following vulnerability has been resolved: powerpc/mm: Fix null-pointer
    dereference in pgtable_cache_add kasprintf() returns a pointer to dynamically allocated memory which can
    be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.
    (CVE-2023-52607)

  - In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Fix buffer overflow in
    trans_stat_show Fix buffer overflow in trans_stat_show(). Convert simple snprintf to the more secure
    scnprintf with size of PAGE_SIZE. Add condition checking if we are exceeding PAGE_SIZE and exit early from
    loop. Also add at the end a warning that we exceeded PAGE_SIZE and that stats is disabled. Return -EFBIG
    in the case where we don't have enough space to write the full transition table. Also document in the ABI
    that this function can return -EFBIG error. (CVE-2023-52614)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: disallow timeout
    for anonymous sets Never used from userspace, disallow these parameters. (CVE-2023-52620)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: exthdr: fix
    4-byte stack OOB write If priv->len is a multiple of 4, then dst[len / 4] can write past the destination
    array which leads to stack corruption. This construct is necessary to clean the remainder of the register
    in case ->len is NOT a multiple of the register size, so make it conditional just like nft_payload.c does.
    The bug was added in 4.1 cycle and then copied/inherited when tcp/sctp and ip option support was added.
    Bug reported by Zero Day Initiative project (ZDI-CAN-21950, ZDI-CAN-21951, ZDI-CAN-21961).
    (CVE-2023-52628)

  - In the Linux kernel, the following vulnerability has been resolved: PM / devfreq: Synchronize
    devfreq_monitor_[start/stop] There is a chance if a frequent switch of the governor done in a loop result
    in timer list corruption where timer cancel being done from two place one from cancel_delayed_work_sync()
    and followed by expire_timers() can be seen from the traces[1]. while true do echo simple_ondemand >
    /sys/class/devfreq/1d84000.ufshc/governor echo performance > /sys/class/devfreq/1d84000.ufshc/governor
    done It looks to be issue with devfreq driver where device_monitor_[start/stop] need to synchronized so
    that delayed work should get corrupted while it is either being queued or running or being cancelled.
    Let's use polling flag and devfreq lock to synchronize the queueing the timer instance twice and work data
    being corrupted. [1] ... .. <idle>-0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428 <idle>-0
    [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c
    function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c <idle>-0 [003] 9436.209718:
    timer_expire_exit timer=0xffffff80444f0428 kworker/u16:6-14217 [003] 9436.209863: timer_start
    timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b
    now=0x10022da1c flags=182452227 vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel
    timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428
    vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428
    function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532
    vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428 xxxyyyTraceManag-7795 [004]
    9436.261641: timer_cancel timer=0xffffff80444f0428 [2] 9436.261653][ C4] Unable to handle kernel paging
    request at virtual address dead00000000012a [ 9436.261664][ C4] Mem abort info: [ 9436.261666][ C4] ESR =
    0x96000044 [ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits [ 9436.261671][ C4] SET = 0, FnV
    = 0 [ 9436.261673][ C4] EA = 0, S1PTW = 0 [ 9436.261675][ C4] Data abort info: [ 9436.261677][ C4] ISV =
    0, ISS = 0x00000044 [ 9436.261680][ C4] CM = 0, WnR = 1 [ 9436.261682][ C4] [dead00000000012a] address
    between user and kernel address ranges [ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP
    [ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0 ... [ 9436.262138][ C4] CPU: 4 PID: 7795
    Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1 [ 9436.262141][ C4] Hardware
    name: Qualcomm Technologies, Inc. (DT) [ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO
    BTYPE=--) [ 9436.262161][ C4] pc : expire_timers+0x9c/0x438 [ 9436.262164][ C4] lr :
    expire_timers+0x2a4/0x438 [ 9436.262168][ C4] sp : ffffffc010023dd0 [ 9436.262171][ C4] x29:
    ffffffc010023df0 x28: ffffffd0636fdc18 [ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008 [
    9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280 [ 9436.262185][ C4] x23: 00000000000000e0
    x22: dead000000000122 [ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80 [ 9436.262191][ C4]
    x19: ffffffc010023e50 x18: ffffffc010025038 [ 9436.262195][ C4] x17: 0000000000000240 x16:
    0000000000000201 [ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100 [ 9436.262203][ C4] x13:
    ffffff889f3c3100 x12: 00000000049f56b8 [ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff [
    9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122 [ 9436.262216][ C4] x7 : ffffffffffffffff x6
    : ffffffc0100239d8 [ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101 [ 9436.262223][ C4] x3
    : 0000000000000080 x2 : ffffff8 ---truncated--- (CVE-2023-52635)

  - In the Linux kernel, the following vulnerability has been resolved: KVM: s390: vsie: fix race during
    shadow creation Right now it is possible to see gmap->private being zero in kvm_s390_vsie_gmap_notifier
    resulting in a crash. This is due to the fact that we add gmap->private == kvm after creation: static int
    acquire_gmap_shadow(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) { [...] gmap =
    gmap_shadow(vcpu->arch.gmap, asce, edat); if (IS_ERR(gmap)) return PTR_ERR(gmap); gmap->private =
    vcpu->kvm; Let children inherit the private field of the parent. (CVE-2023-52639)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: b43: Stop/wake correct queue in
    DMA Tx path when QoS is disabled When QoS is disabled, the queue priority value will not map to the
    correct ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS is disabled to prevent
    trying to stop/wake a non-existent queue and failing to stop/wake the actual queue instantiated. Log of
    issue before change (with kernel parameter qos=0): [ +5.112651] ------------[ cut here ]------------ [
    +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180
    [mac80211] [ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device
    nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu
    snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack
    nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog
    xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915
    intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap
    btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437
    x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg
    crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun
    drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul
    macvlan ttm ghash_clmulni_intel ecc tg3 [ +0.000044] videodev bridge snd_hda_core rapl crc16
    drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp
    mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt
    industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus
    thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button
    sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse
    backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc
    encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid
    sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci
    ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel
    usbcore scsi_mod libaes crypto_simd cryptd scsi_common [ +0.000055] usb_common rtc_cmos btrfs
    blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last
    unloaded: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS [
    +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019 [
    +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000046] Code: 00 45 85 e4 0f 85 9b
    00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0
    <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00 [ +0.000002] RSP:
    0018:ffffc90003c77d60 EFLAGS: 00010097 [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX:
    0000000000000000 [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900 [
    +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0 [ +0.000001] R10:
    ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000 [ +0.000001] R13: 0000000000000000 R14:
    ffffc90003c77d90 R15: ffffffffc0fa6f40 [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000)
    knlGS:0000000000000000 [ +0.000001] CS: 0010 DS: 0 ---truncated--- (CVE-2023-52644)

  - In the Linux kernel, the following vulnerability has been resolved: aio: fix mremap after fork null-deref
    Commit e4a0d3e720e7 (aio: Make it possible to remap aio ring) introduced a null-deref if mremap is
    called on an old aio mapping after fork as mm->ioctx_table will be set to NULL. [[email protected]: fix 80
    column issue] (CVE-2023-52646)

  - In the Linux kernel, the following vulnerability has been resolved: drm/tegra: dsi: Add missing check for
    of_find_device_by_node Add check for the return value of of_find_device_by_node() and return the error if
    it fails in order to avoid NULL pointer dereference. (CVE-2023-52650)

  - In the Linux kernel, the following vulnerability has been resolved: NTB: fix possible name leak in
    ntb_register_device() If device_register() fails in ntb_register_device(), the device name allocated by
    dev_set_name() should be freed. As per the comment in device_register(), callers should use put_device()
    to give up the reference in the error path. So fix this by calling put_device() in the error path so that
    the name can be freed in kobject_cleanup(). As a result of this, put_device() in the error path of
    ntb_register_device() is removed and the actual error is returned. [mani: reworded commit message]
    (CVE-2023-52652)

  - In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix a memleak in
    gss_import_v2_context The ctx->mech_used.data allocated by kmemdup is not freed in neither
    gss_import_v2_context nor it only caller gss_krb5_import_sec_context, which frees ctx on error. Thus, this
    patch reform the last call of gss_import_v2_context to the gss_krb5_import_ctx_v2, preventing the memleak
    while keepping the return formation. (CVE-2023-52653)

  - A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function
    improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing
    between the free on the struct and the access through the `skbtxq` global queue. This could lead to a
    denial of service condition or potential code execution. (CVE-2023-6270)

  - A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious
    actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL
    pointer dereference in the NVMe driver and causing kernel panic and a denial of service. (CVE-2023-6356)

  - A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious
    actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL
    pointer dereference in the NVMe driver, causing kernel panic and a denial of service. (CVE-2023-6535,
    CVE-2023-6536)

  - A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in
    drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a
    denial of service. (CVE-2023-7042)

  - A memory leak problem was found in ctnetlink_create_conntrack in net/netfilter/nf_conntrack_netlink.c in
    the Linux Kernel. This issue may allow a local attacker with CAP_NET_ADMIN privileges to cause a denial of
    service (DoS) attack due to a refcount overflow. (CVE-2023-7192)

  - This CVE was assigned by Intel. Please see CVE-2024-2201 on CVE.org for more information. (CVE-2024-2201)

  - NULL Pointer Dereference vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (net, bluetooth
    modules) allows Overflow Buffers. This vulnerability is associated with program files
    /net/bluetooth/rfcomm/core.C. This issue affects Linux kernel: v2.6.12-rc2. (CVE-2024-22099)

  - Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid,
    raid5 modules) allows Forced Integer Overflow. (CVE-2024-23307)

  - In the Linux kernel through 6.7.1, there is a use-after-free in cec_queue_msg_fh, related to
    drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c. (CVE-2024-23848)

  - A race condition was found in the Linux kernel's scsi device driver in lpfc_unregister_fcf_rescan()
    function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or
    denial of service issue. (CVE-2024-24855)

  - A race condition was found in the Linux kernel's media/xc4000 device driver in xc4000
    xc4000_get_frequency() function. This can result in return value overflow issue, possibly leading to
    malfunction or denial of service issue. (CVE-2024-24861)

  - In the Linux kernel, the following vulnerability has been resolved: tcp: make sure init the accept_queue's
    spinlocks once When I run syz's reproduction C program locally, it causes the following issue:
    pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0! WARNING: CPU: 19 PID: 21160 at
    __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508) Hardware name: Red Hat KVM,
    BIOS 0.5.1 01/01/2011 RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)
    Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c7
    30 20 ce 8f e8 ad 56 42 ff <0f> 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 RSP:
    0018:ffffa8d200604cb8 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908
    RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900 RBP: ffff9d181cd5c280 R08:
    0000000000000000 R09: 00000000ffff7fff R10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000
    R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000 FS: 00007fa110184640(0000)
    GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0 Call Trace: <IRQ> _raw_spin_unlock
    (kernel/locking/spinlock.c:186) inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)
    inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358) tcp_check_req
    (net/ipv4/tcp_minisocks.c:868) tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260) ip_protocol_deliver_rcu
    (net/ipv4/ip_input.c:205) ip_local_deliver_finish (net/ipv4/ip_input.c:234) __netif_receive_skb_one_core
    (net/core/dev.c:5529) process_backlog (./include/linux/rcupdate.h:779) __napi_poll (net/core/dev.c:6533)
    net_rx_action (net/core/dev.c:6604) __do_softirq (./arch/x86/include/asm/jump_label.h:27) do_softirq
    (kernel/softirq.c:454 kernel/softirq.c:441) </IRQ> <TASK> __local_bh_enable_ip (kernel/softirq.c:381)
    __dev_queue_xmit (net/core/dev.c:4374) ip_finish_output2 (./include/net/neighbour.h:540
    net/ipv4/ip_output.c:235) __ip_queue_xmit (net/ipv4/ip_output.c:535) __tcp_transmit_skb
    (net/ipv4/tcp_output.c:1462) tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)
    tcp_rcv_state_process (net/ipv4/tcp_input.c:6657) tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929) __release_sock
    (./include/net/sock.h:1121 net/core/sock.c:2968) release_sock (net/core/sock.c:3536) inet_wait_for_connect
    (net/ipv4/af_inet.c:609) __inet_stream_connect (net/ipv4/af_inet.c:702) inet_stream_connect
    (net/ipv4/af_inet.c:748) __sys_connect (./include/linux/file.h:45 net/socket.c:2064) __x64_sys_connect
    (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070) do_syscall_64 (arch/x86/entry/common.c:51
    arch/x86/entry/common.c:82) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129) RIP:
    0033:0x7fa10ff05a3d Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48
    89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89
    01 48 RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a RAX: ffffffffffffffda RBX:
    0000000020000054 RCX: 00007fa10ff05a3d RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003
    RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11:
    0000000000000202 R12: 00007fa110184640 R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20
    </TASK> The issue triggering process is analyzed as follows: Thread A Thread B tcp_v4_rcv //receive ack
    TCP packet inet_shutdown tcp_check_req tcp_disconnect //disconnect sock ... tcp_set_state(sk, TCP_CLOSE)
    inet_csk_complete_hashdance ... inet_csk_reqsk_queue_add ---truncated--- (CVE-2024-26614)

  - In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: disallow
    anonymous set with timeout flag Anonymous sets are never used with timeout from userspace, reject this.
    Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work. (CVE-2024-26642)

  - In the Linux kernel, the following vulnerability has been resolved: sr9800: Add check for
    usbnet_get_endpoints Add check for usbnet_get_endpoints() and return the error if it fails in order to
    transfer the error. (CVE-2024-26651)

  - In the Linux kernel, the following vulnerability has been resolved: blk-mq: fix IO hang from sbitmap
    wakeup race In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered with the following
    blk_mq_get_driver_tag() in case of getting driver tag failure. Then in __sbitmap_queue_wake_up(),
    waitqueue_active() may not observe the added waiter in blk_mq_mark_tag_wait() and wake up nothing,
    meantime blk_mq_mark_tag_wait() can't get driver tag successfully. This issue can be reproduced by running
    the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in
    laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1
    submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 |
    xargs basename` fio --filename=/dev/$dev --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100
    --numjobs=40 --time_based --name=test \ --ioengine=libaio Fix the issue by adding one explicit barrier in
    blk_mq_mark_tag_wait(), which is just fine in case of running out of tag. (CVE-2024-26671)

  - In the Linux kernel, the following vulnerability has been resolved: ppp_async: limit MRU to 64K syzbot
    triggered a warning [1] in __alloc_pages(): WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp) Willem fixed a
    similar issue in commit c0a2a1b0d631 (ppp: limit MRU to 64K) Adopt the same sanity check for
    ppp_async_ioctl(PPPIOCSMRU) [1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698
    mm/page_alloc.c:4543 Modules linked in: CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted
    6.8.0-rc2-syzkaller-g41bccc98fb79 #0 Hardware name: Google Google Compute Engine/Google Compute Engine,
    BIOS Google 11/17/2023 Workqueue: events_unbound flush_to_ldisc pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO
    -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698
    mm/page_alloc.c:4537 sp : ffff800093967580 x29: ffff800093967660 x28: ffff8000939675a0 x27:
    dfff800000000000 x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0 x23: 0000000000000000
    x22: 0000000000060820 x21: 1ffff0001272ceb8 x20: ffff8000939675e0 x19: 0000000000000010 x18:
    ffff800093967120 x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005 x14: 1ffff0001272cebc
    x13: 0000000000000000 x12: 0000000000000000 x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 :
    0000000000000001 x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 00000000ffffffff
    x4 : 0000000000000000 x3 : 0000000000000020 x2 : 0000000000000008 x1 : 0000000000000000 x0 :
    ffff8000939675e0 Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node
    include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline]
    __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline]
    __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590
    __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715
    netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline]
    ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c
    drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390
    tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444
    [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204
    kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4
    kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20
    arch/arm64/kernel/entry.S:860 (CVE-2024-26675)

  - In the Linux kernel, the following vulnerability has been resolved: ceph: prevent use-after-free in
    encode_cap_msg() In fs/ceph/caps.c, in encode_cap_msg(), use after free error was caught by KASAN at
    this line - 'ceph_buffer_get(arg->xattr_buf);'. This implies before the refcount could be increment here,
    it was freed. In same file, in handle_cap_grant() refcount is decremented by this line -
    'ceph_buffer_put(ci->i_xattrs.blob);'. It appears that a race occurred and resource was freed by the
    latter line before the former line could increment it. encode_cap_msg() is called by __send_cap() and
    __send_cap() is called by ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
    arg->xattr_buf is assigned to ci->i_xattrs.blob. This is the spot where the refcount must be increased to
    prevent use after free error. (CVE-2024-26689)

  - In the Linux kernel, the following vulnerability has been resolved: ext4: fix double-free of blocks due to
    wrong extents moved_len In ext4_move_extents(), moved_len is only updated when all moves are successfully
    executed, and only discards orig_inode and donor_inode preallocations when moved_len is not zero. When the
    loop fails to exit after successfully moving some extents, moved_len is not updated and remains at 0, so
    it does not discard the preallocations. If the moved extents overlap with the preallocated extents, the
    overlapped extents are freed twice in ext4_mb_release_inode_pa() and ext4_process_freed_data() (as
    described in commit 94d7c16cbbbd (ext4: Fix double-free of blocks with EXT4_IOC_MOVE_EXT)), and bb_free
    is incremented twice. Hence when trim is executed, a zero-division bug is triggered in
    mb_update_avg_fragment_size() because bb_free is not zero and bb_fragments is zero. Therefore, update
    move_len after each extent move to avoid the issue. (CVE-2024-26704)

  - In the Linux kernel, the following vulnerability has been resolved: arp: Prevent overflow in
    arp_req_get(). syzkaller reported an overflown write in arp_req_get(). [0] When ioctl(SIOCGARP) is issued,
    arp_req_get() looks up an neighbour entry and copies neigh->ha to struct arpreq.arp_ha.sa_data. The arp_ha
    here is struct sockaddr, not struct sockaddr_storage, so the sa_data buffer is just 14 bytes. In the splat
    below, 2 bytes are overflown to the next int field, arp_flags. We initialise the field just after the
    memcpy(), so it's not a problem. However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN),
    arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL) in arp_ioctl() before calling
    arp_req_get(). To avoid the overflow, let's limit the max length of memcpy(). Note that commit
    b5f0de6df6dc (net: dev: Convert sa_data to flexible array in struct sockaddr) just silenced syzkaller.
    [0]: memcpy: detected field-spanning write (size 16) of single field r->arp_ha.sa_data at
    net/ipv4/arp.c:1128 (size 14) WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0
    net/ipv4/arp.c:1128 Modules linked in: CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 RIP:
    0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48
    c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42
    de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 0000000000000000 RBX:
    ffff88803a815000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001
    RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11:
    203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010
    FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000
    CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0 DR0:
    0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0
    DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261
    inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981 sock_do_ioctl+0xdf/0x260 net/socket.c:1204
    sock_ioctl+0x3ef/0x650 net/socket.c:1321 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870
    [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856 do_syscall_x64
    arch/x86/entry/common.c:51 [inline] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81
    entry_SYSCALL_64_after_hwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Code: 66 2e 0f 1f 84 00 00 00 00 00 0f
    1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0
    ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 00000246
    ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d RDX:
    0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003 RBP: 00007f172b2d3493 R08: 0000000000000000
    R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13:
    000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000 </TASK> (CVE-2024-26733)

  - In the Linux kernel, the following vulnerability has been resolved: net/sched: act_mirred: don't override
    retval if we already lost the skb If we're redirecting the skb, and haven't called tcf_mirred_forward(),
    yet, we need to tell the core to drop the skb by setting the retcode to SHOT. If we have called
    tcf_mirred_forward(), however, the skb is out of our hands and returning SHOT will lead to UaF. Move the
    retval override to the error path which actually need it. (CVE-2024-26739)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/qedr: Fix qedr_create_user_qp
    error flow Avoid the following warning by making sure to free the allocated resources in case that
    qedr_init_user_queue() fail. -----------[ cut here ]----------- WARNING: CPU: 0 PID: 143192 at
    drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Modules linked in:
    tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp
    scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache
    netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert
    iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1
    intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal
    drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif
    sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf
    fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore
    ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi
    sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3 ghash_clmulni_intel megaraid_sas crc8 wmi
    [last unloaded: ib_srpt] CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted
    5.14.0-408.el9.x86_64 #1 Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022 RIP:
    0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8
    67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00
    00 00 48 89 df e8 8e f5 ff ff e9 6d ff RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286 RAX: ffff8f0889ee3f60
    RBX: ffff8f088c1a5200 RCX: 00000000802a0016 RDX: 00000000802a0017 RSI: 0000000000000001 RDI:
    ffff8f0880042600 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8f11fffd5000
    R11: 0000000000039000 R12: ffff8f0d5b36cd80 R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15:
    0000000000000000 FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000 CS: 0010 DS:
    0000 ES: 0000 CR0: 0000000080050033 CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0 Call
    Trace: <TASK> ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ?
    ib_uverbs_close+0x1f/0xb0 [ib_uverbs] ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? __warn+0x81/0x110
    ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs] ? report_bug+0x10a/0x140 ? handle_bug+0x3c/0x70 ?
    exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
    ib_uverbs_close+0x1f/0xb0 [ib_uverbs] __fput+0x94/0x250 task_work_run+0x5c/0x90 do_exit+0x270/0x4a0
    do_group_exit+0x2d/0x90 get_signal+0x87c/0x8c0 arch_do_signal_or_restart+0x25/0x100 ?
    ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs] exit_to_user_mode_loop+0x9c/0x130
    exit_to_user_mode_prepare+0xb6/0x100 syscall_exit_to_user_mode+0x12/0x40 do_syscall_64+0x69/0x90 ?
    syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x22/0x40 ? do_syscall_64+0x69/0x90 ?
    syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x22/0x40 ? do_syscall_64+0x69/0x90 ?
    do_syscall_64+0x69/0x90 ? common_interrupt+0x43/0xa0 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP:
    0033:0x1470abe3ec6b Code: Unable to access opcode bytes at RIP 0x1470abe3ec41. RSP: 002b:00007fff13ce9108
    EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX:
    00001470abe3ec6b RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004 RBP: 00007fff13ce91e0
    R08: 0000558d9655da10 R09: 0000558d9655dd00 R10: 00007fff13ce95c0 R11: 0000000000000246 R12:
    00007fff13ce9358 R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470 </TASK> --[ end trace
    888a9b92e04c5c97 ]-- (CVE-2024-26743)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/srpt: Support specifying the
    srpt_service_guid parameter Make loading ib_srpt with this parameter set work. The current behavior is
    that setting that parameter while loading the ib_srpt kernel module triggers the following kernel crash:
    BUG: kernel NULL pointer dereference, address: 0000000000000000 Call Trace: <TASK> parse_one+0x18c/0x1d0
    parse_args+0xe1/0x230 load_module+0x8de/0xa60 init_module_from_file+0x8b/0xd0
    idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0
    entry_SYSCALL_64_after_hwframe+0x6e/0x76 (CVE-2024-26744)

  - In the Linux kernel, the following vulnerability has been resolved: usb: roles: fix NULL pointer issue
    when put module's reference In current design, usb role class driver will get usb_role_switch parent's
    module reference after the user get usb_role_switch device and put the reference after the user put the
    usb_role_switch device. However, the parent device of usb_role_switch may be removed before the user put
    the usb_role_switch. If so, then, NULL pointer issue will be met when the user put the parent module's
    reference. This will save the module pointer in structure of usb_role_switch. Then, we don't need to find
    module by iterating long relations. (CVE-2024-26747)

  - In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr-
    deref in gtp_genl_dump_pdp() The gtp_net_ops pernet operations structure for the subsystem must be
    registered before registering the generic netlink family. Syzkaller hit 'general protection fault in
    gtp_genl_dump_pdp' bug: general protection fault, probably for non-canonical address 0xdffffc0000000002:
    0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
    CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1 Hardware name: QEMU Standard PC (Q35 +
    ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014 RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp] Code: c6 89 c6 e8
    64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48
    c1 ea 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74 RSP: 0018:ffff888014107220
    EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000002
    RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09:
    0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff88800fcda588
    R14: 0000000000000001 R15: 0000000000000000 FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000)
    knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1be4e766cf CR3:
    000000000c33e000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? show_regs+0x90/0xa0 ?
    die_addr+0x50/0xd0 ? exc_general_protection+0x148/0x220 ? asm_exc_general_protection+0x22/0x30 ?
    gtp_genl_dump_pdp+0x1be/0x800 [gtp] ? __alloc_skb+0x1dd/0x350 ? __pfx___alloc_skb+0x10/0x10
    genl_dumpit+0x11d/0x230 netlink_dump+0x5b9/0xce0 ? lockdep_hardirqs_on_prepare+0x253/0x430 ?
    __pfx_netlink_dump+0x10/0x10 ? kasan_save_track+0x10/0x40 ? __kasan_kmalloc+0x9b/0xa0 ?
    genl_start+0x675/0x970 __netlink_dump_start+0x6fc/0x9f0 genl_family_rcv_msg_dumpit+0x1bb/0x2d0 ?
    __pfx_genl_family_rcv_msg_dumpit+0x10/0x10 ? genl_op_from_small+0x2a/0x440 ? cap_capable+0x1d0/0x240 ?
    __pfx_genl_start+0x10/0x10 ? __pfx_genl_dumpit+0x10/0x10 ? __pfx_genl_done+0x10/0x10 ?
    security_capable+0x9d/0xe0 (CVE-2024-26754)

  - In the Linux kernel, the following vulnerability has been resolved: dm-crypt: don't modify the data when
    using authenticated encryption It was said that authenticated encryption could produce invalid tag when
    the data that is being encrypted is modified [1]. So, fix this problem by copying the data into the clone
    bio first and then encrypt them inside the clone bio. This may reduce performance, but it is needed to
    prevent the user from corrupting the device by writing data with O_DIRECT and modifying them at the same
    time. [1] https://lore.kernel.org/all/[email protected]/T/ (CVE-2024-26763)

  - In the Linux kernel, the following vulnerability has been resolved: dmaengine: ti: edma: Add some null
    pointer checks to the edma_probe devm_kasprintf() returns a pointer to dynamically allocated memory which
    can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.
    (CVE-2024-26771)

  - In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from
    corrupted group in ext4_mb_find_by_goal() Places the logic for checking if the group's block bitmap is
    corrupt under the protection of the group lock to avoid allocating blocks from the group with a corrupted
    block bitmap. (CVE-2024-26772)

  - In the Linux kernel, the following vulnerability has been resolved: ext4: avoid allocating blocks from
    corrupted group in ext4_mb_try_best_found() Determine if the group block bitmap is corrupted before using
    ac_b_ex in ext4_mb_try_best_found() to avoid allocating blocks from a group with a corrupted block bitmap
    in the following concurrency and making the situation worse. ext4_mb_regular_allocator ext4_lock_group(sb,
    group) ext4_mb_good_group // check if the group bbitmap is corrupted ext4_mb_complex_scan_group // Scan
    group gets ac_b_ex but doesn't use it ext4_unlock_group(sb, group) ext4_mark_group_bitmap_corrupted(group)
    // The block bitmap was corrupted during // the group unlock gap. ext4_mb_try_best_found
    ext4_lock_group(ac->ac_sb, group) ext4_mb_use_best_found mb_mark_used // Allocating blocks in block bitmap
    corrupted group (CVE-2024-26773)

  - In the Linux kernel, the following vulnerability has been resolved: fbdev: sis: Error out if pixclock
    equals zero The userspace program could pass any values to the driver through ioctl() interface. If the
    driver doesn't check the value of pixclock, it may cause divide-by-zero error. In sisfb_check_var(),
    var->pixclock is used as a divisor to caculate drate before it is checked against zero. Fix this by
    checking it at the beginning. This is similar to CVE-2022-3061 in i740fb which was fixed by commit
    15cf0b8. (CVE-2024-26777)

  - In the Linux kernel, the following vulnerability has been resolved: fbdev: savage: Error out if pixclock
    equals zero The userspace program could pass any values to the driver through ioctl() interface. If the
    driver doesn't check the value of pixclock, it may cause divide-by-zero error. Although pixclock is
    checked in savagefb_decode_var(), but it is not checked properly in savagefb_probe(). Fix this by checking
    whether pixclock is zero in the function savagefb_check_var() before info->var.pixclock is used as the
    divisor. This is similar to CVE-2022-3061 in i740fb which was fixed by commit 15cf0b8. (CVE-2024-26778)

  - In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix race condition on
    enabling fast-xmit fast-xmit must only be enabled after the sta has been uploaded to the driver, otherwise
    it could end up passing the not-yet-uploaded sta via drv_tx calls to the driver, leading to potential
    crashes because of uninitialized drv_priv data. Add a missing sta->uploaded check and re-check fast xmit
    after inserting a sta. (CVE-2024-26779)

  - In the Linux kernel, the following vulnerability has been resolved: gtp: fix use-after-free and null-ptr-
    deref in gtp_newlink() The gtp_link_ops operations structure for the subsystem must be registered after
    registering the gtp_net_ops pernet operations structure. Syzkaller hit 'general protection fault in
    gtp_genl_dump_pdp' bug: [ 1010.702740] gtp: GTP module unloaded [ 1010.715877] general protection fault,
    probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI [ 1010.715888] KASAN:
    null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 1010.715895] CPU: 1 PID: 128616 Comm:
    a.out Not tainted 6.8.0-rc6-std-def-alt1 #1 [ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9,
    2009), BIOS 1.16.0-alt1 04/01/2014 [ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.715915]
    Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00
    00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00 [
    1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203 [ 1010.715929] RAX: dffffc0000000000 RBX:
    ffff88800399c000 RCX: 0000000000000000 [ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI:
    0000000000000282 [ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000 [
    1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80 [ 1010.715947] R13:
    0000000000000000 R14: 0000000000000000 R15: 0000000000000400 [ 1010.715953] FS: 00007fd1509ab5c0(0000)
    GS:ffff88805b300000(0000) knlGS:0000000000000000 [ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0:
    0000000080050033 [ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0 [
    1010.715968] PKRU: 55555554 [ 1010.715972] Call Trace: [ 1010.715985] ? __die_body.cold+0x1a/0x1f [
    1010.715995] ? die_addr+0x43/0x70 [ 1010.716002] ? exc_general_protection+0x199/0x2f0 [ 1010.716016] ?
    asm_exc_general_protection+0x1e/0x30 [ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp] [ 1010.716034] ?
    gtp_net_exit+0x150/0x150 [gtp] [ 1010.716042] __rtnl_newlink+0x1063/0x1700 [ 1010.716051] ?
    rtnl_setlink+0x3c0/0x3c0 [ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0 [ 1010.716070] ?
    kernel_text_address.part.0+0xbb/0xd0 [ 1010.716076] ? __kernel_text_address+0x56/0xa0 [ 1010.716084] ?
    unwind_get_return_address+0x5a/0xa0 [ 1010.716091] ? create_prof_cpu_mask+0x30/0x30 [ 1010.716098] ?
    arch_stack_walk+0x9e/0xf0 [ 1010.716106] ? stack_trace_save+0x91/0xd0 [ 1010.716113] ?
    stack_trace_consume_entry+0x170/0x170 [ 1010.716121] ? __lock_acquire+0x15c5/0x5380 [ 1010.716139] ?
    mark_held_locks+0x9e/0xe0 [ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0 [ 1010.716155] ?
    __rtnl_newlink+0x1700/0x1700 [ 1010.716160] rtnl_newlink+0x69/0xa0 [ 1010.716166]
    rtnetlink_rcv_msg+0x43b/0xc50 [ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716179] ?
    lock_acquire+0x1fe/0x560 [ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50 [ 1010.716196]
    netlink_rcv_skb+0x14d/0x440 [ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0 [ 1010.716208] ?
    netlink_ack+0xab0/0xab0 [ 1010.716213] ? netlink_deliver_tap+0x202/0xd50 [ 1010.716220] ?
    netlink_deliver_tap+0x218/0xd50 [ 1010.716226] ? __virt_addr_valid+0x30b/0x590 [ 1010.716233]
    netlink_unicast+0x54b/0x800 [ 1010.716240] ? netlink_attachskb+0x870/0x870 [ 1010.716248] ?
    __check_object_size+0x2de/0x3b0 [ 1010.716254] netlink_sendmsg+0x938/0xe40 [ 1010.716261] ?
    netlink_unicast+0x800/0x800 [ 1010.716269] ? __import_iovec+0x292/0x510 [ 1010.716276] ?
    netlink_unicast+0x800/0x800 [ 1010.716284] __sock_sendmsg+0x159/0x190 [ 1010.716290]
    ____sys_sendmsg+0x712/0x880 [ 1010.716297] ? sock_write_iter+0x3d0/0x3d0 [ 1010.716304] ?
    __ia32_sys_recvmmsg+0x270/0x270 [ 1010.716309] ? lock_acquire+0x1fe/0x560 [ 1010.716315] ?
    drain_array_locked+0x90/0x90 [ 1010.716324] ___sys_sendmsg+0xf8/0x170 [ 1010.716331] ?
    sendmsg_copy_msghdr+0x170/0x170 [ 1010.716337] ? lockdep_init_map ---truncated--- (CVE-2024-26793)

  - In the Linux kernel, the following vulnerability has been resolved: netlink: Fix kernel-infoleak-after-
    free in __skb_datagram_iter syzbot reported the following uninit-value access issue [1]:
    netlink_to_full_skb() creates a new `skb` and puts the `skb->data` passed as a 1st arg of
    netlink_to_full_skb() onto new `skb`. The data size is specified as `len` and passed to skb_put_data().
    This `len` is based on `skb->end` that is not data offset but buffer offset. The `skb->end` contains data
    and tailroom. Since the tailroom is not initialized when the new `skb` created, KMSAN detects
    uninitialized memory area when copying the data. This patch resolved this issue by correct the len from
    `skb->end` to `skb->len`, which is the actual data offset. BUG: KMSAN: kernel-infoleak-after-free in
    instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak-after-free
    in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf
    include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2
    include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance
    include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520
    lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter
    lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2
    include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline]
    _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline]
    simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0
    net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg
    include/linux/skbuff.h:3960 [inline] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482
    sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline]
    sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [inline] new_sync_read
    fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0
    fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline]
    __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
    do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was
    stored to memory at: skb_put_data include/linux/skbuff.h:2622 [inline] netlink_to_full_skb
    net/netlink/af_netlink.c:181 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline]
    __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap
    net/netlink/af_netlink.c:338 [inline] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline]
    netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x10f1/0x1250
    net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
    sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline]
    ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg
    net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674
    [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52
    [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b
    Uninit was created at: free_pages_prepare mm/page_alloc.c:1087 [inline] free_unref_page_prepare+0xb0/0xa40
    mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410
    mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages ---truncated---
    (CVE-2024-26805)

  - In the Linux kernel, the following vulnerability has been resolved: x86, relocs: Ignore relocations in
    .notes section When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so
    that Xen can find the startup_xen entry point. This information is used prior to booting the kernel, so
    relocations are not useful. In fact, performing relocations against the .notes section means that the
    KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without
    breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in
    the .notes section. The values readable in .notes are then identical to those found in System.map.
    (CVE-2024-26816)

  - In the Linux kernel, the following vulnerability has been resolved: amdkfd: use calloc instead of kzalloc
    to avoid integer overflow This uses calloc instead of doing the multiplication which might overflow.
    (CVE-2024-26817)

  - In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix a memleak in
    init_credit_return When dma_alloc_coherent fails to allocate dd->cr_base[i].va, init_credit_return should
    deallocate dd->cr_base and dd->cr_base[i] that allocated before. Or those resources would be never freed
    and a memleak is triggered. (CVE-2024-26839)

  - In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix memory leak in
    cachefiles_add_cache() The following memory leak was reported after unbinding /dev/cachefiles:
    ================================================================== unreferenced object 0xffff9b674176e3c0
    (size 192): comm cachefilesd2, pid 680, jiffies 4294881224 hex dump (first 32 bytes): 01 00 00 00 00 00
    00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    ................ backtrace (crc ea38a44b): [<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370
    [<ffffffff8e917f86>] prepare_creds+0x26/0x2e0 [<ffffffffc002eeef>]
    cachefiles_determine_cache_security+0x1f/0x120 [<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0
    [<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0 [<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520
    [<ffffffff8ebc5069>] ksys_write+0x69/0xf0 [<ffffffff8f6d4662>] do_syscall_64+0x72/0x140
    [<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76
    ================================================================== Put the reference count of cache_cred
    in cachefiles_daemon_unbind() to fix the problem. And also put cache_cred in cachefiles_add_cache() error
    branch to avoid memory leaks. (CVE-2024-26840)

  - In the Linux kernel, the following vulnerability has been resolved: net/ipv6: avoid possible UAF in
    ip6_route_mpath_notify() syzbot found another use-after-free in ip6_route_mpath_notify() [1] Commit
    f7225172f25a (net/ipv6: prevent use after free in ip6_route_mpath_notify) was not able to fix the root
    cause. We need to defer the fib6_info_release() calls after ip6_route_mpath_notify(), in the cleanup
    phase. [1] BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0 Read of size 4 at addr
    ffff88809a07fc64 by task syz-executor.2/23037 CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted
    6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0 Hardware name: Google Google Compute Engine/Google Compute
    Engine, BIOS Google 01/25/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline]
    dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline]
    print_report+0x167/0x540 mm/kasan/report.c:488 kasan_report+0x142/0x180 mm/kasan/report.c:601
    rt6_fill_node+0x1460/0x1ac0 inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184 ip6_route_mpath_notify
    net/ipv6/route.c:5198 [inline] ip6_route_multipath_add net/ipv6/route.c:5404 [inline]
    inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040
    net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel
    net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
    netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline]
    __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg
    net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240
    entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f73dd87dda9 Code: 28 00 00 00 75 05 48 83 c4 28 c3
    e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0
    ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f73de6550c8 EFLAGS: 00000246
    ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9 RDX:
    0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005 RBP: 00007f73dd8ca47a R08: 0000000000000000
    R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13:
    000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858 </TASK> Allocated by task 23037:
    kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
    poison_kmalloc_redzone mm/kasan/common.c:372 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389
    kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3981 [inline]
    __kmalloc+0x22e/0x490 mm/slub.c:3994 kmalloc include/linux/slab.h:594 [inline] kzalloc
    include/linux/slab.h:711 [inline] fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155
    ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758 ip6_route_multipath_add net/ipv6/route.c:5298
    [inline] inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040
    net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel
    net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
    netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline]
    __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg
    net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240
    entry_SYSCALL_64_after_hwframe+0x6f/0x77 Freed by task 16: kasan_save_stack mm/kasan/common.c:47 [inline]
    kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640
    poison_slab_object+0xa6/0xe0 m ---truncated--- (CVE-2024-26852)

  - In the Linux kernel, the following vulnerability has been resolved: net: ice: Fix potential NULL pointer
    dereference in ice_bridge_setlink() The function ice_bridge_setlink() may encounter a NULL pointer
    dereference if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently in
    nla_for_each_nested(). To address this issue, add a check to ensure that br_spec is not NULL before
    proceeding with the nested attribute iteration. (CVE-2024-26855)

  - In the Linux kernel, the following vulnerability has been resolved: geneve: make sure to pull inner header
    in geneve_rx() syzbot triggered a bug in geneve_rx() [1] Issue is similar to the one I fixed in commit
    8d975c15c0cd (ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()) We have to save
    skb->network_header in a temporary variable in order to be able to recompute the network_header pointer
    after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head.
    [1] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-
    value in geneve_rx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in
    geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 IP_ECN_decapsulate include/net/inet_ecn.h:302
    [inline] geneve_rx drivers/net/geneve.c:279 [inline] geneve_udp_encap_recv+0x36f9/0x3c10
    drivers/net/geneve.c:391 udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108
    udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346
    __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604
    ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440
    net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490
    net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449
    [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569
    __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0
    net/core/dev.c:5648 process_backlog+0x480/0x8b0 net/core/dev.c:5976 __napi_poll+0xe3/0x980
    net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x8b8/0x1870 net/core/dev.c:6778
    __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553 do_softirq+0x9a/0xf0 kernel/softirq.c:454
    __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381 local_bh_enable include/linux/bottom_half.h:33
    [inline] rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline] __dev_queue_xmit+0x2768/0x51c0
    net/core/dev.c:4378 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0
    net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10
    net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745
    [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline]
    __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64
    arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
    entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook mm/slub.c:3819
    [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903
    kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x352/0x790 net/core/skbuff.c:651 alloc_skb
    include/linux/skbuff.h:1296 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394
    sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783 packet_alloc_skb net/packet/af_packet.c:2930
    [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x70c2/0x9f10
    net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745
    [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline]
    __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64
    arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
    entry_SYSCALL_64_after_hwframe+0x63/0x6b (CVE-2024-26857)

  - In the Linux kernel, the following vulnerability has been resolved: net/bnx2x: Prevent access to a freed
    page in page_pool Fix race condition leading to system crash during EEH error handling During EEH error
    recovery, the bnx2x driver's transmit timeout logic could cause a race condition when handling reset
    tasks. The bnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(), which ultimately leads to
    bnx2x_nic_unload(). In bnx2x_nic_unload() SGEs are freed using bnx2x_free_rx_sge_range(). However, this
    could overlap with the EEH driver's attempt to reset the device using bnx2x_io_slot_reset(), which also
    tries to free SGEs. This race condition can result in system crashes due to accessing freed memory
    locations in bnx2x_free_rx_sge() 799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp, 800 struct
    bnx2x_fastpath *fp, u16 index) 801 { 802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index]; 803 struct
    page *page = sw_buf->page; .... where sw_buf was set to NULL after the call to dma_unmap_page() by the
    preceding thread. EEH: Beginning: 'slot_reset' PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset()
    bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing... bnx2x 0011:01:00.0: enabling device
    (0140 -> 0142) bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload Kernel attempted to
    read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000
    Faulting instruction address: 0xc0080000025065fc Oops: Kernel access of bad area, sig: 11 [#1] ..... Call
    Trace: [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable)
    [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0 [c000000003c67b60] [c000000000052130]
    eeh_pe_report+0x180/0x550 [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60
    [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170 [c000000003c67da0] [c000000000194c58]
    kthread+0x1c8/0x1d0 [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64 To solve this
    issue, we need to verify page pool allocations before freeing. (CVE-2024-26859)

  - In the Linux kernel, the following vulnerability has been resolved: quota: Fix potential NULL pointer
    dereference Below race may cause NULL pointer dereference P1 P2 dquot_free_inode quota_off drop_dquot_ref
    remove_dquot_ref dquots = i_dquot(inode) dquots = i_dquot(inode) srcu_read_lock dquots[cnt]) != NULL (1)
    dquots[type] = NULL (2) spin_lock(&dquots[cnt]->dq_dqb_lock) (3) .... If dquot_free_inode(or other
    routines) checks inode's quota pointers (1) before quota_off sets it to NULL(2) and use it (3) after that,
    NULL pointer dereference will be triggered. So let's fix it by using a temporary pointer to avoid this
    issue. (CVE-2024-26878)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stackmap overflow check on
    32-bit arches The stackmap code relies on roundup_pow_of_two() to compute the number of hash buckets, and
    contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup
    code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined
    behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH
    type, which contains the same check, copied from the hashtab code. The commit in the fixes tag actually
    attempted to fix this, but the fix did not account for the UB, so the fix only works on CPUs where an
    overflow does result in a neat truncation to zero, which is not guaranteed. Checking the value before
    rounding does not have this problem. (CVE-2024-26883)

  - In the Linux kernel, the following vulnerability has been resolved: bpf: Fix hashtab overflow check on
    32-bit arches The hashtab code relies on roundup_pow_of_two() to compute the number of hash buckets, and
    contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup
    code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined
    behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH
    type, which contains the same check, copied from the hashtab code. So apply the same fix to hashtab, by
    moving the overflow check to before the roundup. (CVE-2024-26884)

  - In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free
    problem in aoecmd_cfg_pkts This patch is against CVE-2023-6270. The description of cve is: A flaw was
    found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly
    updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the
    free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of
    service condition or potential code execution. In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb
    initial code is finished. But the net_device ifp will still be used in later tx()->dev_queue_xmit() in
    kthread. Which means that the dev_put(ifp) should NOT be called in the success path of skb initial code in
    aoecmd_cfg_pkts(). Otherwise tx() may run into use-after-free because the net_device is freed. This patch
    removed the dev_put(ifp) in the success path in aoecmd_cfg_pkts(), and added dev_put() after skb xmit in
    tx(). (CVE-2024-26898)

  - In the Linux kernel, the following vulnerability has been resolved: do_sys_name_to_handle(): use kzalloc()
    to fix kernel-infoleak syzbot identified a kernel information leak vulnerability in
    do_sys_name_to_handle() and issued the following report [1]. [1] BUG: KMSAN: kernel-infoleak in
    instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in
    _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114
    [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline]
    do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
    __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140
    fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node
    mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node
    mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc
    include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline]
    __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10
    fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are
    uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address
    0000000020000240 Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem.
    (CVE-2024-26901)

  - In the Linux kernel, the following vulnerability has been resolved: Bluetooth: rfcomm: Fix null-ptr-deref
    in rfcomm_check_security During our fuzz testing of the connection and disconnection process at the RFCOMM
    layer, we discovered this bug. By comparing the packets from a normal connection and disconnection process
    with the testcase that triggered a KASAN report. We analyzed the cause of this bug as follows: 1. In the
    packets captured during a normal connection, the host sends a `Read Encryption Key Size` type of `HCI_CMD`
    packet (Command Opcode: 0x1408) to the controller to inquire the length of encryption key.After receiving
    this packet, the controller immediately replies with a Command Completepacket (Event Code: 0x0e) to return
    the Encryption Key Size. 2. In our fuzz test case, the timing of the controller's response to this packet
    was delayed to an unexpected point: after the RFCOMM and L2CAP layers had disconnected but before the HCI
    layer had disconnected. 3. After receiving the Encryption Key Size Response at the time described in point
    2, the host still called the rfcomm_check_security function. However, by this time `struct l2cap_conn
    *conn = l2cap_pi(sk)->chan->conn;` had already been released, and when the function executed `return
    hci_conn_security(conn->hcon, d->sec_level, auth_type, d->out);`, specifically when accessing
    `conn->hcon`, a null-ptr-deref error occurred. To fix this bug, check if `sk->sk_state` is BT_CLOSED
    before calling rfcomm_recv_frame in rfcomm_process_rx. (CVE-2024-26903)

  - In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix fortify source warning
    while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write
    (size 56) of single field eseg->inline_hdr.start at /var/lib/dkms/mlnx-ofed-
    kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at
    /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131
    mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE)
    rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE)
    mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4
    nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat
    nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE)
    vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user
    xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni
    polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer
    joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc
    drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded:
    mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware
    name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01
    00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01
    e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP:
    0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
    RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08:
    0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8
    R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000)
    GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000
    DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK>
    ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ?
    mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ?
    exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
    mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib]
    ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80
    sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ?
    _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib]
    neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0
    __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ?
    __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460
    ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60
    tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80
    sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90
    __x64_sys_write+0x19/0x30 do_syscall_ ---truncated--- (CVE-2024-26907)

  - In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: validate the parameters of
    bo mapping operations more clearly Verify the parameters of
    amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place. (CVE-2024-26922)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix double free of
    fcport The server was crashing after LOGO because fcport was getting freed twice. -----------[ cut here
    ]----------- kernel BUG at mm/slub.c:371! invalid opcode: 0000 1 SMP PTI CPU: 35 PID: 4610 Comm: bash
    Kdump: loaded Tainted: G OE --------- - - 4.18.0-425.3.1.el8.x86_64 #1 Hardware name: HPE ProLiant DL360
    Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021 RIP: 0010:set_freepointer.part.57+0x0/0x10 RSP:
    0018:ffffb07107027d90 EFLAGS: 00010246 RAX: ffff9cb7e3150000 RBX: ffff9cb7e332b9c0 RCX: ffff9cb7e3150400
    RDX: 0000000000001f37 RSI: 0000000000000000 RDI: ffff9cb7c0005500 RBP: fffff693448c5400 R08:
    0000000080000000 R09: 0000000000000009 R10: 0000000000000000 R11: 0000000000132af0 R12: ffff9cb7c0005500
    R13: ffff9cb7e3150000 R14: ffffffffc06990e0 R15: ffff9cb7ea85ea58 FS: 00007ff6b79c2740(0000)
    GS:ffff9cb8f7ec0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2:
    000055b426b7d700 CR3: 0000000169c18002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000
    DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554
    Call Trace: kfree+0x238/0x250 qla2x00_els_dcmd_sp_free+0x20/0x230 [qla2xxx] ?
    qla24xx_els_dcmd_iocb+0x607/0x690 [qla2xxx] qla2x00_issue_logo+0x28c/0x2a0 [qla2xxx] ?
    qla2x00_issue_logo+0x28c/0x2a0 [qla2xxx] ? kernfs_fop_write+0x11e/0x1a0 Remove one of the free calls and
    add check for valid fcport. Also use function qla2x00_free_fcport() instead of kfree(). (CVE-2024-26929)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix double free of the
    ha->vp_map pointer Coverity scan reported potential risk of double free of the pointer ha->vp_map.
    ha->vp_map was freed in qla2x00_mem_alloc(), and again freed in function qla2x00_mem_free(ha). Assign NULL
    to vp_map and kfree take care of NULL. (CVE-2024-26930)

  - In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix command flush on
    cable pull System crash due to command failed to flush back to SCSI layer. BUG: unable to handle kernel
    NULL pointer dereference at 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 27 PID: 793455
    Comm: kworker/u130:6 Kdump: loaded Tainted: G OE --------- - - 4.18.0-372.9.1.el8.x86_64 #1 Hardware name:
    HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021 Workqueue: nvme-wq
    nvme_fc_connect_ctrl_work [nvme_fc] RIP: 0010:__wake_up_common+0x4c/0x190 Code: 24 10 4d 85 c9 74 0a 41 f6
    01 04 0f 85 9d 00 00 00 48 8b 43 08 48 83 c3 08 4c 8d 48 e8 49 8d 41 18 48 39 c3 0f 84 f0 00 00 00 <49> 8b
    41 18 89 54 24 08 31 ed 4c 8d 70 e8 45 8b 29 41 f6 c5 04 75 RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086
    RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000 RDX: 0000000000000001 RSI:
    0000000000000003 RDI: ffff8b08d3b26320 RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8
    R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20 R13: 0000000000000003 R14:
    0000000000000000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8b2fdf6c0000(0000)
    knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3:
    0000002f1e410002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace:
    __wake_up_common_lock+0x7c/0xc0 qla_nvme_ls_req+0x355/0x4c0 [qla2xxx] qla2xxx [0000:12:00.1]-f084:3:
    qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae1407ca000 from port 21:32:00:02:ac:07:ee:b8
    loop_id 0x02 s_id 01:02:00 logout 1 keep 0 els_logo 0 ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc]
    qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST -
    portid=010200. ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc] qla2xxx [0000:12:00.1]-2109:3:
    qla2x00_schedule_rport_del 21320002ac07eeb8. rport ffff8ae598122000 roles 1 ?
    nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc] qla2xxx [0000:12:00.1]-f084:3:
    qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae14801e000 from port 21:32:01:02:ad:f7:ee:b8
    loop_id 0x04 s_id 01:02:01 logout 1 keep 0 els_logo 0 ? __switch_to+0x10c/0x450 ?
    process_one_work+0x1a7/0x360 qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:01:02:ad:f7:ee:b8 state
    transitioned from ONLINE to LOST - portid=010201. ? worker_thread+0x1ce/0x390 ? create_worker+0x1a0/0x1a0
    qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320102adf7eeb8. rport ffff8ae3b2312800 roles
    70 ? kthread+0x10a/0x120 qla2xxx [0000:12:00.1]-2112:3: qla_nvme_unregister_remote_port: unregister
    remoteport on ffff8ae14801e000 21320102adf7eeb8 ? set_kthread_struct+0x40/0x40 qla2xxx
    [0000:12:00.1]-2110:3: remoteport_delete of ffff8ae14801e000 21320102adf7eeb8 completed. ?
    ret_from_fork+0x1f/0x40 qla2xxx [0000:12:00.1]-f086:3: qlt_free_session_done: waiting for sess
    ffff8ae14801e000 logout The system was under memory stress where driver was not able to allocate an SRB to
    carry out error recovery of cable pull. The failure to flush causes upper layer to start modifying
    scsi_cmnd. When the system frees up some memory, the subsequent cable pull trigger another command flush.
    At this point the driver access a null pointer when attempting to DMA unmap the SGL. Add a check to make
    sure commands are flush back on session tear down to prevent the null pointer access. (CVE-2024-26931)

  - In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add a dc_state NULL
    check in dc_state_release [How] Check wheather state is NULL before releasing it. (CVE-2024-26948)

  - In the Linux kernel, the following vulnerability has been resolved: fs: sysfs: Fix reference leak in
    sysfs_break_active_protection() The sysfs_break_active_protection() routine has an obvious reference leak
    in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion
    sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by
    trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the
    start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when
    kn is NULL. (CVE-2024-26993)

  - In the Linux kernel, the following vulnerability has been resolved: tun: limit printing rate when illegal
    packet received by tun dev vhost_worker will call tun call backs to receive packets. If too many illegal
    packets arrives, tun_do_read will keep dumping packet contents. When console is enabled, it will costs
    much more cpu time to dump packet and soft lockup will be detected. net_ratelimit mechanism can be used to
    limit the dumping rate. PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: vhost-32980 #0
    [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 #1 [fffffe00003fce58] nmi_handle at
    ffffffff89225fa3 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e #3 [fffffe00003fced0] do_nmi at
    ffffffff8922660d #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20]
    RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0
    RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP:
    0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f
    R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX:
    ffffffffffffffff CS: 0010 SS: 0018 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594 #6
    [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 #7 [ffffa65531497a08] serial8250_console_putchar at
    ffffffff897934f6 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 #9 [ffffa65531497a48]
    serial8250_console_write at ffffffff89796558 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124 #11
    [ffffa65531497b10] vprintk_emit at ffffffff89317c07 #12 [ffffa65531497b68] printk at ffffffff89318306 #13
    [ffffa65531497bc8] print_hex_dump at ffffffff89650765 #14 [ffffa65531497ca8] tun_do_read at
    ffffffffc0b06c27 [tun] #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] #16 [ffffa65531497d68]
    handle_rx at ffffffffc0c5d682 [vhost_net] #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost]
    #18 [ffffa65531497f10] kthread at ffffffff892d2e72 #19 [ffffa65531497f50] ret_from_fork at
    ffffffff89c0022f (CVE-2024-27013)

  - In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Prevent deadlock while
    disabling aRFS When disabling aRFS under the `priv->state_lock`, any scheduled aRFS works are canceled
    using the `cancel_work_sync` function, which waits for the work to end if it has already started. However,
    while waiting for the work handler, the handler will try to acquire the `state_lock` which is already
    acquired. The worker acquires the lock to delete the rules if the state is down, which is not the worker's
    responsibility since disabling aRFS deletes the rules. Add an aRFS state variable, which indicates whether
    the aRFS is enabled and prevent adding rules when the aRFS is disabled. Kernel log:
    ====================================================== WARNING: possible circular locking dependency
    detected 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I
    ------------------------------------------------------ ethtool/386089 is trying to acquire lock:
    ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0 but task
    is already holding lock: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at:
    mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core] which lock already depends on the new lock. the existing
    dependency chain (in reverse order) is: -> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90
    arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0
    kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 -> #0
    ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0
    __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core]
    mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
    ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120
    genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270
    netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30
    do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4e other info that might help us debug this:
    Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&priv->state_lock);
    lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock);
    lock((work_completion)(&rule->arfs_work)); *** DEADLOCK *** 3 locks held by ethtool/386089: #0:
    ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88
    (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0
    (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core] stack backtrace:
    CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Hardware name: QEMU
    Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace:
    <TASK> dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80
    lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0
    __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0
    ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70
    arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
    mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0
    ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn
    ---truncated--- (CVE-2024-27014)

  - In the Linux kernel, the following vulnerability has been resolved: media: edia: dvbdev: fix a use-after-
    free In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed in several error-handling
    paths. However, *pdvbdev is not set to NULL after dvbdev's deallocation, causing use-after-frees in many
    places, for example, in the following call chain: budget_register |-> dvb_dmxdev_init |->
    dvb_register_device |-> dvb_dmxdev_release |-> dvb_unregister_device |-> dvb_remove_device |->
    dvb_device_put |-> kref_put When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in
    dvb_register_device) could point to memory that had been freed in dvb_register_device. Thereafter, this
    pointer is transferred to kref_put and triggering a use-after-free. (CVE-2024-27043)

  - In the Linux kernel, the following vulnerability has been resolved: nfp: flower: handle acti_netdevs
    allocation failure The kmalloc_array() in nfp_fl_lag_do_work() will return null, if the physical memory
    has run out. As a result, if we dereference the acti_netdevs, the null pointer dereference bugs will
    happen. This patch adds a check to judge whether allocation failure occurs. If it happens, the delayed
    work will be rescheduled and try again. (CVE-2024-27046)

  - In the Linux kernel, the following vulnerability has been resolved: s390/dasd: fix double module refcount
    decrement Once the discipline is associated with the device, deleting the device takes care of
    decrementing the module's refcount. Doing it manually on this error path causes refcount to artificially
    decrease on each error while it should just stay the same. (CVE-2024-27054)

  - In the Linux kernel, the following vulnerability has been resolved: media: usbtv: Remove useless locks in
    usbtv_video_free() Remove locks calls in usbtv_video_free() because are useless and may led to a deadlock
    as reported here: https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000 Also remove usbtv_stop()
    call since it will be called when unregistering the device. Before 'c838530d230b' this issue would only be
    noticed if you disconnect while streaming and now it is noticeable even when disconnecting while not
    streaming. [hverkuil: fix minor spelling mistake in log message] (CVE-2024-27072)

  - In the Linux kernel, the following vulnerability has been resolved: media: ttpci: fix two memleaks in
    budget_av_attach When saa7146_register_device and saa7146_vv_init fails, budget_av_attach should free the
    resources it allocates, like the error-handling of ttpci_budget_init does. Besides, there are two fixme
    comment refers to such deallocations. (CVE-2024-27073)

  - In the Linux kernel, the following vulnerability has been resolved: media: go7007: fix a memleak in
    go7007_load_encoder In go7007_load_encoder, bounce(i.e. go->boot_fw), is allocated without a deallocation
    thereafter. After the following call chain: saa7134_go7007_init |-> go7007_boot_encoder |->
    go7007_load_encoder |-> kfree(go) go is freed and thus bounce is leaked. (CVE-2024-27074)

  - In the Linux kernel, the following vulnerability has been resolved: media: dvb-frontends: avoid stack
    overflow warnings with clang A previous patch worked around a KASAN issue in stv0367, now a similar
    problem showed up with clang: drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size
    (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than] 1214 | static int
    stv0367ter_set_frontend(struct dvb_frontend *fe) Rework the stv0367_writereg() function to be simpler and
    mark both register access functions as noinline_for_stack so the temporary i2c_msg structures do not get
    duplicated on the stack when KASAN_STACK is enabled. (CVE-2024-27075)

  - In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: fix some memleaks in
    tpg_alloc In tpg_alloc, resources should be deallocated in each and every error-handling paths, since they
    are allocated in for statements. Otherwise there would be memleaks because tpg_free is called only when
    tpg_alloc return 0. (CVE-2024-27078)

  - In the Linux kernel, the following vulnerability has been resolved: SUNRPC: fix some memleaks in
    gssx_dec_option_array The creds and oa->data need to be freed in the error-handling paths after their
    allocation. So this patch add these deallocations in the corresponding paths. (CVE-2024-27388)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version
number.");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1084332");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1141539");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1184509");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1186060");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1190317");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1190576");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1192145");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1194516");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1203935");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1209657");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1211592");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1212514");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1213456");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1217339");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1217987");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1217988");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1217989");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1218220");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1218336");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1218479");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1218562");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219104");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219169");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219170");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219618");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219623");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1219847");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220320");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220366");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220394");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220411");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220416");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220418");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220422");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220442");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220445");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220505");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220521");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220528");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220536");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220538");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220554");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220572");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220580");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220611");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220625");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220628");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220637");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220640");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220662");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220687");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220692");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220703");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220706");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220739");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220742");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220743");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220745");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220751");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220768");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220769");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220777");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220790");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220794");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220829");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220836");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220843");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220846");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220850");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220871");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220927");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220960");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220985");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1220987");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221044");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221046");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221048");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221058");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221060");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221061");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221077");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221082");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221088");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221162");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221277");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221293");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221337");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221532");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221541");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221548");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221575");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221605");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221608");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221617");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221791");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221816");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221825");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221830");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221862");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221934");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221949");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221952");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221953");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221965");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221966");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221967");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221969");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221972");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221973");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221977");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221979");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221988");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221991");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221993");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221994");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221997");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221998");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1221999");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222000");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222001");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222002");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222117");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222294");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222300");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222357");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222379");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222422");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222428");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222449");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222503");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222559");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222585");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222609");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222610");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222613");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222618");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222619");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222624");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222630");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222632");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222660");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222662");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222664");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222666");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222669");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222671");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222677");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222706");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222720");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222765");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222770");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222772");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222787");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222790");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222812");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222836");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222869");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222876");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222878");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222881");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222883");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222888");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222952");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222961");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222975");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1222976");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223016");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223035");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223049");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223051");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223057");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223058");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223060");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223187");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223189");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223198");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223203");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223315");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223432");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223509");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223512");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223513");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223516");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223518");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223626");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223627");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223664");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223686");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223693");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223712");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223715");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223735");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223744");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223745");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223770");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223781");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223819");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223824");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223827");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223837");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223842");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223843");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223844");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223883");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223885");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223921");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223941");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223952");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223953");
  script_set_attribute(attribute:"see_also", value:"https://bugzilla.suse.com/1223954");
  script_set_attribute(attribute:"see_also", value:"https://lists.suse.com/pipermail/sle-updates/2024-May/035259.html");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2019-25160");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2020-36312");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-23134");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46904");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46905");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46907");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46909");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46938");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46939");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46941");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46950");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46958");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46960");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46963");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46964");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46966");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46975");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46981");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46988");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46990");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-46998");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47006");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47015");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47024");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47034");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47045");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47049");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47055");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47056");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47060");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47061");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47063");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47068");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47070");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47071");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47073");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47100");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47101");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47104");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47110");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47112");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47114");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47117");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47118");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47119");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47138");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47141");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47142");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47143");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47146");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47149");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47150");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47153");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47159");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47161");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47162");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47165");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47166");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47167");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47168");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47169");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47171");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47173");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47177");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47179");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47180");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47181");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47182");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47183");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47184");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47185");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47188");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47189");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47198");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47202");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47203");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47204");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47205");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47207");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47211");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47216");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2021-47217");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-0487");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-48619");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-48626");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-48636");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-48650");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-48651");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-48667");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-48668");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-48687");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-48688");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-48695");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2022-48701");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-0160");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-28746");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-35827");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52454");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52469");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52470");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52474");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52476");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52477");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52486");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52488");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52509");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52515");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52524");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52528");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52575");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52583");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52587");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52590");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52591");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52595");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52598");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52607");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52614");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52620");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52628");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52635");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52639");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52644");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52646");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52650");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52652");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-52653");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-6270");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-6356");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-6535");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-6536");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-7042");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2023-7192");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-2201");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-22099");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-23307");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-23848");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-24855");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-24861");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26614");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26642");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26651");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26671");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26675");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26689");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26704");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26733");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26739");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26743");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26744");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26747");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26754");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26763");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26771");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26772");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26773");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26777");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26778");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26779");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26793");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26805");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26816");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26817");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26839");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26840");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26852");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26855");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26857");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26859");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26878");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26883");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26884");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26898");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26901");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26903");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26907");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26922");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26929");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26930");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26931");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26948");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-26993");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-27013");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-27014");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-27043");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-27046");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-27054");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-27072");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-27073");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-27074");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-27075");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-27078");
  script_set_attribute(attribute:"see_also", value:"https://www.suse.com/security/cve/CVE-2024-27388");
  script_set_attribute(attribute:"solution", value:
"Update the affected packages.");
  script_set_cvss_base_vector("CVSS2#AV:L/AC:L/Au:N/C:P/I:P/A:P");
  script_set_cvss_temporal_vector("CVSS2#E:POC/RL:OF/RC:C");
  script_set_cvss3_base_vector("CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H");
  script_set_cvss3_temporal_vector("CVSS:3.0/E:P/RL:O/RC:C");
  script_set_attribute(attribute:"cvss_score_source", value:"CVE-2021-23134");
  script_set_attribute(attribute:"cvss3_score_source", value:"CVE-2024-26930");

  script_set_attribute(attribute:"exploitability_ease", value:"Exploits are available");
  script_set_attribute(attribute:"exploit_available", value:"true");

  script_set_attribute(attribute:"vuln_publication_date", value:"2021/04/07");
  script_set_attribute(attribute:"patch_publication_date", value:"2024/05/14");
  script_set_attribute(attribute:"plugin_publication_date", value:"2024/05/15");

  script_set_attribute(attribute:"plugin_type", value:"local");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:cluster-md-kmp-default");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:dlm-kmp-default");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:gfs2-kmp-default");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-default");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-default-base");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-default-devel");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-default-extra");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-default-kgraft");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-default-kgraft-devel");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-default-man");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-devel");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-macros");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-obs-build");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-source");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kernel-syms");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:kgraft-patch-4_12_14-122_212-default");
  script_set_attribute(attribute:"cpe", value:"p-cpe:/a:novell:suse_linux:ocfs2-kmp-default");
  script_set_attribute(attribute:"cpe", value:"cpe:/o:novell:suse_linux:12");
  script_set_attribute(attribute:"generated_plugin", value:"current");
  script_end_attributes();

  script_category(ACT_GATHER_INFO);
  script_family(english:"SuSE Local Security Checks");

  script_copyright(english:"This script is Copyright (C) 2024 and is owned by Tenable, Inc. or an Affiliate thereof.");

  script_dependencies("ssh_get_info.nasl");
  script_require_keys("Host/local_checks_enabled", "Host/cpu", "Host/SuSE/release", "Host/SuSE/rpm-list");

  exit(0);
}


include('rpm.inc');

if (!get_kb_item('Host/local_checks_enabled')) audit(AUDIT_LOCAL_CHECKS_NOT_ENABLED);
var os_release = get_kb_item("Host/SuSE/release");
if (isnull(os_release) || os_release !~ "^(SLED|SLES)") audit(AUDIT_OS_NOT, "SUSE");
var os_ver = pregmatch(pattern: "^(SLE(S|D)(?:_SAP)?\d+)", string:os_release);
if (isnull(os_ver)) audit(AUDIT_UNKNOWN_APP_VER, 'SUSE');
os_ver = os_ver[1];
if (! preg(pattern:"^(SLED12|SLED_SAP12|SLES12|SLES_SAP12)$", string:os_ver)) audit(AUDIT_OS_NOT, 'SUSE SLED12 / SLED_SAP12 / SLES12 / SLES_SAP12', 'SUSE (' + os_ver + ')');

if (!get_kb_item("Host/SuSE/rpm-list")) audit(AUDIT_PACKAGE_LIST_MISSING);

var cpu = get_kb_item('Host/cpu');
if (isnull(cpu)) audit(AUDIT_UNKNOWN_ARCH);
if ('x86_64' >!< cpu && cpu !~ "^i[3-6]86$" && 's390' >!< cpu && 'aarch64' >!< cpu) audit(AUDIT_LOCAL_CHECKS_NOT_IMPLEMENTED, 'SUSE (' + os_ver + ')', cpu);

var service_pack = get_kb_item("Host/SuSE/patchlevel");
if (isnull(service_pack)) service_pack = "0";
if (os_ver == "SLED12" && (! preg(pattern:"^(5)$", string:service_pack))) audit(AUDIT_OS_NOT, "SLED12 SP5", os_ver + " SP" + service_pack);
if (os_ver == "SLED_SAP12" && (! preg(pattern:"^(5)$", string:service_pack))) audit(AUDIT_OS_NOT, "SLED_SAP12 SP5", os_ver + " SP" + service_pack);
if (os_ver == "SLES12" && (! preg(pattern:"^(5)$", string:service_pack))) audit(AUDIT_OS_NOT, "SLES12 SP5", os_ver + " SP" + service_pack);
if (os_ver == "SLES_SAP12" && (! preg(pattern:"^(5)$", string:service_pack))) audit(AUDIT_OS_NOT, "SLES_SAP12 SP5", os_ver + " SP" + service_pack);

var pkgs = [
    {'reference':'kernel-default-4.12.14-122.212.1', 'sp':'5', 'release':'SLES_SAP12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-12.5']},
    {'reference':'kernel-default-base-4.12.14-122.212.1', 'sp':'5', 'release':'SLES_SAP12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-12.5']},
    {'reference':'kernel-default-devel-4.12.14-122.212.1', 'sp':'5', 'release':'SLES_SAP12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-12.5']},
    {'reference':'kernel-default-extra-4.12.14-122.212.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLED_SAP12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-12.5']},
    {'reference':'kernel-default-extra-4.12.14-122.212.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES_SAP12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-12.5']},
    {'reference':'kernel-default-man-4.12.14-122.212.1', 'sp':'5', 'cpu':'s390x', 'release':'SLES_SAP12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-12.5']},
    {'reference':'kernel-devel-4.12.14-122.212.1', 'sp':'5', 'release':'SLES_SAP12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-12.5']},
    {'reference':'kernel-macros-4.12.14-122.212.1', 'sp':'5', 'release':'SLES_SAP12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-12.5']},
    {'reference':'kernel-obs-build-4.12.14-122.212.1', 'sp':'5', 'release':'SLES_SAP12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-12.5']},
    {'reference':'kernel-source-4.12.14-122.212.1', 'sp':'5', 'release':'SLES_SAP12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-12.5']},
    {'reference':'kernel-syms-4.12.14-122.212.1', 'sp':'5', 'release':'SLES_SAP12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['SLES_SAP-release-12.5']},
    {'reference':'cluster-md-kmp-default-4.12.14-122.212.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-ha-release-12.5']},
    {'reference':'dlm-kmp-default-4.12.14-122.212.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-ha-release-12.5']},
    {'reference':'gfs2-kmp-default-4.12.14-122.212.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-ha-release-12.5']},
    {'reference':'ocfs2-kmp-default-4.12.14-122.212.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-ha-release-12.5']},
    {'reference':'kernel-default-kgraft-4.12.14-122.212.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-live-patching-release-12.5']},
    {'reference':'kernel-default-kgraft-devel-4.12.14-122.212.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-live-patching-release-12.5']},
    {'reference':'kgraft-patch-4_12_14-122_212-default-1-8.11.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-live-patching-release-12.5']},
    {'reference':'kernel-obs-build-4.12.14-122.212.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-sdk-release-12.5', 'sles-release-12.5']},
    {'reference':'kernel-default-extra-4.12.14-122.212.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLED12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-we-release-12.5', 'sles-release-12.5']},
    {'reference':'kernel-default-extra-4.12.14-122.212.1', 'sp':'5', 'cpu':'x86_64', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sle-we-release-12.5', 'sles-release-12.5']},
    {'reference':'kernel-default-4.12.14-122.212.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sles-release-12.5']},
    {'reference':'kernel-default-base-4.12.14-122.212.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sles-release-12.5']},
    {'reference':'kernel-default-devel-4.12.14-122.212.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sles-release-12.5']},
    {'reference':'kernel-default-man-4.12.14-122.212.1', 'sp':'5', 'cpu':'s390x', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sles-release-12.5']},
    {'reference':'kernel-devel-4.12.14-122.212.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sles-release-12.5']},
    {'reference':'kernel-macros-4.12.14-122.212.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sles-release-12.5']},
    {'reference':'kernel-source-4.12.14-122.212.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sles-release-12.5']},
    {'reference':'kernel-syms-4.12.14-122.212.1', 'sp':'5', 'release':'SLES12', 'rpm_spec_vers_cmp':TRUE, 'exists_check':['sles-release-12.5']}
];

var ltss_caveat_required = FALSE;
var flag = 0;
foreach var package_array ( pkgs ) {
  var reference = NULL;
  var _release = NULL;
  var sp = NULL;
  var _cpu = NULL;
  var exists_check = NULL;
  var rpm_spec_vers_cmp = NULL;
  if (!empty_or_null(package_array['reference'])) reference = package_array['reference'];
  if (!empty_or_null(package_array['release'])) _release = package_array['release'];
  if (!empty_or_null(package_array['sp'])) sp = package_array['sp'];
  if (!empty_or_null(package_array['cpu'])) _cpu = package_array['cpu'];
  if (!empty_or_null(package_array['exists_check'])) exists_check = package_array['exists_check'];
  if (!empty_or_null(package_array['rpm_spec_vers_cmp'])) rpm_spec_vers_cmp = package_array['rpm_spec_vers_cmp'];
  if (reference && _release) {
    if (exists_check) {
      var check_flag = 0;
      foreach var check (exists_check) {
        if (!rpm_exists(release:_release, rpm:check)) continue;
        check_flag++;
      }
      if (!check_flag) continue;
    }
    if (rpm_check(release:_release, sp:sp, cpu:_cpu, reference:reference, rpm_spec_vers_cmp:rpm_spec_vers_cmp)) flag++;
  }
}

if (flag)
{
  security_report_v4(
      port       : 0,
      severity   : SECURITY_WARNING,
      extra      : rpm_report_get()
  );
  exit(0);
}
else
{
  var tested = pkg_tests_get();
  if (tested) audit(AUDIT_PACKAGE_NOT_AFFECTED, tested);
  else audit(AUDIT_PACKAGE_NOT_INSTALLED, 'cluster-md-kmp-default / dlm-kmp-default / gfs2-kmp-default / etc');
}