[000/190] Revertion of all of the umn.edu commits
mbox series

Message ID 20210421130105.1226686-1-gregkh@linuxfoundation.org
Headers show
Series
  • Revertion of all of the umn.edu commits
Related show

Message

Greg KH April 21, 2021, 12:57 p.m. UTC
I have been meaning to do this for a while, but recent events have
finally forced me to do so.

Commits from @umn.edu addresses have been found to be submitted in "bad
faith" to try to test the kernel community's ability to review "known
malicious" changes.  The result of these submissions can be found in a
paper published at the 42nd IEEE Symposium on Security and Privacy
entitled, "Open Source Insecurity: Stealthily Introducing
Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
of Minnesota) and Kangjie Lu (University of Minnesota).

Because of this, all submissions from this group must be reverted from
the kernel tree and will need to be re-reviewed again to determine if
they actually are a valid fix.  Until that work is complete, remove this
change to ensure that no problems are being introduced into the
codebase.

This patchset has the "easy" reverts, there are 68 remaining ones that
need to be manually reviewed.  Some of them are not able to be reverted
as they already have been reverted, or fixed up with follow-on patches
as they were determined to be invalid.  Proof that these submissions
were almost universally wrong.

I will be working with some other kernel developers to determine if any
of these reverts were actually valid changes, were actually valid, and
if so, will resubmit them properly later.  For now, it's better to be
safe.

I'll take this through my tree, so no need for any maintainer to worry
about this, but they should be aware that future submissions from anyone
with a umn.edu address should be by default-rejected unless otherwise
determined to actually be a valid fix (i.e. they provide proof and you
can verify it, but really, why waste your time doing that extra work?)

thanks,

greg k-h

Greg Kroah-Hartman (190):
  Revert "net/rds: Avoid potential use after free in
    rds_send_remove_from_sock"
  Revert "media: st-delta: Fix reference count leak in delta_run_work"
  Revert "media: sti: Fix reference count leaks"
  Revert "media: exynos4-is: Fix several reference count leaks due to
    pm_runtime_get_sync"
  Revert "media: exynos4-is: Fix a reference count leak due to
    pm_runtime_get_sync"
  Revert "media: exynos4-is: Fix a reference count leak"
  Revert "media: ti-vpe: Fix a missing check and reference count leak"
  Revert "media: stm32-dcmi: Fix a reference count leak"
  Revert "media: s5p-mfc: Fix a reference count leak"
  Revert "media: camss: Fix a reference count leak."
  Revert "media: platform: fcp: Fix a reference count leak."
  Revert "media: rockchip/rga: Fix a reference count leak."
  Revert "media: rcar-vin: Fix a reference count leak."
  Revert "media: rcar-vin: Fix a reference count leak."
  Revert "firmware: Fix a reference count leak."
  Revert "drm/nouveau: fix reference count leak in
    nouveau_debugfs_strap_peek"
  Revert "drm/nouveau: fix reference count leak in
    nv50_disp_atomic_commit"
  Revert "drm/nouveau: fix multiple instances of reference count leaks"
  Revert "drm/nouveau/drm/noveau: fix reference count leak in
    nouveau_fbcon_open"
  Revert "PCI: Fix pci_create_slot() reference count leak"
  Revert "omapfb: fix multiple reference count leaks due to
    pm_runtime_get_sync"
  Revert "drm/radeon: Fix reference count leaks caused by
    pm_runtime_get_sync"
  Revert "drm/radeon: fix multiple reference count leak"
  Revert "drm/amdkfd: Fix reference count leaks."
  Revert "platform/chrome: cros_ec_ishtp: Fix a double-unlock issue"
  Revert "usb: dwc3: pci: Fix reference count leak in
    dwc3_pci_resume_work"
  Revert "ASoC: rockchip: Fix a reference count leak."
  Revert "RDMA/rvt: Fix potential memory leak caused by rvt_alloc_rq"
  Revert "EDAC: Fix reference count leaks"
  Revert "ASoC: tegra: Fix reference count leaks."
  Revert "test_objagg: Fix potential memory leak in error handling"
  Revert "ASoC: img-parallel-out: Fix a reference count leak"
  Revert "ASoC: img: Fix a reference count leak in img_i2s_in_set_fmt"
  Revert "efi/esrt: Fix reference count leak in
    esre_create_sysfs_entry."
  Revert "scsi: iscsi: Fix reference count leak in
    iscsi_boot_create_kobj"
  Revert "vfio/mdev: Fix reference count leak in
    add_mdev_supported_type"
  Revert "RDMA/core: Fix several reference count leaks."
  Revert "cpuidle: Fix three reference count leaks"
  Revert "iommu: Fix reference count leak in iommu_group_alloc."
  Revert "ACPI: CPPC: Fix reference count leak in
    acpi_cppc_processor_probe()"
  Revert "ACPI: sysfs: Fix reference count leak in
    acpi_sysfs_add_hotplug_profile()"
  Revert "ASoC: fix incomplete error-handling in img_i2s_in_probe."
  Revert "qlcnic: fix missing release in qlcnic_83xx_interrupt_test."
  Revert "RDMA/pvrdma: Fix missing pci disable in pvrdma_pci_probe()"
  Revert "usb: gadget: fix potential double-free in m66592_probe."
  Revert "net/mlx4_core: fix a memory leak bug."
  Revert "rxrpc: Fix a memory leak in rxkad_verify_response()"
  Revert "net: sun: fix missing release regions in cas_init_one()."
  Revert "agp/intel: Fix a memory leak on module initialisation failure"
  Revert "nfp: abm: fix a memory leak bug"
  Revert "power: supply: core: fix memory leak in HWMON error path"
  Revert "media: media/saa7146: fix incorrect assertion in
    saa7146_buffer_finish"
  Revert "ecryptfs: replace BUG_ON with error handling code"
  Revert "clk: samsung: Remove redundant check in
    samsung_cmu_register_one"
  Revert "fs: ocfs: remove unnecessary assertion in dlm_migrate_lockres"
  Revert "media: davinci/vpfe_capture.c: Avoid BUG_ON for register
    failure"
  Revert "media: saa7146: Avoid using BUG_ON as an assertion"
  Revert "media: cx231xx: replace BUG_ON with recovery code"
  Revert "RDMA/srpt: Remove unnecessary assertion in
    srpt_queue_response"
  Revert "staging: kpc2000: remove unnecessary assertions in
    kpc_dma_transfer"
  Revert "xen/grant-table: remove multiple BUG_ON on gnttab_interface"
  Revert "scsi: libfc: remove unnecessary assertion on ep variable"
  Revert "hdlcdrv: replace unnecessary assertion in hdlcdrv_register"
  Revert "nfc: s3fwrn5: replace the assertion with a WARN_ON"
  Revert "nfsd: remove unnecessary assertion in nfsd4_encode_replay"
  Revert "bpf: Remove unnecessary assertion on fp_old"
  Revert "net: caif: replace BUG_ON with recovery code"
  Revert "fore200e: Fix incorrect checks of NULL pointer dereference"
  Revert "mac80211: Remove redundant assertion"
  Revert "rfkill: Fix incorrect check to avoid NULL pointer dereference"
  Revert "pppoe: remove redundant BUG_ON() check in pppoe_pernet"
  Revert "net: atm: Reduce the severity of logging in unlink_clip_vcc"
  Revert "media: rcar_drif: fix a memory disclosure"
  Revert "drm/gma500: fix memory disclosures due to uninitialized bytes"
  Revert "gma/gma500: fix a memory disclosure bug due to uninitialized
    bytes"
  Revert "net: ixgbevf: fix a missing check of
    ixgbevf_write_msg_read_ack"
  Revert "rapidio: fix a NULL pointer dereference when
    create_workqueue() fails"
  Revert "ASoC: cs43130: fix a NULL pointer dereference"
  Revert "ASoC: rt5645: fix a NULL pointer dereference"
  Revert "ALSA: usx2y: fix a double free bug"
  Revert "tracing: Fix a memory leak by early error exit in
    trace_pid_write()"
  Revert "rsi: Fix NULL pointer dereference in kmalloc"
  Revert "net: cw1200: fix a NULL pointer dereference"
  Revert "net: ieee802154: fix missing checks for regmap_update_bits"
  Revert "audit: fix a memory leak bug"
  Revert "x86/PCI: Fix PCI IRQ routing table memory leak"
  Revert "udf: fix an uninitialized read bug and remove dead code"
  Revert "mmc_spi: add a status check for spi_sync_locked"
  Revert "PCI: endpoint: Fix a potential NULL pointer dereference"
  Revert "net/smc: fix a NULL pointer dereference"
  Revert "pinctrl: axp209: Fix NULL pointer dereference after
    allocation"
  Revert "power: charger-manager: fix a potential NULL pointer
    dereference"
  Revert "iio: hmc5843: fix potential NULL pointer dereferences"
  Revert "iio: adc: fix a potential NULL pointer dereference"
  Revert "rtlwifi: fix a potential NULL pointer dereference"
  Revert "net: mwifiex: fix a NULL pointer dereference"
  Revert "video: imsttfb: fix potential NULL pointer dereferences"
  Revert "video: hgafb: fix potential NULL pointer dereference"
  Revert "omapfb: Fix potential NULL pointer dereference in kmalloc"
  Revert "staging: greybus: audio_manager: fix a missing check of
    ida_simple_get"
  Revert "PCI: xilinx: Check for __get_free_pages() failure"
  Revert "media: video-mux: fix null pointer dereferences"
  Revert "thunderbolt: property: Fix a missing check of kzalloc"
  Revert "char: hpet: fix a missing check of ioremap"
  Revert "libnvdimm/btt: Fix a kmemdup failure check"
  Revert "tty: ipwireless: fix missing checks for ioremap"
  Revert "RDMA/i40iw: Handle workqueue allocation failure"
  Revert "usb: u132-hcd: fix potential NULL pointer dereference"
  Revert "usb: sierra: fix a missing check of device_create_file"
  Revert "scsi: qla4xxx: fix a potential NULL pointer dereference"
  Revert "gpio: aspeed: fix a potential NULL pointer dereference"
  Revert "libnvdimm/namespace: Fix a potential NULL pointer dereference"
  Revert "x86/hpet: Prevent potential NULL pointer dereference"
  Revert "staging: rtl8188eu: Fix potential NULL pointer dereference of
    kcalloc"
  Revert "thunderbolt: Fix a missing check of kmemdup"
  Revert "thunderbolt: property: Fix a NULL pointer dereference"
  Revert "media: si2165: fix a missing check of return value"
  Revert "scsi: ufs: fix a missing check of devm_reset_control_get"
  Revert "tty: mxs-auart: fix a potential NULL pointer dereference"
  Revert "tty: atmel_serial: fix a potential NULL pointer dereference"
  Revert "serial: mvebu-uart: Fix to avoid a potential NULL pointer
    dereference"
  Revert "HID: logitech: check the return value of
    create_singlethread_workqueue"
  Revert "netfilter: ip6t_srh: fix NULL pointer dereferences"
  Revert "spi : spi-topcliff-pch: Fix to handle empty DMA buffers"
  Revert "net: tipc: fix a missing check of nla_nest_start"
  Revert "net: openvswitch: fix a NULL pointer dereference"
  Revert "ALSA: sb8: add a check for request_region"
  Revert "net: strparser: fix a missing check for
    create_singlethread_workqueue"
  Revert "qlcnic: Avoid potential NULL pointer dereference"
  Revert "ALSA: usx2y: Fix potential NULL pointer dereference"
  Revert "net: 8390: fix potential NULL pointer dereferences"
  Revert "net: fujitsu: fix a potential NULL pointer dereference"
  Revert "net: qlogic: fix a potential NULL pointer dereference"
  Revert "md: Fix failed allocation of md_register_thread"
  Revert "net: rocker: fix a potential NULL pointer dereference"
  Revert "net: thunder: fix a potential NULL pointer dereference"
  Revert "net: lio_core: fix two NULL pointer dereferences"
  Revert "net: liquidio: fix a NULL pointer dereference"
  Revert "isdn: mISDNinfineon: fix potential NULL pointer dereference"
  Revert "isdn: mISDN: Fix potential NULL pointer dereference of
    kzalloc"
  Revert "libertas: add checks for the return value of
    sysfs_create_group"
  Revert "rtc: hym8563: fix a missing check of block data read"
  Revert "power: twl4030: fix a missing check of return value"
  Revert "misc/ics932s401: Add a missing check to
    i2c_smbus_read_word_data"
  Revert "leds: lp5523: fix a missing check of return value of
    lp55xx_read"
  Revert "media: dvb: Add check on sp8870_readreg"
  Revert "media: dvb: add return value check on Write16"
  Revert "media: mt312: fix a missing check of mt312 reset"
  Revert "media: lgdt3306a: fix a missing check of return value"
  Revert "media: gspca: mt9m111: Check write_bridge for timeout"
  Revert "media: gspca: Check the return value of write_bridge for
    timeout"
  Revert "media: usb: gspca: add a missed check for goto_low_power"
  Revert "media: usb: gspca: add a missed return-value check for
    do_command"
  Revert "ath6kl: return error code in ath6kl_wmi_set_roam_lrssi_cmd()"
  Revert "brcmfmac: add a check for the status of usb_register"
  Revert "serial: max310x: pass return value of spi_register_driver"
  Revert "Input: ad7879 - add check for read errors in interrupt"
  Revert "ALSA: sb: fix a missing check of snd_ctl_add"
  Revert "ALSA: gus: add a check of the status of snd_ctl_add"
  Revert "Staging: rts5208: Fix error handling on rtsx_send_cmd"
  Revert "staging: rts5208: Add a check for ms_read_extra_data"
  Revert "dmaengine: qcom_hidma: Check for driver register failure"
  Revert "dmaengine: mv_xor: Fix a missing check in mv_xor_channel_add"
  Revert "iio: ad9523: fix a missing check of return value"
  Revert "mfd: mc13xxx: Fix a missing check of a register-read failure"
  Revert "infiniband: bnxt_re: qplib: Check the return value of
    send_message"
  Revert "gdrom: fix a memory leak bug"
  Revert "net: marvell: fix a missing check of acpi_match_device"
  Revert "atl1e: checking the status of atl1e_write_phy_reg"
  Revert "net: dsa: bcm_sf2: Propagate error value from mdio_write"
  Revert "net: stmicro: fix a missing check of clk_prepare"
  Revert "net: (cpts) fix a missing check of clk_prepare"
  Revert "niu: fix missing checks of niu_pci_eeprom_read"
  Revert "net: chelsio: Add a missing check on cudg_get_buffer"
  Revert "ipv6/route: Add a missing check on proc_dointvec"
  Revert "net/net_namespace: Check the return value of
    register_pernet_subsys()"
  Revert "hwmon: (lm80) fix a missing check of bus read in lm80 probe"
  Revert "net: netxen: fix a missing check and an uninitialized use"
  Revert "drivers/regulator: fix a missing check of return value"
  Revert "net: socket: fix a missing-check bug"
  Revert "dm ioctl: harden copy_params()'s copy_from_user() from
    malicious users"
  Revert "ethtool: fix a missing-check bug"
  Revert "media: isif: fix a NULL pointer dereference bug"
  Revert "yam: fix a missing-check bug"
  Revert "net: cxgb3_main: fix a missing-check bug"
  Revert "virt: vbox: Only copy_from_user the request-header once"
  Revert "ALSA: control: fix a redundant-copy issue"
  Revert "scsi: 3w-xxxx: fix a missing-check bug"
  Revert "scsi: 3w-9xxx: fix a missing-check bug"
  Revert "ethtool: fix a potential missing-check bug"

 arch/x86/kernel/hpet.c                        |  2 --
 arch/x86/pci/irq.c                            | 10 ++----
 drivers/acpi/cppc_acpi.c                      |  1 -
 drivers/acpi/sysfs.c                          |  4 +--
 drivers/atm/fore200e.c                        | 25 +++++----------
 drivers/cdrom/gdrom.c                         |  1 -
 drivers/char/agp/intel-gtt.c                  |  4 +--
 drivers/char/hpet.c                           |  2 --
 drivers/clk/samsung/clk.c                     |  4 +++
 drivers/cpuidle/sysfs.c                       |  6 ++--
 drivers/dma/mv_xor.c                          |  5 +--
 drivers/dma/qcom/hidma_mgmt.c                 |  3 +-
 drivers/edac/edac_device_sysfs.c              |  1 -
 drivers/edac/edac_pci_sysfs.c                 |  2 +-
 drivers/firmware/efi/esrt.c                   |  2 +-
 drivers/firmware/qemu_fw_cfg.c                |  7 ++---
 drivers/gpio/gpio-aspeed.c                    |  2 --
 drivers/gpu/drm/amd/amdkfd/kfd_topology.c     | 20 +++---------
 drivers/gpu/drm/gma500/cdv_intel_display.c    |  2 --
 drivers/gpu/drm/gma500/oaktrail_crtc.c        |  2 --
 drivers/gpu/drm/nouveau/dispnv50/disp.c       |  4 +--
 drivers/gpu/drm/nouveau/nouveau_debugfs.c     |  4 +--
 drivers/gpu/drm/nouveau/nouveau_drm.c         |  8 ++---
 drivers/gpu/drm/nouveau/nouveau_fbcon.c       |  4 +--
 drivers/gpu/drm/nouveau/nouveau_gem.c         |  4 +--
 drivers/gpu/drm/radeon/radeon_connectors.c    | 20 +++---------
 drivers/gpu/drm/radeon/radeon_display.c       |  4 +--
 drivers/gpu/drm/radeon/radeon_drv.c           |  4 +--
 drivers/gpu/drm/radeon/radeon_kms.c           |  4 +--
 drivers/hid/hid-logitech-hidpp.c              |  8 +----
 drivers/hwmon/lm80.c                          | 11 ++-----
 drivers/iio/adc/mxs-lradc-adc.c               |  2 --
 drivers/iio/frequency/ad9523.c                |  7 ++---
 drivers/iio/magnetometer/hmc5843_i2c.c        |  7 +----
 drivers/iio/magnetometer/hmc5843_spi.c        |  7 +----
 drivers/infiniband/core/sysfs.c               | 10 +++---
 drivers/infiniband/hw/bnxt_re/qplib_sp.c      |  5 +--
 drivers/infiniband/hw/i40iw/i40iw.h           |  2 +-
 drivers/infiniband/hw/i40iw/i40iw_cm.c        | 18 ++---------
 drivers/infiniband/hw/i40iw/i40iw_main.c      |  5 +--
 .../infiniband/hw/vmw_pvrdma/pvrdma_main.c    |  2 +-
 drivers/infiniband/sw/rdmavt/qp.c             |  6 ++--
 drivers/infiniband/ulp/srpt/ib_srpt.c         |  2 ++
 drivers/input/touchscreen/ad7879.c            | 11 +++----
 drivers/iommu/iommu.c                         |  2 +-
 drivers/isdn/hardware/mISDN/hfcsusb.c         |  3 --
 drivers/isdn/hardware/mISDN/mISDNinfineon.c   |  5 +--
 drivers/leds/leds-lp5523.c                    |  4 +--
 drivers/md/dm-ioctl.c                         | 18 +++++++----
 drivers/md/raid10.c                           |  2 --
 drivers/md/raid5.c                            |  2 --
 drivers/media/common/saa7146/saa7146_fops.c   |  2 ++
 drivers/media/common/saa7146/saa7146_video.c  |  6 ++--
 drivers/media/dvb-frontends/drxd_hard.c       | 30 +++++++-----------
 drivers/media/dvb-frontends/lgdt3306a.c       |  5 +--
 drivers/media/dvb-frontends/mt312.c           |  4 +--
 drivers/media/dvb-frontends/si2165.c          |  8 ++---
 drivers/media/dvb-frontends/sp8870.c          |  4 +--
 drivers/media/platform/davinci/isif.c         |  3 +-
 drivers/media/platform/davinci/vpfe_capture.c | 31 +++++++++----------
 drivers/media/platform/exynos4-is/fimc-isp.c  |  4 +--
 drivers/media/platform/exynos4-is/fimc-lite.c |  2 +-
 drivers/media/platform/exynos4-is/media-dev.c |  4 +--
 drivers/media/platform/exynos4-is/mipi-csis.c |  4 +--
 .../media/platform/qcom/camss/camss-csiphy.c  |  4 +--
 drivers/media/platform/rcar-fcp.c             |  4 +--
 drivers/media/platform/rcar-vin/rcar-dma.c    |  4 +--
 drivers/media/platform/rcar-vin/rcar-v4l2.c   |  4 +--
 drivers/media/platform/rcar_drif.c            |  1 -
 drivers/media/platform/rockchip/rga/rga-buf.c |  1 -
 drivers/media/platform/s5p-mfc/s5p_mfc_pm.c   |  4 +--
 drivers/media/platform/sti/delta/delta-v4l2.c |  4 +--
 drivers/media/platform/sti/hva/hva-hw.c       |  2 --
 drivers/media/platform/stm32/stm32-dcmi.c     |  4 ++-
 drivers/media/platform/ti-vpe/vpe.c           |  2 --
 drivers/media/platform/video-mux.c            |  5 ---
 drivers/media/usb/cx231xx/cx231xx-i2c.c       |  3 +-
 drivers/media/usb/gspca/cpia1.c               | 14 ++-------
 drivers/media/usb/gspca/m5602/m5602_mt9m111.c |  8 ++---
 drivers/media/usb/gspca/m5602/m5602_po1030.c  |  8 ++---
 drivers/mfd/mc13xxx-core.c                    |  4 +--
 drivers/misc/ics932s401.c                     |  2 --
 drivers/mmc/host/mmc_spi.c                    |  4 ---
 drivers/net/caif/caif_serial.c                |  4 +--
 drivers/net/dsa/bcm_sf2.c                     |  7 +++--
 drivers/net/ethernet/8390/pcnet_cs.c          | 10 ------
 .../net/ethernet/atheros/atl1e/atl1e_main.c   |  4 +--
 .../net/ethernet/cavium/liquidio/lio_core.c   | 10 ------
 .../net/ethernet/cavium/liquidio/lio_main.c   |  5 ---
 .../net/ethernet/cavium/thunder/nicvf_main.c  |  6 ----
 .../net/ethernet/chelsio/cxgb3/cxgb3_main.c   | 17 ----------
 .../net/ethernet/chelsio/cxgb4/cudbg_lib.c    |  4 ---
 drivers/net/ethernet/fujitsu/fmvj18x_cs.c     |  5 ---
 drivers/net/ethernet/intel/ixgbevf/vf.c       |  5 +--
 .../net/ethernet/marvell/mvpp2/mvpp2_main.c   |  2 --
 drivers/net/ethernet/mellanox/mlx4/fw.c       |  2 +-
 drivers/net/ethernet/netronome/nfp/abm/main.c |  1 -
 .../ethernet/qlogic/netxen/netxen_nic_init.c  |  3 +-
 drivers/net/ethernet/qlogic/qla3xxx.c         |  6 ----
 .../ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c   |  4 +--
 .../ethernet/qlogic/qlcnic/qlcnic_ethtool.c   |  2 --
 drivers/net/ethernet/rocker/rocker_main.c     |  5 ---
 .../net/ethernet/stmicro/stmmac/dwmac-sunxi.c |  4 +--
 drivers/net/ethernet/sun/cassini.c            |  3 +-
 drivers/net/ethernet/sun/niu.c                | 10 ++----
 drivers/net/ethernet/ti/cpts.c                |  4 +--
 drivers/net/hamradio/hdlcdrv.c                |  2 ++
 drivers/net/hamradio/yam.c                    |  4 ---
 drivers/net/ieee802154/mcr20a.c               |  6 ----
 drivers/net/ppp/pppoe.c                       |  2 ++
 drivers/net/wireless/ath/ath6kl/wmi.c         |  4 ++-
 .../broadcom/brcm80211/brcmfmac/usb.c         |  6 +---
 drivers/net/wireless/marvell/libertas/mesh.c  |  5 ---
 drivers/net/wireless/marvell/mwifiex/cmdevt.c |  6 ----
 drivers/net/wireless/realtek/rtlwifi/base.c   |  5 ---
 drivers/net/wireless/rsi/rsi_91x_mac80211.c   | 30 +++++++-----------
 drivers/net/wireless/st/cw1200/main.c         |  5 ---
 drivers/nfc/s3fwrn5/firmware.c                |  5 +--
 drivers/nvdimm/btt_devs.c                     | 18 +++--------
 drivers/nvdimm/namespace_devs.c               |  5 +--
 drivers/pci/controller/pcie-xilinx.c          | 12 ++-----
 drivers/pci/endpoint/functions/pci-epf-test.c |  5 ---
 drivers/pci/slot.c                            |  6 ++--
 drivers/pinctrl/pinctrl-axp209.c              |  2 --
 drivers/platform/chrome/cros_ec_ishtp.c       |  4 +--
 drivers/power/supply/charger-manager.c        |  3 --
 drivers/power/supply/power_supply_hwmon.c     |  2 +-
 drivers/power/supply/twl4030_charger.c        |  4 +--
 drivers/rapidio/rio_cm.c                      |  8 -----
 drivers/regulator/palmas-regulator.c          |  5 +--
 drivers/rtc/rtc-hym8563.c                     |  2 --
 drivers/scsi/3w-9xxx.c                        |  5 ---
 drivers/scsi/3w-xxxx.c                        |  3 --
 drivers/scsi/iscsi_boot_sysfs.c               |  2 +-
 drivers/scsi/qla4xxx/ql4_os.c                 |  2 --
 drivers/scsi/ufs/ufs-hisi.c                   |  4 ---
 drivers/spi/spi-topcliff-pch.c                | 15 ++-------
 drivers/staging/greybus/audio_manager.c       |  3 --
 drivers/staging/kpc2000/kpc_dma/fileops.c     |  2 ++
 drivers/staging/rtl8188eu/core/rtw_xmit.c     |  9 ++----
 drivers/staging/rtl8188eu/include/rtw_xmit.h  |  2 +-
 drivers/staging/rtl8723bs/core/rtw_xmit.c     | 14 ++++-----
 drivers/staging/rtl8723bs/include/rtw_xmit.h  |  2 +-
 drivers/staging/rts5208/ms.c                  |  5 +--
 drivers/staging/rts5208/sd.c                  |  7 +----
 drivers/target/tcm_fc/tfc_io.c                |  1 +
 drivers/thunderbolt/property.c                | 16 +---------
 drivers/tty/ipwireless/main.c                 |  8 -----
 drivers/tty/serial/atmel_serial.c             |  4 ---
 drivers/tty/serial/max310x.c                  |  4 +--
 drivers/tty/serial/mvebu-uart.c               |  3 --
 drivers/tty/serial/mxs-auart.c                |  4 ---
 drivers/usb/dwc3/dwc3-pci.c                   |  4 +--
 drivers/usb/gadget/udc/m66592-udc.c           |  2 +-
 drivers/usb/host/u132-hcd.c                   |  2 --
 drivers/usb/storage/sierra_ms.c               |  4 ++-
 drivers/vfio/mdev/mdev_sysfs.c                |  2 +-
 drivers/video/fbdev/hgafb.c                   |  2 --
 drivers/video/fbdev/imsttfb.c                 |  5 ---
 drivers/video/fbdev/omap2/omapfb/dss/dispc.c  |  7 ++---
 drivers/video/fbdev/omap2/omapfb/dss/dsi.c    |  7 ++---
 drivers/video/fbdev/omap2/omapfb/dss/dss.c    |  7 ++---
 drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c  |  5 ++-
 drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c  |  5 ++-
 .../omap2/omapfb/dss/omapdss-boot-init.c      |  2 --
 drivers/video/fbdev/omap2/omapfb/dss/venc.c   |  7 ++---
 drivers/virt/vboxguest/vboxguest_linux.c      |  4 +--
 drivers/xen/grant-table.c                     |  4 +++
 fs/ecryptfs/crypto.c                          |  6 ++--
 fs/nfsd/nfs4xdr.c                             |  2 ++
 fs/ocfs2/dlm/dlmmaster.c                      |  2 ++
 fs/udf/namei.c                                | 15 +++++++++
 kernel/auditfilter.c                          | 12 +++----
 kernel/bpf/core.c                             |  2 ++
 kernel/trace/trace.c                          |  5 +--
 lib/test_objagg.c                             |  4 +--
 net/atm/clip.c                                |  6 ++--
 net/core/net_namespace.c                      |  3 +-
 net/ethtool/ioctl.c                           |  8 -----
 net/ipv6/netfilter/ip6t_srh.c                 |  6 ----
 net/ipv6/route.c                              |  6 +---
 net/mac80211/util.c                           |  1 +
 net/openvswitch/datapath.c                    |  4 ---
 net/rds/message.c                             |  1 -
 net/rds/send.c                                |  2 +-
 net/rfkill/core.c                             |  7 ++---
 net/rxrpc/rxkad.c                             |  2 +-
 net/smc/smc_ism.c                             |  5 ---
 net/socket.c                                  | 11 ++-----
 net/strparser/strparser.c                     |  2 --
 net/tipc/group.c                              |  3 --
 sound/core/control_compat.c                   |  3 +-
 sound/isa/gus/gus_main.c                      | 13 ++------
 sound/isa/sb/sb16_main.c                      | 10 ++----
 sound/isa/sb/sb8.c                            |  4 ---
 sound/soc/codecs/cs43130.c                    |  2 --
 sound/soc/codecs/rt5645.c                     |  3 --
 sound/soc/img/img-i2s-in.c                    |  5 +--
 sound/soc/img/img-parallel-out.c              |  4 +--
 sound/soc/rockchip/rockchip_pdm.c             |  4 +--
 sound/soc/tegra/tegra30_ahub.c                |  4 +--
 sound/soc/tegra/tegra30_i2s.c                 |  4 +--
 sound/usb/usx2y/usb_stream.c                  |  5 ---
 sound/usb/usx2y/usbusx2y.c                    |  4 ++-
 204 files changed, 306 insertions(+), 826 deletions(-)

Comments

Guenter Roeck April 21, 2021, 1:56 p.m. UTC | #1
On 4/21/21 5:57 AM, Greg Kroah-Hartman wrote:
> I have been meaning to do this for a while, but recent events have
> finally forced me to do so.
> 
> Commits from @umn.edu addresses have been found to be submitted in "bad
> faith" to try to test the kernel community's ability to review "known
> malicious" changes.  The result of these submissions can be found in a
> paper published at the 42nd IEEE Symposium on Security and Privacy
> entitled, "Open Source Insecurity: Stealthily Introducing
> Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
> of Minnesota) and Kangjie Lu (University of Minnesota).
> 

Sigh. As if this wouldn't be a problem everywhere.

> Because of this, all submissions from this group must be reverted from
> the kernel tree and will need to be re-reviewed again to determine if
> they actually are a valid fix.  Until that work is complete, remove this
> change to ensure that no problems are being introduced into the
> codebase.
> 
> This patchset has the "easy" reverts, there are 68 remaining ones that
> need to be manually reviewed.  Some of them are not able to be reverted
> as they already have been reverted, or fixed up with follow-on patches
> as they were determined to be invalid.  Proof that these submissions
> were almost universally wrong.
> 
> I will be working with some other kernel developers to determine if any
> of these reverts were actually valid changes, were actually valid, and
> if so, will resubmit them properly later.  For now, it's better to be
> safe.
> 
> I'll take this through my tree, so no need for any maintainer to worry
> about this, but they should be aware that future submissions from anyone
> with a umn.edu address should be by default-rejected unless otherwise
> determined to actually be a valid fix (i.e. they provide proof and you
> can verify it, but really, why waste your time doing that extra work?)
> 
> thanks,
> 
> greg k-h
> 
[ ... ]
>   Revert "hwmon: (lm80) fix a missing check of bus read in lm80 probe"

I see

9aa3aa15f4c2 hwmon: (lm80) fix a missing check of bus read in lm80 probe
c9c63915519b hwmon: (lm80) fix a missing check of the status of SMBus read

The latter indeed introduced a problem which was later fixed with

07bd14ccc304 hwmon: (lm80) Fix missing unlock on error in set_fan_div()

I guess that was part of the experiment. I don't see a problem with the
patch that is being reverted, but it is not extremely valuable either,
so I don't mind the revert. It is not valuable enough to re-apply it later
either.

FWIW, I didn't see the problem with the second patch even when re-reviewing
it, which makes me suspect that they introduced missing-unlock problems on
purpose. It is important to keep that in mind when re-reviewing the patches.
Also, it may be part of the pattern that they introduced one or more valid
patches followed by a malicious one into the same subsystem on purpose.

Guenter
Greg KH April 21, 2021, 2:21 p.m. UTC | #2
On Wed, Apr 21, 2021 at 06:56:49AM -0700, Guenter Roeck wrote:
> On 4/21/21 5:57 AM, Greg Kroah-Hartman wrote:
> > I have been meaning to do this for a while, but recent events have
> > finally forced me to do so.
> > 
> > Commits from @umn.edu addresses have been found to be submitted in "bad
> > faith" to try to test the kernel community's ability to review "known
> > malicious" changes.  The result of these submissions can be found in a
> > paper published at the 42nd IEEE Symposium on Security and Privacy
> > entitled, "Open Source Insecurity: Stealthily Introducing
> > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
> > of Minnesota) and Kangjie Lu (University of Minnesota).
> > 
> 
> Sigh. As if this wouldn't be a problem everywhere.
> 
> > Because of this, all submissions from this group must be reverted from
> > the kernel tree and will need to be re-reviewed again to determine if
> > they actually are a valid fix.  Until that work is complete, remove this
> > change to ensure that no problems are being introduced into the
> > codebase.
> > 
> > This patchset has the "easy" reverts, there are 68 remaining ones that
> > need to be manually reviewed.  Some of them are not able to be reverted
> > as they already have been reverted, or fixed up with follow-on patches
> > as they were determined to be invalid.  Proof that these submissions
> > were almost universally wrong.
> > 
> > I will be working with some other kernel developers to determine if any
> > of these reverts were actually valid changes, were actually valid, and
> > if so, will resubmit them properly later.  For now, it's better to be
> > safe.
> > 
> > I'll take this through my tree, so no need for any maintainer to worry
> > about this, but they should be aware that future submissions from anyone
> > with a umn.edu address should be by default-rejected unless otherwise
> > determined to actually be a valid fix (i.e. they provide proof and you
> > can verify it, but really, why waste your time doing that extra work?)
> > 
> > thanks,
> > 
> > greg k-h
> > 
> [ ... ]
> >   Revert "hwmon: (lm80) fix a missing check of bus read in lm80 probe"
> 
> I see
> 
> 9aa3aa15f4c2 hwmon: (lm80) fix a missing check of bus read in lm80 probe
> c9c63915519b hwmon: (lm80) fix a missing check of the status of SMBus read
> 
> The latter indeed introduced a problem which was later fixed with
> 
> 07bd14ccc304 hwmon: (lm80) Fix missing unlock on error in set_fan_div()
> 
> I guess that was part of the experiment. I don't see a problem with the
> patch that is being reverted, but it is not extremely valuable either,
> so I don't mind the revert. It is not valuable enough to re-apply it later
> either.
> 
> FWIW, I didn't see the problem with the second patch even when re-reviewing
> it, which makes me suspect that they introduced missing-unlock problems on
> purpose. It is important to keep that in mind when re-reviewing the patches.
> Also, it may be part of the pattern that they introduced one or more valid
> patches followed by a malicious one into the same subsystem on purpose.

Thanks for the review of these, much appreciated.

greg k-h
Jiri Kosina April 21, 2021, 2:32 p.m. UTC | #3
On Wed, 21 Apr 2021, Guenter Roeck wrote:

> > Commits from @umn.edu addresses have been found to be submitted in 
> > "bad faith" to try to test the kernel community's ability to review 
> > "known malicious" changes.  The result of these submissions can be 
> > found in a paper published at the 42nd IEEE Symposium on Security and 
> > Privacy entitled, "Open Source Insecurity: Stealthily Introducing 
> > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu 
> > (University of Minnesota) and Kangjie Lu (University of Minnesota).
> 
> Sigh. As if this wouldn't be a problem everywhere.

Right.

> > Because of this, all submissions from this group must be reverted from
> > the kernel tree and will need to be re-reviewed again to determine if
> > they actually are a valid fix.  Until that work is complete, remove this
> > change to ensure that no problems are being introduced into the
> > codebase.
> > 
> > This patchset has the "easy" reverts, there are 68 remaining ones that
> > need to be manually reviewed.  Some of them are not able to be reverted
> > as they already have been reverted, or fixed up with follow-on patches
> > as they were determined to be invalid.  Proof that these submissions
> > were almost universally wrong.
> > 
> > I will be working with some other kernel developers to determine if any
> > of these reverts were actually valid changes, were actually valid, and
> > if so, will resubmit them properly later.  For now, it's better to be
> > safe.
> > 
> > I'll take this through my tree, so no need for any maintainer to worry
> > about this, but they should be aware that future submissions from anyone
> > with a umn.edu address should be by default-rejected unless otherwise
> > determined to actually be a valid fix (i.e. they provide proof and you
> > can verify it, but really, why waste your time doing that extra work?)
> > 
> > thanks,
> > 
> > greg k-h
> > 
> [ ... ]
> >   Revert "hwmon: (lm80) fix a missing check of bus read in lm80 probe"
> 
> I see
> 
> 9aa3aa15f4c2 hwmon: (lm80) fix a missing check of bus read in lm80 probe
> c9c63915519b hwmon: (lm80) fix a missing check of the status of SMBus read
> 
> The latter indeed introduced a problem which was later fixed with

Therefore I'd like to ask Kangjie Lu (who is CCed here) to consider 
revising his statement in the attempted public clarification:

	"The experiment did not introduce any bug or bug-introducing commit into 
	 OSS."

at [1] as it's clearly not true. Missing mutex unlock clearky is a bug 
introduced by this experiment.

[1] https://www-users.cs.umn.edu/~kjlu/

Thanks,
Jiri Kosina April 21, 2021, 3:09 p.m. UTC | #4
On Wed, 21 Apr 2021, Kangjie Lu wrote:

> > Therefore I'd like to ask Kangjie Lu (who is CCed here) to consider
> > revising his statement in the attempted public clarification:
> >
> >         "The experiment did not introduce any bug or bug-introducing
> > commit into
> >          OSS."
> >
> > at [1] as it's clearly not true. Missing mutex unlock clearky is a bug
> > introduced by this experiment.
> >
> 
> Hi everyone,
> 
> I am so sorry for the concerns. I fully understand why the community is
> angry. Please allow me to have a very quick response, as Jiri requested. We
> will provide a detailed explanation later.

Thanks.

> These are two different projects. The one published at IEEE S&P 2021 has
> completely finished in November 2020. 

What about 8a94644b440 then? It's from May 2020, it has been committed to 
the tree, and it introduces a NULL pointer dereference on 
kobject_init_and_add() failure.
Laurent Pinchart April 21, 2021, 3:16 p.m. UTC | #5
Hi Kangjie,

On Wed, Apr 21, 2021 at 09:44:52AM -0500, Kangjie Lu wrote:
> On Wed, Apr 21, 2021 at 9:32 AM Jiri Kosina wrote:
> > On Wed, 21 Apr 2021, Guenter Roeck wrote:
> > > > Commits from @umn.edu addresses have been found to be submitted in
> > > > "bad faith" to try to test the kernel community's ability to review
> > > > "known malicious" changes.  The result of these submissions can be
> > > > found in a paper published at the 42nd IEEE Symposium on Security and
> > > > Privacy entitled, "Open Source Insecurity: Stealthily Introducing
> > > > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu
> > > > (University of Minnesota) and Kangjie Lu (University of Minnesota).
> > >
> > > Sigh. As if this wouldn't be a problem everywhere.
> >
> > Right.
> >
> > > > Because of this, all submissions from this group must be reverted from
> > > > the kernel tree and will need to be re-reviewed again to determine if
> > > > they actually are a valid fix.  Until that work is complete, remove this
> > > > change to ensure that no problems are being introduced into the
> > > > codebase.
> > > >
> > > > This patchset has the "easy" reverts, there are 68 remaining ones that
> > > > need to be manually reviewed.  Some of them are not able to be reverted
> > > > as they already have been reverted, or fixed up with follow-on patches
> > > > as they were determined to be invalid.  Proof that these submissions
> > > > were almost universally wrong.
> > > >
> > > > I will be working with some other kernel developers to determine if any
> > > > of these reverts were actually valid changes, were actually valid, and
> > > > if so, will resubmit them properly later.  For now, it's better to be
> > > > safe.
> > > >
> > > > I'll take this through my tree, so no need for any maintainer to worry
> > > > about this, but they should be aware that future submissions from anyone
> > > > with a umn.edu address should be by default-rejected unless otherwise
> > > > determined to actually be a valid fix (i.e. they provide proof and you
> > > > can verify it, but really, why waste your time doing that extra work?)
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > > >
> > > [ ... ]
> > > >   Revert "hwmon: (lm80) fix a missing check of bus read in lm80 probe"
> > >
> > > I see
> > >
> > > 9aa3aa15f4c2 hwmon: (lm80) fix a missing check of bus read in lm80 probe
> > > c9c63915519b hwmon: (lm80) fix a missing check of the status of SMBus read
> > >
> > > The latter indeed introduced a problem which was later fixed with
> >
> > Therefore I'd like to ask Kangjie Lu (who is CCed here) to consider
> > revising his statement in the attempted public clarification:
> >
> >         "The experiment did not introduce any bug or bug-introducing commit into
> >          OSS."
> >
> > at [1] as it's clearly not true. Missing mutex unlock clearky is a bug
> > introduced by this experiment.
> 
> Hi everyone,
> 
> I am so sorry for the concerns. I fully understand why the community is
> angry. Please allow me to have a very quick response, as Jiri requested. We
> will provide a detailed explanation later.
> 
> These are two different projects. The one published at IEEE S&P 2021 has
> completely finished in November 2020. My student Aditya is working on a new
> project that is to find bugs introduced by bad patches. Please do not link
> these two projects together.  I am sorry that his new patches are not
> correct either. He did not intentionally make the mistake.

Do you have a list of all known bad commits ? Not that we shouldn't
revert the other ones as well, but having a list of bad ones would be
useful when reviewing commits individually to see which ones may
actually be correct.

> > [1] https://www-users.cs.umn.edu/~kjlu/
Jiri Kosina April 21, 2021, 3:47 p.m. UTC | #6
On Wed, 21 Apr 2021, Qiushi Wu wrote:

> The function description of "kobject_init_and_add()" mentioned that "If 
> this function returns an error, kobject_put() must be called to properly 
> clean up the memory associated with the object." (see 
> https://elixir.bootlin.com/linux/v5.12-rc8/source/lib/kobject.c#L464) So 
> we use this patch to fix the issue, and I may miss some context here, 
> but I don't see why this cause some issue like NULL dereferences.
> 
> The identification methodology for this bug and other similar bugs that
> are error-handling related, is shown in "Understanding and Detecting
> Disordered Error Handling with Precise Function Pairing."
> (https://www.usenix.org/conference/usenixsecurity21/presentation/wu-qiushi)

You are calling kobject_put() if kobject_init_and_add() fails. That will 
in turn invoke pci_slot_release() which will try to delete slot->list, but 
that hasn't been initialized yet. 

Fixed in 4684709bf8, present in two major Linux kernel releases.
Guenter Roeck April 21, 2021, 3:49 p.m. UTC | #7
On Wed, Apr 21, 2021 at 09:44:52AM -0500, Kangjie Lu wrote:
> On Wed, Apr 21, 2021 at 9:32 AM Jiri Kosina <jikos@kernel.org> wrote:
> 
> > On Wed, 21 Apr 2021, Guenter Roeck wrote:
> >
> > > > Commits from @umn.edu addresses have been found to be submitted in
> > > > "bad faith" to try to test the kernel community's ability to review
> > > > "known malicious" changes.  The result of these submissions can be
> > > > found in a paper published at the 42nd IEEE Symposium on Security and
> > > > Privacy entitled, "Open Source Insecurity: Stealthily Introducing
> > > > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu
> > > > (University of Minnesota) and Kangjie Lu (University of Minnesota).
> > >
> > > Sigh. As if this wouldn't be a problem everywhere.
> >
> > Right.
> >
> > > > Because of this, all submissions from this group must be reverted from
> > > > the kernel tree and will need to be re-reviewed again to determine if
> > > > they actually are a valid fix.  Until that work is complete, remove
> > this
> > > > change to ensure that no problems are being introduced into the
> > > > codebase.
> > > >
> > > > This patchset has the "easy" reverts, there are 68 remaining ones that
> > > > need to be manually reviewed.  Some of them are not able to be reverted
> > > > as they already have been reverted, or fixed up with follow-on patches
> > > > as they were determined to be invalid.  Proof that these submissions
> > > > were almost universally wrong.
> > > >
> > > > I will be working with some other kernel developers to determine if any
> > > > of these reverts were actually valid changes, were actually valid, and
> > > > if so, will resubmit them properly later.  For now, it's better to be
> > > > safe.
> > > >
> > > > I'll take this through my tree, so no need for any maintainer to worry
> > > > about this, but they should be aware that future submissions from
> > anyone
> > > > with a umn.edu address should be by default-rejected unless otherwise
> > > > determined to actually be a valid fix (i.e. they provide proof and you
> > > > can verify it, but really, why waste your time doing that extra work?)
> > > >
> > > > thanks,
> > > >
> > > > greg k-h
> > > >
> > > [ ... ]
> > > >   Revert "hwmon: (lm80) fix a missing check of bus read in lm80 probe"
> > >
> > > I see
> > >
> > > 9aa3aa15f4c2 hwmon: (lm80) fix a missing check of bus read in lm80 probe
> > > c9c63915519b hwmon: (lm80) fix a missing check of the status of SMBus
> > read
> > >
> > > The latter indeed introduced a problem which was later fixed with
> >
> > Therefore I'd like to ask Kangjie Lu (who is CCed here) to consider
> > revising his statement in the attempted public clarification:
> >
> >         "The experiment did not introduce any bug or bug-introducing
> > commit into
> >          OSS."
> >
> > at [1] as it's clearly not true. Missing mutex unlock clearky is a bug
> > introduced by this experiment.
> >
> 
> Hi everyone,
> 
> I am so sorry for the concerns. I fully understand why the community is
> angry. Please allow me to have a very quick response, as Jiri requested. We
> will provide a detailed explanation later.
> 
> These are two different projects. The one published at IEEE S&P 2021 has
> completely finished in November 2020. My student Aditya is working on a new
> project that is to find bugs introduced by bad patches. Please do not link
> these two projects together.  I am sorry that his new patches are not
> correct either. He did not intentionally make the mistake.
> 

The author of commit c9c63915519b is Kangjie Lu <kjlu@umn.edu>, not some
student, and I have to assume that it intentionally introduced a problem.
That was the whole point of the exercise, wasn't it ?
As mentioned by Jiri, the statement "The experiment did not introduce
any bug or bug-introducing commit into OSS" is obviously wrong. It is
a lie, to say it directly.

I absolutely agree with Greg's assertion: All patches introduced from
the umn.edu domain can not be trusted and should be reverted.

It might be worthwhile to have a discussion at the upcoming maintainers
summit on how to handle contributions from untrusted sources in the
future, and how to identify trusted contributors. Quite obviously the
paradigm has finally changed from "assume the contribution is
well-intended" to "assume the contribution is malicious". I guess that
was prone to happen, but it is sad to experience it anyway.

For my part, congratulations (in a negative sense): You made me much less
inclined to accept minor bug fixes from people I don't know in the future.

Guenter
Guenter Roeck April 21, 2021, 3:59 p.m. UTC | #8
On 4/21/21 8:21 AM, Kangjie Lu wrote:

> All of the commits sent by my students are in good faith to fix some bugs.
> 

Fool me once, fool me twice.

How do we know that this isn't part of some obscure follow-up study ?

Guenter
Laurent Pinchart April 21, 2021, 4 p.m. UTC | #9
Hi Kangjie,

On Wed, Apr 21, 2021 at 10:21:07AM -0500, Kangjie Lu wrote:
> On Wed, Apr 21, 2021 at 10:16 AM Laurent Pinchart wrote:
> > On Wed, Apr 21, 2021 at 09:44:52AM -0500, Kangjie Lu wrote:
> > > On Wed, Apr 21, 2021 at 9:32 AM Jiri Kosina wrote:
> > > > On Wed, 21 Apr 2021, Guenter Roeck wrote:
> > > > > > Commits from @umn.edu addresses have been found to be submitted in
> > > > > > "bad faith" to try to test the kernel community's ability to review
> > > > > > "known malicious" changes.  The result of these submissions can be
> > > > > > found in a paper published at the 42nd IEEE Symposium on Security and
> > > > > > Privacy entitled, "Open Source Insecurity: Stealthily Introducing
> > > > > > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu
> > > > > > (University of Minnesota) and Kangjie Lu (University of Minnesota).
> > > > >
> > > > > Sigh. As if this wouldn't be a problem everywhere.
> > > >
> > > > Right.
> > > >
> > > > > > Because of this, all submissions from this group must be reverted from
> > > > > > the kernel tree and will need to be re-reviewed again to determine if
> > > > > > they actually are a valid fix.  Until that work is complete, remove this
> > > > > > change to ensure that no problems are being introduced into the
> > > > > > codebase.
> > > > > >
> > > > > > This patchset has the "easy" reverts, there are 68 remaining ones that
> > > > > > need to be manually reviewed.  Some of them are not able to be reverted
> > > > > > as they already have been reverted, or fixed up with follow-on patches
> > > > > > as they were determined to be invalid.  Proof that these submissions
> > > > > > were almost universally wrong.
> > > > > >
> > > > > > I will be working with some other kernel developers to determine if any
> > > > > > of these reverts were actually valid changes, were actually valid, and
> > > > > > if so, will resubmit them properly later.  For now, it's better to be
> > > > > > safe.
> > > > > >
> > > > > > I'll take this through my tree, so no need for any maintainer to worry
> > > > > > about this, but they should be aware that future submissions from anyone
> > > > > > with a umn.edu address should be by default-rejected unless otherwise
> > > > > > determined to actually be a valid fix (i.e. they provide proof and you
> > > > > > can verify it, but really, why waste your time doing that extra work?)
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > greg k-h
> > > > > >
> > > > > [ ... ]
> > > > > >   Revert "hwmon: (lm80) fix a missing check of bus read in lm80 probe"
> > > > >
> > > > > I see
> > > > >
> > > > > 9aa3aa15f4c2 hwmon: (lm80) fix a missing check of bus read in lm80 probe
> > > > > c9c63915519b hwmon: (lm80) fix a missing check of the status of SMBus read
> > > > >
> > > > > The latter indeed introduced a problem which was later fixed with
> > > >
> > > > Therefore I'd like to ask Kangjie Lu (who is CCed here) to consider
> > > > revising his statement in the attempted public clarification:
> > > >
> > > >         "The experiment did not introduce any bug or bug-introducing commit into
> > > >          OSS."
> > > >
> > > > at [1] as it's clearly not true. Missing mutex unlock clearky is a bug
> > > > introduced by this experiment.
> > >
> > > Hi everyone,
> > >
> > > I am so sorry for the concerns. I fully understand why the community is
> > > angry. Please allow me to have a very quick response, as Jiri requested. We
> > > will provide a detailed explanation later.
> > >
> > > These are two different projects. The one published at IEEE S&P 2021 has
> > > completely finished in November 2020. My student Aditya is working on a new
> > > project that is to find bugs introduced by bad patches. Please do not link
> > > these two projects together.  I am sorry that his new patches are not
> > > correct either. He did not intentionally make the mistake.
> >
> > Do you have a list of all known bad commits ? Not that we shouldn't
> > revert the other ones as well, but having a list of bad ones would be
> > useful when reviewing commits individually to see which ones may
> > actually be correct.
> 
> We did not introduce any bad commits in the study of hypocrite commits.
> Please see more details here:
> https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

You may not have intended for those patches to be merged upstream, but
they were submitted on mailing list for review, and it's clear that at
least some of them did get merged. I thus repeat my question: do you
have a full list of all malicious patches submitted to mailing lists ?

> All of the commits sent by my students are in good faith to fix some bugs.
> 
> > > > [1] https://www-users.cs.umn.edu/~kjlu/
Daniel Vetter April 21, 2021, 5:35 p.m. UTC | #10
On Wed, Apr 21, 2021 at 3:01 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> I have been meaning to do this for a while, but recent events have
> finally forced me to do so.
>
> Commits from @umn.edu addresses have been found to be submitted in "bad
> faith" to try to test the kernel community's ability to review "known
> malicious" changes.  The result of these submissions can be found in a
> paper published at the 42nd IEEE Symposium on Security and Privacy
> entitled, "Open Source Insecurity: Stealthily Introducing
> Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
> of Minnesota) and Kangjie Lu (University of Minnesota).
>
> Because of this, all submissions from this group must be reverted from
> the kernel tree and will need to be re-reviewed again to determine if
> they actually are a valid fix.  Until that work is complete, remove this
> change to ensure that no problems are being introduced into the
> codebase.
>
> This patchset has the "easy" reverts, there are 68 remaining ones that
> need to be manually reviewed.  Some of them are not able to be reverted
> as they already have been reverted, or fixed up with follow-on patches
> as they were determined to be invalid.  Proof that these submissions
> were almost universally wrong.

Will you take care of these remaining ones in subsequent patches too?

> I will be working with some other kernel developers to determine if any
> of these reverts were actually valid changes, were actually valid, and
> if so, will resubmit them properly later.  For now, it's better to be
> safe.
>
> I'll take this through my tree, so no need for any maintainer to worry
> about this, but they should be aware that future submissions from anyone
> with a umn.edu address should be by default-rejected unless otherwise
> determined to actually be a valid fix (i.e. they provide proof and you
> can verify it, but really, why waste your time doing that extra work?)
>
> thanks,
>
> greg k-h
>
> Greg Kroah-Hartman (190):
>   Revert "net/rds: Avoid potential use after free in
>     rds_send_remove_from_sock"
>   Revert "media: st-delta: Fix reference count leak in delta_run_work"
>   Revert "media: sti: Fix reference count leaks"
>   Revert "media: exynos4-is: Fix several reference count leaks due to
>     pm_runtime_get_sync"
>   Revert "media: exynos4-is: Fix a reference count leak due to
>     pm_runtime_get_sync"
>   Revert "media: exynos4-is: Fix a reference count leak"
>   Revert "media: ti-vpe: Fix a missing check and reference count leak"
>   Revert "media: stm32-dcmi: Fix a reference count leak"
>   Revert "media: s5p-mfc: Fix a reference count leak"
>   Revert "media: camss: Fix a reference count leak."
>   Revert "media: platform: fcp: Fix a reference count leak."
>   Revert "media: rockchip/rga: Fix a reference count leak."
>   Revert "media: rcar-vin: Fix a reference count leak."
>   Revert "media: rcar-vin: Fix a reference count leak."
>   Revert "firmware: Fix a reference count leak."
>   Revert "drm/nouveau: fix reference count leak in
>     nouveau_debugfs_strap_peek"
>   Revert "drm/nouveau: fix reference count leak in
>     nv50_disp_atomic_commit"
>   Revert "drm/nouveau: fix multiple instances of reference count leaks"
>   Revert "drm/nouveau/drm/noveau: fix reference count leak in
>     nouveau_fbcon_open"
>   Revert "PCI: Fix pci_create_slot() reference count leak"
>   Revert "omapfb: fix multiple reference count leaks due to
>     pm_runtime_get_sync"
>   Revert "drm/radeon: Fix reference count leaks caused by
>     pm_runtime_get_sync"
>   Revert "drm/radeon: fix multiple reference count leak"
>   Revert "drm/amdkfd: Fix reference count leaks."

I didn't review these carefully, but from a quick look they all seem
rather inconsequental. Either error paths that are very unlikely, or
drivers which are very dead (looking at the entire list, not just what
you reverted here).

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Also adding drm maintainers/lists, those aren't all on your cc it
seems. I will also forward this to fd.o sitewranglers as abuse of our
infrastructure, it's for community collaboration, not for inflicting
experiments on unconsenting subjects.

I'me dropping non-drm people here so not everyone gets spammed too badly.
-Daniel

>   Revert "platform/chrome: cros_ec_ishtp: Fix a double-unlock issue"
>   Revert "usb: dwc3: pci: Fix reference count leak in
>     dwc3_pci_resume_work"
>   Revert "ASoC: rockchip: Fix a reference count leak."
>   Revert "RDMA/rvt: Fix potential memory leak caused by rvt_alloc_rq"
>   Revert "EDAC: Fix reference count leaks"
>   Revert "ASoC: tegra: Fix reference count leaks."
>   Revert "test_objagg: Fix potential memory leak in error handling"
>   Revert "ASoC: img-parallel-out: Fix a reference count leak"
>   Revert "ASoC: img: Fix a reference count leak in img_i2s_in_set_fmt"
>   Revert "efi/esrt: Fix reference count leak in
>     esre_create_sysfs_entry."
>   Revert "scsi: iscsi: Fix reference count leak in
>     iscsi_boot_create_kobj"
>   Revert "vfio/mdev: Fix reference count leak in
>     add_mdev_supported_type"
>   Revert "RDMA/core: Fix several reference count leaks."
>   Revert "cpuidle: Fix three reference count leaks"
>   Revert "iommu: Fix reference count leak in iommu_group_alloc."
>   Revert "ACPI: CPPC: Fix reference count leak in
>     acpi_cppc_processor_probe()"
>   Revert "ACPI: sysfs: Fix reference count leak in
>     acpi_sysfs_add_hotplug_profile()"
>   Revert "ASoC: fix incomplete error-handling in img_i2s_in_probe."
>   Revert "qlcnic: fix missing release in qlcnic_83xx_interrupt_test."
>   Revert "RDMA/pvrdma: Fix missing pci disable in pvrdma_pci_probe()"
>   Revert "usb: gadget: fix potential double-free in m66592_probe."
>   Revert "net/mlx4_core: fix a memory leak bug."
>   Revert "rxrpc: Fix a memory leak in rxkad_verify_response()"
>   Revert "net: sun: fix missing release regions in cas_init_one()."
>   Revert "agp/intel: Fix a memory leak on module initialisation failure"
>   Revert "nfp: abm: fix a memory leak bug"
>   Revert "power: supply: core: fix memory leak in HWMON error path"
>   Revert "media: media/saa7146: fix incorrect assertion in
>     saa7146_buffer_finish"
>   Revert "ecryptfs: replace BUG_ON with error handling code"
>   Revert "clk: samsung: Remove redundant check in
>     samsung_cmu_register_one"
>   Revert "fs: ocfs: remove unnecessary assertion in dlm_migrate_lockres"
>   Revert "media: davinci/vpfe_capture.c: Avoid BUG_ON for register
>     failure"
>   Revert "media: saa7146: Avoid using BUG_ON as an assertion"
>   Revert "media: cx231xx: replace BUG_ON with recovery code"
>   Revert "RDMA/srpt: Remove unnecessary assertion in
>     srpt_queue_response"
>   Revert "staging: kpc2000: remove unnecessary assertions in
>     kpc_dma_transfer"
>   Revert "xen/grant-table: remove multiple BUG_ON on gnttab_interface"
>   Revert "scsi: libfc: remove unnecessary assertion on ep variable"
>   Revert "hdlcdrv: replace unnecessary assertion in hdlcdrv_register"
>   Revert "nfc: s3fwrn5: replace the assertion with a WARN_ON"
>   Revert "nfsd: remove unnecessary assertion in nfsd4_encode_replay"
>   Revert "bpf: Remove unnecessary assertion on fp_old"
>   Revert "net: caif: replace BUG_ON with recovery code"
>   Revert "fore200e: Fix incorrect checks of NULL pointer dereference"
>   Revert "mac80211: Remove redundant assertion"
>   Revert "rfkill: Fix incorrect check to avoid NULL pointer dereference"
>   Revert "pppoe: remove redundant BUG_ON() check in pppoe_pernet"
>   Revert "net: atm: Reduce the severity of logging in unlink_clip_vcc"
>   Revert "media: rcar_drif: fix a memory disclosure"
>   Revert "drm/gma500: fix memory disclosures due to uninitialized bytes"
>   Revert "gma/gma500: fix a memory disclosure bug due to uninitialized
>     bytes"
>   Revert "net: ixgbevf: fix a missing check of
>     ixgbevf_write_msg_read_ack"
>   Revert "rapidio: fix a NULL pointer dereference when
>     create_workqueue() fails"
>   Revert "ASoC: cs43130: fix a NULL pointer dereference"
>   Revert "ASoC: rt5645: fix a NULL pointer dereference"
>   Revert "ALSA: usx2y: fix a double free bug"
>   Revert "tracing: Fix a memory leak by early error exit in
>     trace_pid_write()"
>   Revert "rsi: Fix NULL pointer dereference in kmalloc"
>   Revert "net: cw1200: fix a NULL pointer dereference"
>   Revert "net: ieee802154: fix missing checks for regmap_update_bits"
>   Revert "audit: fix a memory leak bug"
>   Revert "x86/PCI: Fix PCI IRQ routing table memory leak"
>   Revert "udf: fix an uninitialized read bug and remove dead code"
>   Revert "mmc_spi: add a status check for spi_sync_locked"
>   Revert "PCI: endpoint: Fix a potential NULL pointer dereference"
>   Revert "net/smc: fix a NULL pointer dereference"
>   Revert "pinctrl: axp209: Fix NULL pointer dereference after
>     allocation"
>   Revert "power: charger-manager: fix a potential NULL pointer
>     dereference"
>   Revert "iio: hmc5843: fix potential NULL pointer dereferences"
>   Revert "iio: adc: fix a potential NULL pointer dereference"
>   Revert "rtlwifi: fix a potential NULL pointer dereference"
>   Revert "net: mwifiex: fix a NULL pointer dereference"
>   Revert "video: imsttfb: fix potential NULL pointer dereferences"
>   Revert "video: hgafb: fix potential NULL pointer dereference"
>   Revert "omapfb: Fix potential NULL pointer dereference in kmalloc"
>   Revert "staging: greybus: audio_manager: fix a missing check of
>     ida_simple_get"
>   Revert "PCI: xilinx: Check for __get_free_pages() failure"
>   Revert "media: video-mux: fix null pointer dereferences"
>   Revert "thunderbolt: property: Fix a missing check of kzalloc"
>   Revert "char: hpet: fix a missing check of ioremap"
>   Revert "libnvdimm/btt: Fix a kmemdup failure check"
>   Revert "tty: ipwireless: fix missing checks for ioremap"
>   Revert "RDMA/i40iw: Handle workqueue allocation failure"
>   Revert "usb: u132-hcd: fix potential NULL pointer dereference"
>   Revert "usb: sierra: fix a missing check of device_create_file"
>   Revert "scsi: qla4xxx: fix a potential NULL pointer dereference"
>   Revert "gpio: aspeed: fix a potential NULL pointer dereference"
>   Revert "libnvdimm/namespace: Fix a potential NULL pointer dereference"
>   Revert "x86/hpet: Prevent potential NULL pointer dereference"
>   Revert "staging: rtl8188eu: Fix potential NULL pointer dereference of
>     kcalloc"
>   Revert "thunderbolt: Fix a missing check of kmemdup"
>   Revert "thunderbolt: property: Fix a NULL pointer dereference"
>   Revert "media: si2165: fix a missing check of return value"
>   Revert "scsi: ufs: fix a missing check of devm_reset_control_get"
>   Revert "tty: mxs-auart: fix a potential NULL pointer dereference"
>   Revert "tty: atmel_serial: fix a potential NULL pointer dereference"
>   Revert "serial: mvebu-uart: Fix to avoid a potential NULL pointer
>     dereference"
>   Revert "HID: logitech: check the return value of
>     create_singlethread_workqueue"
>   Revert "netfilter: ip6t_srh: fix NULL pointer dereferences"
>   Revert "spi : spi-topcliff-pch: Fix to handle empty DMA buffers"
>   Revert "net: tipc: fix a missing check of nla_nest_start"
>   Revert "net: openvswitch: fix a NULL pointer dereference"
>   Revert "ALSA: sb8: add a check for request_region"
>   Revert "net: strparser: fix a missing check for
>     create_singlethread_workqueue"
>   Revert "qlcnic: Avoid potential NULL pointer dereference"
>   Revert "ALSA: usx2y: Fix potential NULL pointer dereference"
>   Revert "net: 8390: fix potential NULL pointer dereferences"
>   Revert "net: fujitsu: fix a potential NULL pointer dereference"
>   Revert "net: qlogic: fix a potential NULL pointer dereference"
>   Revert "md: Fix failed allocation of md_register_thread"
>   Revert "net: rocker: fix a potential NULL pointer dereference"
>   Revert "net: thunder: fix a potential NULL pointer dereference"
>   Revert "net: lio_core: fix two NULL pointer dereferences"
>   Revert "net: liquidio: fix a NULL pointer dereference"
>   Revert "isdn: mISDNinfineon: fix potential NULL pointer dereference"
>   Revert "isdn: mISDN: Fix potential NULL pointer dereference of
>     kzalloc"
>   Revert "libertas: add checks for the return value of
>     sysfs_create_group"
>   Revert "rtc: hym8563: fix a missing check of block data read"
>   Revert "power: twl4030: fix a missing check of return value"
>   Revert "misc/ics932s401: Add a missing check to
>     i2c_smbus_read_word_data"
>   Revert "leds: lp5523: fix a missing check of return value of
>     lp55xx_read"
>   Revert "media: dvb: Add check on sp8870_readreg"
>   Revert "media: dvb: add return value check on Write16"
>   Revert "media: mt312: fix a missing check of mt312 reset"
>   Revert "media: lgdt3306a: fix a missing check of return value"
>   Revert "media: gspca: mt9m111: Check write_bridge for timeout"
>   Revert "media: gspca: Check the return value of write_bridge for
>     timeout"
>   Revert "media: usb: gspca: add a missed check for goto_low_power"
>   Revert "media: usb: gspca: add a missed return-value check for
>     do_command"
>   Revert "ath6kl: return error code in ath6kl_wmi_set_roam_lrssi_cmd()"
>   Revert "brcmfmac: add a check for the status of usb_register"
>   Revert "serial: max310x: pass return value of spi_register_driver"
>   Revert "Input: ad7879 - add check for read errors in interrupt"
>   Revert "ALSA: sb: fix a missing check of snd_ctl_add"
>   Revert "ALSA: gus: add a check of the status of snd_ctl_add"
>   Revert "Staging: rts5208: Fix error handling on rtsx_send_cmd"
>   Revert "staging: rts5208: Add a check for ms_read_extra_data"
>   Revert "dmaengine: qcom_hidma: Check for driver register failure"
>   Revert "dmaengine: mv_xor: Fix a missing check in mv_xor_channel_add"
>   Revert "iio: ad9523: fix a missing check of return value"
>   Revert "mfd: mc13xxx: Fix a missing check of a register-read failure"
>   Revert "infiniband: bnxt_re: qplib: Check the return value of
>     send_message"
>   Revert "gdrom: fix a memory leak bug"
>   Revert "net: marvell: fix a missing check of acpi_match_device"
>   Revert "atl1e: checking the status of atl1e_write_phy_reg"
>   Revert "net: dsa: bcm_sf2: Propagate error value from mdio_write"
>   Revert "net: stmicro: fix a missing check of clk_prepare"
>   Revert "net: (cpts) fix a missing check of clk_prepare"
>   Revert "niu: fix missing checks of niu_pci_eeprom_read"
>   Revert "net: chelsio: Add a missing check on cudg_get_buffer"
>   Revert "ipv6/route: Add a missing check on proc_dointvec"
>   Revert "net/net_namespace: Check the return value of
>     register_pernet_subsys()"
>   Revert "hwmon: (lm80) fix a missing check of bus read in lm80 probe"
>   Revert "net: netxen: fix a missing check and an uninitialized use"
>   Revert "drivers/regulator: fix a missing check of return value"
>   Revert "net: socket: fix a missing-check bug"
>   Revert "dm ioctl: harden copy_params()'s copy_from_user() from
>     malicious users"
>   Revert "ethtool: fix a missing-check bug"
>   Revert "media: isif: fix a NULL pointer dereference bug"
>   Revert "yam: fix a missing-check bug"
>   Revert "net: cxgb3_main: fix a missing-check bug"
>   Revert "virt: vbox: Only copy_from_user the request-header once"
>   Revert "ALSA: control: fix a redundant-copy issue"
>   Revert "scsi: 3w-xxxx: fix a missing-check bug"
>   Revert "scsi: 3w-9xxx: fix a missing-check bug"
>   Revert "ethtool: fix a potential missing-check bug"
>
>  arch/x86/kernel/hpet.c                        |  2 --
>  arch/x86/pci/irq.c                            | 10 ++----
>  drivers/acpi/cppc_acpi.c                      |  1 -
>  drivers/acpi/sysfs.c                          |  4 +--
>  drivers/atm/fore200e.c                        | 25 +++++----------
>  drivers/cdrom/gdrom.c                         |  1 -
>  drivers/char/agp/intel-gtt.c                  |  4 +--
>  drivers/char/hpet.c                           |  2 --
>  drivers/clk/samsung/clk.c                     |  4 +++
>  drivers/cpuidle/sysfs.c                       |  6 ++--
>  drivers/dma/mv_xor.c                          |  5 +--
>  drivers/dma/qcom/hidma_mgmt.c                 |  3 +-
>  drivers/edac/edac_device_sysfs.c              |  1 -
>  drivers/edac/edac_pci_sysfs.c                 |  2 +-
>  drivers/firmware/efi/esrt.c                   |  2 +-
>  drivers/firmware/qemu_fw_cfg.c                |  7 ++---
>  drivers/gpio/gpio-aspeed.c                    |  2 --
>  drivers/gpu/drm/amd/amdkfd/kfd_topology.c     | 20 +++---------
>  drivers/gpu/drm/gma500/cdv_intel_display.c    |  2 --
>  drivers/gpu/drm/gma500/oaktrail_crtc.c        |  2 --
>  drivers/gpu/drm/nouveau/dispnv50/disp.c       |  4 +--
>  drivers/gpu/drm/nouveau/nouveau_debugfs.c     |  4 +--
>  drivers/gpu/drm/nouveau/nouveau_drm.c         |  8 ++---
>  drivers/gpu/drm/nouveau/nouveau_fbcon.c       |  4 +--
>  drivers/gpu/drm/nouveau/nouveau_gem.c         |  4 +--
>  drivers/gpu/drm/radeon/radeon_connectors.c    | 20 +++---------
>  drivers/gpu/drm/radeon/radeon_display.c       |  4 +--
>  drivers/gpu/drm/radeon/radeon_drv.c           |  4 +--
>  drivers/gpu/drm/radeon/radeon_kms.c           |  4 +--
>  drivers/hid/hid-logitech-hidpp.c              |  8 +----
>  drivers/hwmon/lm80.c                          | 11 ++-----
>  drivers/iio/adc/mxs-lradc-adc.c               |  2 --
>  drivers/iio/frequency/ad9523.c                |  7 ++---
>  drivers/iio/magnetometer/hmc5843_i2c.c        |  7 +----
>  drivers/iio/magnetometer/hmc5843_spi.c        |  7 +----
>  drivers/infiniband/core/sysfs.c               | 10 +++---
>  drivers/infiniband/hw/bnxt_re/qplib_sp.c      |  5 +--
>  drivers/infiniband/hw/i40iw/i40iw.h           |  2 +-
>  drivers/infiniband/hw/i40iw/i40iw_cm.c        | 18 ++---------
>  drivers/infiniband/hw/i40iw/i40iw_main.c      |  5 +--
>  .../infiniband/hw/vmw_pvrdma/pvrdma_main.c    |  2 +-
>  drivers/infiniband/sw/rdmavt/qp.c             |  6 ++--
>  drivers/infiniband/ulp/srpt/ib_srpt.c         |  2 ++
>  drivers/input/touchscreen/ad7879.c            | 11 +++----
>  drivers/iommu/iommu.c                         |  2 +-
>  drivers/isdn/hardware/mISDN/hfcsusb.c         |  3 --
>  drivers/isdn/hardware/mISDN/mISDNinfineon.c   |  5 +--
>  drivers/leds/leds-lp5523.c                    |  4 +--
>  drivers/md/dm-ioctl.c                         | 18 +++++++----
>  drivers/md/raid10.c                           |  2 --
>  drivers/md/raid5.c                            |  2 --
>  drivers/media/common/saa7146/saa7146_fops.c   |  2 ++
>  drivers/media/common/saa7146/saa7146_video.c  |  6 ++--
>  drivers/media/dvb-frontends/drxd_hard.c       | 30 +++++++-----------
>  drivers/media/dvb-frontends/lgdt3306a.c       |  5 +--
>  drivers/media/dvb-frontends/mt312.c           |  4 +--
>  drivers/media/dvb-frontends/si2165.c          |  8 ++---
>  drivers/media/dvb-frontends/sp8870.c          |  4 +--
>  drivers/media/platform/davinci/isif.c         |  3 +-
>  drivers/media/platform/davinci/vpfe_capture.c | 31 +++++++++----------
>  drivers/media/platform/exynos4-is/fimc-isp.c  |  4 +--
>  drivers/media/platform/exynos4-is/fimc-lite.c |  2 +-
>  drivers/media/platform/exynos4-is/media-dev.c |  4 +--
>  drivers/media/platform/exynos4-is/mipi-csis.c |  4 +--
>  .../media/platform/qcom/camss/camss-csiphy.c  |  4 +--
>  drivers/media/platform/rcar-fcp.c             |  4 +--
>  drivers/media/platform/rcar-vin/rcar-dma.c    |  4 +--
>  drivers/media/platform/rcar-vin/rcar-v4l2.c   |  4 +--
>  drivers/media/platform/rcar_drif.c            |  1 -
>  drivers/media/platform/rockchip/rga/rga-buf.c |  1 -
>  drivers/media/platform/s5p-mfc/s5p_mfc_pm.c   |  4 +--
>  drivers/media/platform/sti/delta/delta-v4l2.c |  4 +--
>  drivers/media/platform/sti/hva/hva-hw.c       |  2 --
>  drivers/media/platform/stm32/stm32-dcmi.c     |  4 ++-
>  drivers/media/platform/ti-vpe/vpe.c           |  2 --
>  drivers/media/platform/video-mux.c            |  5 ---
>  drivers/media/usb/cx231xx/cx231xx-i2c.c       |  3 +-
>  drivers/media/usb/gspca/cpia1.c               | 14 ++-------
>  drivers/media/usb/gspca/m5602/m5602_mt9m111.c |  8 ++---
>  drivers/media/usb/gspca/m5602/m5602_po1030.c  |  8 ++---
>  drivers/mfd/mc13xxx-core.c                    |  4 +--
>  drivers/misc/ics932s401.c                     |  2 --
>  drivers/mmc/host/mmc_spi.c                    |  4 ---
>  drivers/net/caif/caif_serial.c                |  4 +--
>  drivers/net/dsa/bcm_sf2.c                     |  7 +++--
>  drivers/net/ethernet/8390/pcnet_cs.c          | 10 ------
>  .../net/ethernet/atheros/atl1e/atl1e_main.c   |  4 +--
>  .../net/ethernet/cavium/liquidio/lio_core.c   | 10 ------
>  .../net/ethernet/cavium/liquidio/lio_main.c   |  5 ---
>  .../net/ethernet/cavium/thunder/nicvf_main.c  |  6 ----
>  .../net/ethernet/chelsio/cxgb3/cxgb3_main.c   | 17 ----------
>  .../net/ethernet/chelsio/cxgb4/cudbg_lib.c    |  4 ---
>  drivers/net/ethernet/fujitsu/fmvj18x_cs.c     |  5 ---
>  drivers/net/ethernet/intel/ixgbevf/vf.c       |  5 +--
>  .../net/ethernet/marvell/mvpp2/mvpp2_main.c   |  2 --
>  drivers/net/ethernet/mellanox/mlx4/fw.c       |  2 +-
>  drivers/net/ethernet/netronome/nfp/abm/main.c |  1 -
>  .../ethernet/qlogic/netxen/netxen_nic_init.c  |  3 +-
>  drivers/net/ethernet/qlogic/qla3xxx.c         |  6 ----
>  .../ethernet/qlogic/qlcnic/qlcnic_83xx_hw.c   |  4 +--
>  .../ethernet/qlogic/qlcnic/qlcnic_ethtool.c   |  2 --
>  drivers/net/ethernet/rocker/rocker_main.c     |  5 ---
>  .../net/ethernet/stmicro/stmmac/dwmac-sunxi.c |  4 +--
>  drivers/net/ethernet/sun/cassini.c            |  3 +-
>  drivers/net/ethernet/sun/niu.c                | 10 ++----
>  drivers/net/ethernet/ti/cpts.c                |  4 +--
>  drivers/net/hamradio/hdlcdrv.c                |  2 ++
>  drivers/net/hamradio/yam.c                    |  4 ---
>  drivers/net/ieee802154/mcr20a.c               |  6 ----
>  drivers/net/ppp/pppoe.c                       |  2 ++
>  drivers/net/wireless/ath/ath6kl/wmi.c         |  4 ++-
>  .../broadcom/brcm80211/brcmfmac/usb.c         |  6 +---
>  drivers/net/wireless/marvell/libertas/mesh.c  |  5 ---
>  drivers/net/wireless/marvell/mwifiex/cmdevt.c |  6 ----
>  drivers/net/wireless/realtek/rtlwifi/base.c   |  5 ---
>  drivers/net/wireless/rsi/rsi_91x_mac80211.c   | 30 +++++++-----------
>  drivers/net/wireless/st/cw1200/main.c         |  5 ---
>  drivers/nfc/s3fwrn5/firmware.c                |  5 +--
>  drivers/nvdimm/btt_devs.c                     | 18 +++--------
>  drivers/nvdimm/namespace_devs.c               |  5 +--
>  drivers/pci/controller/pcie-xilinx.c          | 12 ++-----
>  drivers/pci/endpoint/functions/pci-epf-test.c |  5 ---
>  drivers/pci/slot.c                            |  6 ++--
>  drivers/pinctrl/pinctrl-axp209.c              |  2 --
>  drivers/platform/chrome/cros_ec_ishtp.c       |  4 +--
>  drivers/power/supply/charger-manager.c        |  3 --
>  drivers/power/supply/power_supply_hwmon.c     |  2 +-
>  drivers/power/supply/twl4030_charger.c        |  4 +--
>  drivers/rapidio/rio_cm.c                      |  8 -----
>  drivers/regulator/palmas-regulator.c          |  5 +--
>  drivers/rtc/rtc-hym8563.c                     |  2 --
>  drivers/scsi/3w-9xxx.c                        |  5 ---
>  drivers/scsi/3w-xxxx.c                        |  3 --
>  drivers/scsi/iscsi_boot_sysfs.c               |  2 +-
>  drivers/scsi/qla4xxx/ql4_os.c                 |  2 --
>  drivers/scsi/ufs/ufs-hisi.c                   |  4 ---
>  drivers/spi/spi-topcliff-pch.c                | 15 ++-------
>  drivers/staging/greybus/audio_manager.c       |  3 --
>  drivers/staging/kpc2000/kpc_dma/fileops.c     |  2 ++
>  drivers/staging/rtl8188eu/core/rtw_xmit.c     |  9 ++----
>  drivers/staging/rtl8188eu/include/rtw_xmit.h  |  2 +-
>  drivers/staging/rtl8723bs/core/rtw_xmit.c     | 14 ++++-----
>  drivers/staging/rtl8723bs/include/rtw_xmit.h  |  2 +-
>  drivers/staging/rts5208/ms.c                  |  5 +--
>  drivers/staging/rts5208/sd.c                  |  7 +----
>  drivers/target/tcm_fc/tfc_io.c                |  1 +
>  drivers/thunderbolt/property.c                | 16 +---------
>  drivers/tty/ipwireless/main.c                 |  8 -----
>  drivers/tty/serial/atmel_serial.c             |  4 ---
>  drivers/tty/serial/max310x.c                  |  4 +--
>  drivers/tty/serial/mvebu-uart.c               |  3 --
>  drivers/tty/serial/mxs-auart.c                |  4 ---
>  drivers/usb/dwc3/dwc3-pci.c                   |  4 +--
>  drivers/usb/gadget/udc/m66592-udc.c           |  2 +-
>  drivers/usb/host/u132-hcd.c                   |  2 --
>  drivers/usb/storage/sierra_ms.c               |  4 ++-
>  drivers/vfio/mdev/mdev_sysfs.c                |  2 +-
>  drivers/video/fbdev/hgafb.c                   |  2 --
>  drivers/video/fbdev/imsttfb.c                 |  5 ---
>  drivers/video/fbdev/omap2/omapfb/dss/dispc.c  |  7 ++---
>  drivers/video/fbdev/omap2/omapfb/dss/dsi.c    |  7 ++---
>  drivers/video/fbdev/omap2/omapfb/dss/dss.c    |  7 ++---
>  drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c  |  5 ++-
>  drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c  |  5 ++-
>  .../omap2/omapfb/dss/omapdss-boot-init.c      |  2 --
>  drivers/video/fbdev/omap2/omapfb/dss/venc.c   |  7 ++---
>  drivers/virt/vboxguest/vboxguest_linux.c      |  4 +--
>  drivers/xen/grant-table.c                     |  4 +++
>  fs/ecryptfs/crypto.c                          |  6 ++--
>  fs/nfsd/nfs4xdr.c                             |  2 ++
>  fs/ocfs2/dlm/dlmmaster.c                      |  2 ++
>  fs/udf/namei.c                                | 15 +++++++++
>  kernel/auditfilter.c                          | 12 +++----
>  kernel/bpf/core.c                             |  2 ++
>  kernel/trace/trace.c                          |  5 +--
>  lib/test_objagg.c                             |  4 +--
>  net/atm/clip.c                                |  6 ++--
>  net/core/net_namespace.c                      |  3 +-
>  net/ethtool/ioctl.c                           |  8 -----
>  net/ipv6/netfilter/ip6t_srh.c                 |  6 ----
>  net/ipv6/route.c                              |  6 +---
>  net/mac80211/util.c                           |  1 +
>  net/openvswitch/datapath.c                    |  4 ---
>  net/rds/message.c                             |  1 -
>  net/rds/send.c                                |  2 +-
>  net/rfkill/core.c                             |  7 ++---
>  net/rxrpc/rxkad.c                             |  2 +-
>  net/smc/smc_ism.c                             |  5 ---
>  net/socket.c                                  | 11 ++-----
>  net/strparser/strparser.c                     |  2 --
>  net/tipc/group.c                              |  3 --
>  sound/core/control_compat.c                   |  3 +-
>  sound/isa/gus/gus_main.c                      | 13 ++------
>  sound/isa/sb/sb16_main.c                      | 10 ++----
>  sound/isa/sb/sb8.c                            |  4 ---
>  sound/soc/codecs/cs43130.c                    |  2 --
>  sound/soc/codecs/rt5645.c                     |  3 --
>  sound/soc/img/img-i2s-in.c                    |  5 +--
>  sound/soc/img/img-parallel-out.c              |  4 +--
>  sound/soc/rockchip/rockchip_pdm.c             |  4 +--
>  sound/soc/tegra/tegra30_ahub.c                |  4 +--
>  sound/soc/tegra/tegra30_i2s.c                 |  4 +--
>  sound/usb/usx2y/usb_stream.c                  |  5 ---
>  sound/usb/usx2y/usbusx2y.c                    |  4 ++-
>  204 files changed, 306 insertions(+), 826 deletions(-)
>
> --
> 2.31.1
>
Al Viro April 21, 2021, 5:48 p.m. UTC | #11
On Wed, Apr 21, 2021 at 08:59:34AM -0700, Guenter Roeck wrote:
> On 4/21/21 8:21 AM, Kangjie Lu wrote:
> 
> > All of the commits sent by my students are in good faith to fix some bugs.


Just to make sure - does that statement cover the following commit?

commit 0c85a7e87465f2d4cbc768e245f4f45b2f299b05
Author: Aditya Pakki <pakki001@umn.edu>
Date:   Tue Apr 6 19:09:12 2021 -0500

    net/rds: Avoid potential use after free in rds_send_remove_from_sock

And is "Ph.D. student in Computer Science" an accurate description of
the gentleman in question?

We all made utterly bonehead mistakes (if you want a fresh example
of mine, take a look at 161aff1d93ab "LOOKUP_MOUNTPOINT: fold
path_mountpointat() into path_lookupat()"; see 035d80695fae for the
merge of the fix and explanation of what was wrong in the original
commit).

However, there's a general expectation that once you become aware of
dumb mistake in something you have published (and merge into mainline
certainly qualifies as publication) you shall retract it as soon
as possible.  If a student is not aware of such expectation, their
advisor really ought to inform them of it.
Jason Gunthorpe April 21, 2021, 6:01 p.m. UTC | #12
On Wed, Apr 21, 2021 at 02:57:55PM +0200, Greg Kroah-Hartman wrote:
> I have been meaning to do this for a while, but recent events have
> finally forced me to do so.
> 
> Commits from @umn.edu addresses have been found to be submitted in "bad
> faith" to try to test the kernel community's ability to review "known
> malicious" changes.  The result of these submissions can be found in a
> paper published at the 42nd IEEE Symposium on Security and Privacy
> entitled, "Open Source Insecurity: Stealthily Introducing
> Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
> of Minnesota) and Kangjie Lu (University of Minnesota).

I noted in the paper it says:

  A. Ethical Considerations

  Ensuring the safety of the experiment. In the experiment, we aim to
  demonstrate the practicality of stealthily introducing vulnerabilities
  through hypocrite commits. Our goal is not to introduce
  vulnerabilities to harm OSS. Therefore, we safely conduct the
  experiment to make sure that the introduced UAF bugs will not be
  merged into the actual Linux code

So, this revert is based on not trusting the authors to carry out
their work in the manner they explained?

From what I've reviewed, and general sentiment of other people's
reviews I've read, I am concerned this giant revert will degrade
kernel quality more than the experimenters did - especially if they
followed their stated methodology.

Jason
Krzysztof Kozlowski April 21, 2021, 6:08 p.m. UTC | #13
On 21/04/2021 19:48, Al Viro wrote:
> On Wed, Apr 21, 2021 at 08:59:34AM -0700, Guenter Roeck wrote:
>> On 4/21/21 8:21 AM, Kangjie Lu wrote:
>>
>>> All of the commits sent by my students are in good faith to fix some bugs.
> 
> 
> Just to make sure - does that statement cover the following commit?
> 
> commit 0c85a7e87465f2d4cbc768e245f4f45b2f299b05
> Author: Aditya Pakki <pakki001@umn.edu>
> Date:   Tue Apr 6 19:09:12 2021 -0500
> 
>     net/rds: Avoid potential use after free in rds_send_remove_from_sock
> 
> And is "Ph.D. student in Computer Science" an accurate description of
> the gentleman in question?
> 
> We all made utterly bonehead mistakes (if you want a fresh example
> of mine, take a look at 161aff1d93ab "LOOKUP_MOUNTPOINT: fold
> path_mountpointat() into path_lookupat()"; see 035d80695fae for the
> merge of the fix and explanation of what was wrong in the original
> commit).
> 
> However, there's a general expectation that once you become aware of
> dumb mistake in something you have published (and merge into mainline
> certainly qualifies as publication) you shall retract it as soon
> as possible.  If a student is not aware of such expectation, their
> advisor really ought to inform them of it.

Mentioned gentleman was also notified on 8th of April with Coverity
report that his patch is questionable:
https://lore.kernel.org/linux-next/202104081640.1A09A99900@keescook/

The report was ignored by the patch author.

Best regards,
Krzysztof
Linus Walleij April 21, 2021, 11:30 p.m. UTC | #14
On Wed, Apr 21, 2021 at 3:01 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:

>   Revert "pinctrl: axp209: Fix NULL pointer dereference after
>     allocation"

There is nothing wrong with this patch that I can see.
It's pretty trivial to inspect.

>   Revert "gpio: aspeed: fix a potential NULL pointer dereference"

I don't see the problem with this either.

There seem to be legit code coming out of umn.edu as well.
To me it seems like students getting assigned to fix random
NULL pointer dereferences, seems unfair that their first
contributions should be punished for what some researcher did.

But I would personally like to discuss the ethics of this
study with the headmaster of this university.

Yours,
Linus Walleij
Al Viro April 22, 2021, 5:51 a.m. UTC | #15
On Wed, Apr 21, 2021 at 02:57:55PM +0200, Greg Kroah-Hartman wrote:

> I'll take this through my tree, so no need for any maintainer to worry
> about this, but they should be aware that future submissions from anyone
> with a umn.edu address should be by default-rejected unless otherwise
> determined to actually be a valid fix (i.e. they provide proof and you
> can verify it, but really, why waste your time doing that extra work?)

Frankly, the last bit is nonsense.  If nothing else, consider the situation
when somebody from UMN (which is a lot bigger than the group in question,
but hell with it - somebody really from that group) posts an analysis of
a real bug, along with a correct fix.  With valid proof of correctness.
What should we do?  Leave the bug in place?  Unattractive, to put it
mildly.  Write a fix and try to make it different from theirs?  Not always
feasible.  Write a fix without looking at theirs and commit it?  And if it
happens to coincide with theirs, then what?

FWIW, I do believe their claims that they tried to avoid introducing bugs
and creating problems in general.  So did RT[F]M, for that matter.
However, the very nature of their "experiment"[1] required deflecting
review.  With obvious effects...

[1] I won't go into its value, relevance of threat model, etc. at the
moment - proper comments on that paper will take more time than I'm likely
to have during the next couple of weeks.
Pavel Machek April 22, 2021, 8:38 a.m. UTC | #16
Hi!

I don't believe doing huge revert is good idea.

> I have been meaning to do this for a while, but recent events have
> finally forced me to do so.
> 
> Commits from @umn.edu addresses have been found to be submitted in "bad
> faith" to try to test the kernel community's ability to review "known
> malicious" changes.  The result of these submissions can be found in a
> paper published at the 42nd IEEE Symposium on Security and Privacy
> entitled, "Open Source Insecurity: Stealthily Introducing
> Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
> of Minnesota) and Kangjie Lu (University of Minnesota).

Do you have examples of those "bad faith" commits? Because that's not
what the paper says. While I identified one unneccessary commit during
stable review, I don't believe it was done in bad faith. According to
the paper, there are just three (3) (!!) bad faith commits, and were
done from gmail addresses, and steps were taken so to prevent them
from entering git.

I do believe we have problem with -stable kernel getting way too many
changes that are not really fixing anything, or are fixing stuff like
"16 bytes memory leak once per boot" or printk log levels. I tried
pushing back with little success. Stable kernel rules are not
consistent with patches actually accepted into stable. Plus, it is
quicker to get patch to stable release than to mainline release, which
I believe is additional problem.

For the reference, the paper seems to be available here:

https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf

Quoting the paper:

Experiment overview. In this experiment, we leverage
program-analysis techniques to prepare three minor hypocrite
commits that introduce UAF bugs in the Linux kernel. The
three cases represent three different kinds of hypocrite commits:
(1) a coding-improvement change that simply prints an error
message, (2) a patch for fixing a memory-leak bug, and (3) a
patch for fixing a refcount bug. We submit the three patches
using a random Gmail account to the Linux community and
seek their feedback—whether the patches look good to them.
The experiment is to demonstrate the practicality of hypocrite
commits, and it will not introduce or intend to introduce actual
UAF or any other bug in the Linux kernel.
A. Ethical Considerations
Ensuring the safety of the experiment. In the experiment,
we aim to demonstrate the practicality of stealthily introducing
vulnerabilities through hypocrite commits. Our goal is not to
introduce vulnerabilities to harm OSS. Therefore, we safely
conduct the experiment to make sure that the introduced UAF
bugs will not be merged into the actual Linux code. In addition
to the minor patches that introduce UAF conditions, we also
prepare the correct patches for fixing the minor issues. We
send the minor patches to the Linux community through email
to seek their feedback. Fortunately, there is a time window
between the confirmation of a patch and the merging of the
patch. Once a maintainer confirmed our patches, e.g., an email
reply indicating “looks good”, we immediately notify the
maintainers of the introduced UAF and request them to not
go ahead to apply the patch. At the same time, we point out
the correct fixing of the bug and provide our correct patch.
In all the three cases, maintainers explicitly acknowledged
and confirmed to not move forward with the incorrect patches
...

Best regards,
							Pavel
Doug Ledford April 22, 2021, 6:53 p.m. UTC | #17
On Wed, 2021-04-21 at 15:01 -0300, Jason Gunthorpe wrote:
> On Wed, Apr 21, 2021 at 02:57:55PM +0200, Greg Kroah-Hartman wrote:
> > I have been meaning to do this for a while, but recent events have
> > finally forced me to do so.
> > 
> > Commits from @umn.edu addresses have been found to be submitted in
> > "bad
> > faith" to try to test the kernel community's ability to review
> > "known
> > malicious" changes.  The result of these submissions can be found in
> > a
> > paper published at the 42nd IEEE Symposium on Security and Privacy
> > entitled, "Open Source Insecurity: Stealthily Introducing
> > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu
> > (University
> > of Minnesota) and Kangjie Lu (University of Minnesota).
> 
> I noted in the paper it says:
> 
>   A. Ethical Considerations
> 
>   Ensuring the safety of the experiment. In the experiment, we aim to
>   demonstrate the practicality of stealthily introducing
> vulnerabilities
>   through hypocrite commits. Our goal is not to introduce
>   vulnerabilities to harm OSS. Therefore, we safely conduct the
>   experiment to make sure that the introduced UAF bugs will not be
>   merged into the actual Linux code
> 
> So, this revert is based on not trusting the authors to carry out
> their work in the manner they explained?
> 
> From what I've reviewed, and general sentiment of other people's
> reviews I've read, I am concerned this giant revert will degrade
> kernel quality more than the experimenters did - especially if they
> followed their stated methodology.

I have to agree with Jason.  This seems like trying to push a thumbtack
into a bulletin board using a pyle driver.  Unless the researchers are
lying (which I've not seen a clear indication of), the 190 patches you
have selected here are nothing more than collateral damage while you are
completely missing the supposed patch submission addresses from which
the malicious patches were sent!

This all really sounds like a knee-jerk reaction to thier posting.  I
have to say, I think it's the wrong reaction to have.  Remember, these
guys are the ones explaining how things can be done and exposing the
tricks.  That puts them in the white-hat hacker camp, not the black-hat
hacker camp.  You shouldn't be banning them, you should be listening to
them and seeing if they found any constructive ways to improve and
harden the maintenance process against these sorts of things.
Al Viro April 22, 2021, 7:16 p.m. UTC | #18
On Thu, Apr 22, 2021 at 02:53:12PM -0400, Doug Ledford wrote:

> This all really sounds like a knee-jerk reaction to thier posting.  I
> have to say, I think it's the wrong reaction to have.

Agreed, however...

> Remember, these
> guys are the ones explaining how things can be done and exposing the
> tricks.

... these guys are the one who provide summarized stats (as opposed to
the raw data and experimental protocol) illustrating their thesis,
along with some advocacy towards their prefered "solutions".

> That puts them in the white-hat hacker camp, not the black-hat
> hacker camp.  You shouldn't be banning them, you should be listening to
> them and seeing if they found any constructive ways to improve and
> harden the maintenance process against these sorts of things.

I'm sorry, but what they are doing is no science - it's advocacy.
The data would certainly be useful - how the submission attempts
went, what correlated with successful ones - timing relative to -rc,
lists involved, etc.; I can think of a bunch of possible factors,
but there's no way to test any of that against their data.
Examining the threads around individual submissions would also be
interesting and might bring useful information.  Except that we
can't do that, since they have not even bothered to publish the
list of SHA1 of commits they got in, nevermind the Message-Id of
the relevant emails.

I don't like the circus with blanket reverts either, for a lot
of reasons.  And ethics questions aside, their raw data might
very well be worth looking into, but as for the trust in their
conclusions... I've seen xenobiology papers done better than
that.
Theodore Ts'o April 22, 2021, 8:48 p.m. UTC | #19
On Thu, Apr 22, 2021 at 02:53:12PM -0400, Doug Ledford wrote:
> I have to agree with Jason.  This seems like trying to push a thumbtack
> into a bulletin board using a pyle driver.  Unless the researchers are
> lying (which I've not seen a clear indication of), the 190 patches you
> have selected here are nothing more than collateral damage while you are
> completely missing the supposed patch submission addresses from which
> the malicious patches were sent!

The 190 reverts are going through the standard review process.  Quite
a few of those patches are getting a "this looks good, please don't
revert".  And these reverts aren't going to be going in for 5.12, but
rather for the next merge window.  So we have plenty of time to review
them and either (a) drop the revert, or (b) if it does get reverted,
we can always re-apply it after it gets proper review.

Given that some of the 190 patches have been found to contain bugs,
regardless of whether they were submitted in good faith or not, it may
be that some of these buggy patches may point out opportunities for us
to improve our patch review processes.  So as a random sampling of
"trivial" (or maybe not-so-trivial) patches sent from a university
since 2018, doing a more careful patch review is precisely a way to,
as you put it:

> harden the maintenance process against these sorts of things.

> This all really sounds like a knee-jerk reaction to thier posting.  I
> have to say, I think it's the wrong reaction to have.  Remember, these
> guys are the ones explaining how things can be done and exposing the
> tricks.  That puts them in the white-hat hacker camp, not the black-hat
> hacker camp.

The idea of turning some students loose on trying to get evil patches
past some kernel maintainers that had worried me didn't appear to be
doing adequate review is something that had crossed my mind over 10 or
15 years ago.  I just didn't do it because, (a) the obvious ethics
concerns, and (b) it wouldn't actually tell us anything new.

Also, even the assistant department head of the UMN CS department has
admitted that this was clearly an IRB failure, and that what they did
was clearly Human Subject Research that should have been stopped cold
at the "get permission from the IRB" stage.  So that puts them in the
gray-hat category at best.

> You shouldn't be banning them, you should be listening to
> them and seeing if they found any constructive ways to improve and
> harden the maintenance process against these sorts of things.

Well, the paper is available.  Aside from the obvious, "be more
careful with code reviews", they had the advice of adding to our Code
of Conduct, "don't do this unethical thing we just did".  Which might
or might not work in terms of preventing academics who submitted
patches in bad faith, but I very much would prevent someone working
for the Ministry of State Security.

So you could consider doing an in-depth review of the patches sent
from umn.edu to be a step towards doing more careful review.  Let's
see what we learn from that analysis.

						- Ted
Kees Cook April 22, 2021, 9:57 p.m. UTC | #20
On Wed, Apr 21, 2021 at 02:57:55PM +0200, Greg Kroah-Hartman wrote:
> Because of this, all submissions from this group must be reverted from
> the kernel tree and will need to be re-reviewed again to determine if
> they actually are a valid fix.  Until that work is complete, remove this
> change to ensure that no problems are being introduced into the
> codebase.

Hi,

The LF Technical Advisory Board is taking a look at the history of
UMN's contributions and their associated research projects. At present,
it seems the vast majority of patches have been in good faith, but we're
continuing to review the work. Several public conversations have already
started around our expectations of contributors[1].

- Kees, speaking on behalf of the TAB

[1] https://lore.kernel.org/ksummit/a72a13e56ee5f19b0dee9ae8c1928b020e8809c2.camel@HansenPartnership.com/
Krzysztof Kozlowski April 23, 2021, 7:01 a.m. UTC | #21
On 22/04/2021 20:53, Doug Ledford wrote:
> On Wed, 2021-04-21 at 15:01 -0300, Jason Gunthorpe wrote:
>> On Wed, Apr 21, 2021 at 02:57:55PM +0200, Greg Kroah-Hartman wrote:
>>> I have been meaning to do this for a while, but recent events have
>>> finally forced me to do so.
>>>
>>> Commits from @umn.edu addresses have been found to be submitted in
>>> "bad
>>> faith" to try to test the kernel community's ability to review
>>> "known
>>> malicious" changes.  The result of these submissions can be found in
>>> a
>>> paper published at the 42nd IEEE Symposium on Security and Privacy
>>> entitled, "Open Source Insecurity: Stealthily Introducing
>>> Vulnerabilities via Hypocrite Commits" written by Qiushi Wu
>>> (University
>>> of Minnesota) and Kangjie Lu (University of Minnesota).
>>
>> I noted in the paper it says:
>>
>>   A. Ethical Considerations
>>
>>   Ensuring the safety of the experiment. In the experiment, we aim to
>>   demonstrate the practicality of stealthily introducing
>> vulnerabilities
>>   through hypocrite commits. Our goal is not to introduce
>>   vulnerabilities to harm OSS. Therefore, we safely conduct the
>>   experiment to make sure that the introduced UAF bugs will not be
>>   merged into the actual Linux code
>>
>> So, this revert is based on not trusting the authors to carry out
>> their work in the manner they explained?
>>
>> From what I've reviewed, and general sentiment of other people's
>> reviews I've read, I am concerned this giant revert will degrade
>> kernel quality more than the experimenters did - especially if they
>> followed their stated methodology.
> 
> I have to agree with Jason.  This seems like trying to push a thumbtack
> into a bulletin board using a pyle driver.  Unless the researchers are
> lying (which I've not seen a clear indication of), the 190 patches you
> have selected here are nothing more than collateral damage while you are
> completely missing the supposed patch submission addresses from which
> the malicious patches were sent!
> 
> This all really sounds like a knee-jerk reaction to thier posting.  I
> have to say, I think it's the wrong reaction to have.

Nothing stops you from participating in the review of this
revert-series, if you think these are valuable commits. Patches getting
the review, won't be reverted (as I understood).


Best regards,
Krzysztof
Greg KH April 23, 2021, 7:10 a.m. UTC | #22
On Fri, Apr 23, 2021 at 09:01:26AM +0200, Krzysztof Kozlowski wrote:
> On 22/04/2021 20:53, Doug Ledford wrote:
> > On Wed, 2021-04-21 at 15:01 -0300, Jason Gunthorpe wrote:
> >> On Wed, Apr 21, 2021 at 02:57:55PM +0200, Greg Kroah-Hartman wrote:
> >>> I have been meaning to do this for a while, but recent events have
> >>> finally forced me to do so.
> >>>
> >>> Commits from @umn.edu addresses have been found to be submitted in
> >>> "bad
> >>> faith" to try to test the kernel community's ability to review
> >>> "known
> >>> malicious" changes.  The result of these submissions can be found in
> >>> a
> >>> paper published at the 42nd IEEE Symposium on Security and Privacy
> >>> entitled, "Open Source Insecurity: Stealthily Introducing
> >>> Vulnerabilities via Hypocrite Commits" written by Qiushi Wu
> >>> (University
> >>> of Minnesota) and Kangjie Lu (University of Minnesota).
> >>
> >> I noted in the paper it says:
> >>
> >>   A. Ethical Considerations
> >>
> >>   Ensuring the safety of the experiment. In the experiment, we aim to
> >>   demonstrate the practicality of stealthily introducing
> >> vulnerabilities
> >>   through hypocrite commits. Our goal is not to introduce
> >>   vulnerabilities to harm OSS. Therefore, we safely conduct the
> >>   experiment to make sure that the introduced UAF bugs will not be
> >>   merged into the actual Linux code
> >>
> >> So, this revert is based on not trusting the authors to carry out
> >> their work in the manner they explained?
> >>
> >> From what I've reviewed, and general sentiment of other people's
> >> reviews I've read, I am concerned this giant revert will degrade
> >> kernel quality more than the experimenters did - especially if they
> >> followed their stated methodology.
> > 
> > I have to agree with Jason.  This seems like trying to push a thumbtack
> > into a bulletin board using a pyle driver.  Unless the researchers are
> > lying (which I've not seen a clear indication of), the 190 patches you
> > have selected here are nothing more than collateral damage while you are
> > completely missing the supposed patch submission addresses from which
> > the malicious patches were sent!
> > 
> > This all really sounds like a knee-jerk reaction to thier posting.  I
> > have to say, I think it's the wrong reaction to have.
> 
> Nothing stops you from participating in the review of this
> revert-series, if you think these are valuable commits. Patches getting
> the review, won't be reverted (as I understood).

You understand correctly :)
Jason Gunthorpe April 23, 2021, 7:19 p.m. UTC | #23
On Thu, Apr 22, 2021 at 04:48:04PM -0400, Theodore Ts'o wrote:

> So you could consider doing an in-depth review of the patches sent
> from umn.edu to be a step towards doing more careful review.  Let's
> see what we learn from that analysis.

My take is this is "as expected" from people operating static
analyzers and other tools. At best they are good at pointing to
potential problems, but typicaly lack the kernel specific knowledge to
be fully relied on to make a fix independently. Further, it is very
rare that people doing this work would be able to test their patches.

At least I always check this stuff no matter who sends it.

Even well reputed people like Nick and Dan make errors and need their
work checked.

I'm interested to see the measured error rate of these 190 patches -
excluding the "not-useful but not wrong" determination.

Based on some Fixes: data mining I did recently it would be hard to
get excited below about 10% errors.

Jason
Greg KH April 26, 2021, 5:09 p.m. UTC | #24
On Thu, Apr 22, 2021 at 01:30:17AM +0200, Linus Walleij wrote:
> On Wed, Apr 21, 2021 at 3:01 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> 
> >   Revert "pinctrl: axp209: Fix NULL pointer dereference after
> >     allocation"
> 
> There is nothing wrong with this patch that I can see.
> It's pretty trivial to inspect.

Now dropped.

> 
> >   Revert "gpio: aspeed: fix a potential NULL pointer dereference"
> 
> I don't see the problem with this either.

Also now dropped from my tree, thanks for the review!

greg k-h
Greg KH April 27, 2021, 4:44 p.m. UTC | #25
On Wed, Apr 21, 2021 at 07:35:44PM +0200, Daniel Vetter wrote:
> On Wed, Apr 21, 2021 at 3:01 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > I have been meaning to do this for a while, but recent events have
> > finally forced me to do so.
> >
> > Commits from @umn.edu addresses have been found to be submitted in "bad
> > faith" to try to test the kernel community's ability to review "known
> > malicious" changes.  The result of these submissions can be found in a
> > paper published at the 42nd IEEE Symposium on Security and Privacy
> > entitled, "Open Source Insecurity: Stealthily Introducing
> > Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
> > of Minnesota) and Kangjie Lu (University of Minnesota).
> >
> > Because of this, all submissions from this group must be reverted from
> > the kernel tree and will need to be re-reviewed again to determine if
> > they actually are a valid fix.  Until that work is complete, remove this
> > change to ensure that no problems are being introduced into the
> > codebase.
> >
> > This patchset has the "easy" reverts, there are 68 remaining ones that
> > need to be manually reviewed.  Some of them are not able to be reverted
> > as they already have been reverted, or fixed up with follow-on patches
> > as they were determined to be invalid.  Proof that these submissions
> > were almost universally wrong.
> 
> Will you take care of these remaining ones in subsequent patches too?

Yes I will.

> > I will be working with some other kernel developers to determine if any
> > of these reverts were actually valid changes, were actually valid, and
> > if so, will resubmit them properly later.  For now, it's better to be
> > safe.
> >
> > I'll take this through my tree, so no need for any maintainer to worry
> > about this, but they should be aware that future submissions from anyone
> > with a umn.edu address should be by default-rejected unless otherwise
> > determined to actually be a valid fix (i.e. they provide proof and you
> > can verify it, but really, why waste your time doing that extra work?)
> >
> > thanks,
> >
> > greg k-h
> >
> > Greg Kroah-Hartman (190):
> >   Revert "net/rds: Avoid potential use after free in
> >     rds_send_remove_from_sock"
> >   Revert "media: st-delta: Fix reference count leak in delta_run_work"
> >   Revert "media: sti: Fix reference count leaks"
> >   Revert "media: exynos4-is: Fix several reference count leaks due to
> >     pm_runtime_get_sync"
> >   Revert "media: exynos4-is: Fix a reference count leak due to
> >     pm_runtime_get_sync"
> >   Revert "media: exynos4-is: Fix a reference count leak"
> >   Revert "media: ti-vpe: Fix a missing check and reference count leak"
> >   Revert "media: stm32-dcmi: Fix a reference count leak"
> >   Revert "media: s5p-mfc: Fix a reference count leak"
> >   Revert "media: camss: Fix a reference count leak."
> >   Revert "media: platform: fcp: Fix a reference count leak."
> >   Revert "media: rockchip/rga: Fix a reference count leak."
> >   Revert "media: rcar-vin: Fix a reference count leak."
> >   Revert "media: rcar-vin: Fix a reference count leak."
> >   Revert "firmware: Fix a reference count leak."
> >   Revert "drm/nouveau: fix reference count leak in
> >     nouveau_debugfs_strap_peek"
> >   Revert "drm/nouveau: fix reference count leak in
> >     nv50_disp_atomic_commit"
> >   Revert "drm/nouveau: fix multiple instances of reference count leaks"
> >   Revert "drm/nouveau/drm/noveau: fix reference count leak in
> >     nouveau_fbcon_open"
> >   Revert "PCI: Fix pci_create_slot() reference count leak"
> >   Revert "omapfb: fix multiple reference count leaks due to
> >     pm_runtime_get_sync"
> >   Revert "drm/radeon: Fix reference count leaks caused by
> >     pm_runtime_get_sync"
> >   Revert "drm/radeon: fix multiple reference count leak"
> >   Revert "drm/amdkfd: Fix reference count leaks."
> 
> I didn't review these carefully, but from a quick look they all seem
> rather inconsequental. Either error paths that are very unlikely, or
> drivers which are very dead (looking at the entire list, not just what
> you reverted here).
> 
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Thanks for the quick review, I'm now going over them all again to see if
they are valid or not, some of the pm reference count stuff all looks
correct.  Others not at all.

> Also adding drm maintainers/lists, those aren't all on your cc it
> seems. I will also forward this to fd.o sitewranglers as abuse of our
> infrastructure, it's for community collaboration, not for inflicting
> experiments on unconsenting subjects.

Much appreciated.

greg k-h
Pavel Machek April 29, 2021, 7:58 p.m. UTC | #26
Hi!

> >   Revert "drm/radeon: Fix reference count leaks caused by
> >     pm_runtime_get_sync"
> >   Revert "drm/radeon: fix multiple reference count leak"
> >   Revert "drm/amdkfd: Fix reference count leaks."
> 
> I didn't review these carefully, but from a quick look they all seem
> rather inconsequental. Either error paths that are very unlikely, or
> drivers which are very dead (looking at the entire list, not just what
> you reverted here).
> 
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>

So you are knowingly acking patch re-introducing bugs into kernel, because 
the bugs are minor? I don't believe that's an okay thing to do.

Maybe something needs reverting, but lets not introduce bugs into kernel because they are
"minor".

Best regards,
									Pavel