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(-)
--
2.31.1
This reverts commit 410822037cc909c4bef845a71e9cac92b75591d2.
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.
Cc: Qiushi Wu <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/rcar-vin/rcar-v4l2.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 457a65bf6b66..d8144cde2952 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -871,10 +871,8 @@ static int rvin_open(struct file *file)
int ret;
ret = pm_runtime_get_sync(vin->dev);
- if (ret < 0) {
- pm_runtime_put_noidle(vin->dev);
+ if (ret < 0)
return ret;
- }
ret = mutex_lock_interruptible(&vin->lock);
if (ret)
--
2.31.1
This reverts commit aaffa0126a111d65f4028c503c76192d4cc93277.
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.
Cc: Qiushi Wu <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/rcar-vin/rcar-dma.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c b/drivers/media/platform/rcar-vin/rcar-dma.c
index f30dafbdf61c..e109b3d0f4d1 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -1459,10 +1459,8 @@ int rvin_set_channel_routing(struct rvin_dev *vin, u8 chsel)
int ret;
ret = pm_runtime_get_sync(vin->dev);
- if (ret < 0) {
- pm_runtime_put_noidle(vin->dev);
+ if (ret < 0)
return ret;
- }
/* Make register writes take effect immediately. */
vnmc = rvin_read(vin, VNMC_REG);
--
2.31.1
This reverts commit 9fb10671011143d15b6b40d6d5fa9c52c57e9d63.
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.
Cc: Evan Quan <[email protected]>
Cc: Aditya Pakki <[email protected]>
Cc: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/radeon/radeon_display.c | 4 +---
drivers/gpu/drm/radeon/radeon_drv.c | 4 +---
drivers/gpu/drm/radeon/radeon_kms.c | 4 +---
3 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
index 652af7a134bd..9f29ba6c2bed 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -627,10 +627,8 @@ radeon_crtc_set_config(struct drm_mode_set *set,
dev = set->crtc->dev;
ret = pm_runtime_get_sync(dev->dev);
- if (ret < 0) {
- pm_runtime_put_autosuspend(dev->dev);
+ if (ret < 0)
return ret;
- }
ret = drm_crtc_helper_set_config(set, ctx);
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c
index efeb115ae70e..468b364c2dab 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -513,10 +513,8 @@ long radeon_drm_ioctl(struct file *filp,
long ret;
dev = file_priv->minor->dev;
ret = pm_runtime_get_sync(dev->dev);
- if (ret < 0) {
- pm_runtime_put_autosuspend(dev->dev);
+ if (ret < 0)
return ret;
- }
ret = drm_ioctl(filp, cmd, arg);
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c
index 2479d6ab7a36..df644bb68c0f 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -644,10 +644,8 @@ int radeon_driver_open_kms(struct drm_device *dev, struct drm_file *file_priv)
file_priv->driver_priv = NULL;
r = pm_runtime_get_sync(dev->dev);
- if (r < 0) {
- pm_runtime_put_autosuspend(dev->dev);
+ if (r < 0)
return r;
- }
/* new gpu have virtual address space support */
if (rdev->family >= CHIP_CAYMAN) {
--
2.31.1
This reverts commit a2cdf39536b0d21fb06113f5e16692513d7bcb9c.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Ben Skeggs <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 1c9c0cdf85db..8ae298ab1cfb 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -2320,10 +2320,8 @@ nv50_disp_atomic_commit(struct drm_device *dev,
int ret, i;
ret = pm_runtime_get_sync(dev->dev);
- if (ret < 0 && ret != -EACCES) {
- pm_runtime_put_autosuspend(dev->dev);
+ if (ret < 0 && ret != -EACCES)
return ret;
- }
ret = drm_atomic_helper_setup_commit(state, nonblock);
if (ret)
--
2.31.1
This reverts commit 7ef64ceea0008c17e94a8a2c60c5d6d46f481996.
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.
Cc: Qiushi Wu <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/exynos4-is/fimc-isp.c | 4 +---
drivers/media/platform/exynos4-is/fimc-lite.c | 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-isp.c b/drivers/media/platform/exynos4-is/fimc-isp.c
index a77c49b18511..cde0d254ec1c 100644
--- a/drivers/media/platform/exynos4-is/fimc-isp.c
+++ b/drivers/media/platform/exynos4-is/fimc-isp.c
@@ -305,10 +305,8 @@ static int fimc_isp_subdev_s_power(struct v4l2_subdev *sd, int on)
if (on) {
ret = pm_runtime_get_sync(&is->pdev->dev);
- if (ret < 0) {
- pm_runtime_put(&is->pdev->dev);
+ if (ret < 0)
return ret;
- }
set_bit(IS_ST_PWR_ON, &is->state);
ret = fimc_is_start_firmware(is);
diff --git a/drivers/media/platform/exynos4-is/fimc-lite.c b/drivers/media/platform/exynos4-is/fimc-lite.c
index fe20af3a7178..1576f273761b 100644
--- a/drivers/media/platform/exynos4-is/fimc-lite.c
+++ b/drivers/media/platform/exynos4-is/fimc-lite.c
@@ -471,7 +471,7 @@ static int fimc_lite_open(struct file *file)
set_bit(ST_FLITE_IN_USE, &fimc->state);
ret = pm_runtime_get_sync(&fimc->pdev->dev);
if (ret < 0)
- goto err_pm;
+ goto unlock;
ret = v4l2_fh_open(file);
if (ret < 0)
--
2.31.1
This reverts commit 6f2e8acdb48ed166b65d47837c31b177460491ec.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/radeon/radeon_connectors.c | 20 +++++---------------
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c
index 607ad5620bd9..ba8885676676 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -879,10 +879,8 @@ radeon_lvds_detect(struct drm_connector *connector, bool force)
if (!drm_kms_helper_is_poll_worker()) {
r = pm_runtime_get_sync(connector->dev->dev);
- if (r < 0) {
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (r < 0)
return connector_status_disconnected;
- }
}
if (encoder) {
@@ -1027,10 +1025,8 @@ radeon_vga_detect(struct drm_connector *connector, bool force)
if (!drm_kms_helper_is_poll_worker()) {
r = pm_runtime_get_sync(connector->dev->dev);
- if (r < 0) {
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (r < 0)
return connector_status_disconnected;
- }
}
encoder = radeon_best_single_encoder(connector);
@@ -1167,10 +1163,8 @@ radeon_tv_detect(struct drm_connector *connector, bool force)
if (!drm_kms_helper_is_poll_worker()) {
r = pm_runtime_get_sync(connector->dev->dev);
- if (r < 0) {
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (r < 0)
return connector_status_disconnected;
- }
}
encoder = radeon_best_single_encoder(connector);
@@ -1253,10 +1247,8 @@ radeon_dvi_detect(struct drm_connector *connector, bool force)
if (!drm_kms_helper_is_poll_worker()) {
r = pm_runtime_get_sync(connector->dev->dev);
- if (r < 0) {
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (r < 0)
return connector_status_disconnected;
- }
}
if (radeon_connector->detected_hpd_without_ddc) {
@@ -1665,10 +1657,8 @@ radeon_dp_detect(struct drm_connector *connector, bool force)
if (!drm_kms_helper_is_poll_worker()) {
r = pm_runtime_get_sync(connector->dev->dev);
- if (r < 0) {
- pm_runtime_put_autosuspend(connector->dev->dev);
+ if (r < 0)
return connector_status_disconnected;
- }
}
if (!force && radeon_check_hpd_status_unchanged(connector)) {
--
2.31.1
This reverts commit 20eca0123a35305e38b344d571cf32768854168c.
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.
Cc: Qiushi Wu <[email protected]>
Cc: Felix Kuehling <[email protected]>
Cc: Felix Kuehling <[email protected]>
Cc: Alex Deucher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 20 +++++---------------
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
index 0be72789ccbc..d3c3fa25c2cc 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -637,10 +637,8 @@ static int kfd_build_sysfs_node_entry(struct kfd_topology_device *dev,
ret = kobject_init_and_add(dev->kobj_node, &node_type,
sys_props.kobj_nodes, "%d", id);
- if (ret < 0) {
- kobject_put(dev->kobj_node);
+ if (ret < 0)
return ret;
- }
dev->kobj_mem = kobject_create_and_add("mem_banks", dev->kobj_node);
if (!dev->kobj_mem)
@@ -687,10 +685,8 @@ static int kfd_build_sysfs_node_entry(struct kfd_topology_device *dev,
return -ENOMEM;
ret = kobject_init_and_add(mem->kobj, &mem_type,
dev->kobj_mem, "%d", i);
- if (ret < 0) {
- kobject_put(mem->kobj);
+ if (ret < 0)
return ret;
- }
mem->attr.name = "properties";
mem->attr.mode = KFD_SYSFS_FILE_MODE;
@@ -708,10 +704,8 @@ static int kfd_build_sysfs_node_entry(struct kfd_topology_device *dev,
return -ENOMEM;
ret = kobject_init_and_add(cache->kobj, &cache_type,
dev->kobj_cache, "%d", i);
- if (ret < 0) {
- kobject_put(cache->kobj);
+ if (ret < 0)
return ret;
- }
cache->attr.name = "properties";
cache->attr.mode = KFD_SYSFS_FILE_MODE;
@@ -729,10 +723,8 @@ static int kfd_build_sysfs_node_entry(struct kfd_topology_device *dev,
return -ENOMEM;
ret = kobject_init_and_add(iolink->kobj, &iolink_type,
dev->kobj_iolink, "%d", i);
- if (ret < 0) {
- kobject_put(iolink->kobj);
+ if (ret < 0)
return ret;
- }
iolink->attr.name = "properties";
iolink->attr.mode = KFD_SYSFS_FILE_MODE;
@@ -811,10 +803,8 @@ static int kfd_topology_update_sysfs(void)
ret = kobject_init_and_add(sys_props.kobj_topology,
&sysprops_type, &kfd_device->kobj,
"topology");
- if (ret < 0) {
- kobject_put(sys_props.kobj_topology);
+ if (ret < 0)
return ret;
- }
sys_props.kobj_nodes = kobject_create_and_add("nodes",
sys_props.kobj_topology);
--
2.31.1
This reverts commit aaa3cbbac326c95308e315f1ab964a3369c4d07d.
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.
Cc: Qiushi Wu <[email protected]>
Cc: Mathew King <[email protected]>
Cc: Enric Balletbo i Serra <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/platform/chrome/cros_ec_ishtp.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_ishtp.c b/drivers/platform/chrome/cros_ec_ishtp.c
index f00107017318..d4f41d68232c 100644
--- a/drivers/platform/chrome/cros_ec_ishtp.c
+++ b/drivers/platform/chrome/cros_ec_ishtp.c
@@ -677,10 +677,8 @@ static int cros_ec_ishtp_probe(struct ishtp_cl_device *cl_device)
/* Register croc_ec_dev mfd */
rv = cros_ec_dev_init(client_data);
- if (rv) {
- down_write(&init_lock);
+ if (rv)
goto end_cros_ec_dev_init_error;
- }
return 0;
--
2.31.1
This reverts commit 2655971ad4b34e97dd921df16bb0b08db9449df7.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Felipe Balbi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/dwc3/dwc3-pci.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 4c5c6972124a..0c0619f7b1a7 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -226,10 +226,8 @@ static void dwc3_pci_resume_work(struct work_struct *work)
int ret;
ret = pm_runtime_get_sync(&dwc3->dev);
- if (ret) {
- pm_runtime_put_sync_autosuspend(&dwc3->dev);
+ if (ret)
return;
- }
pm_runtime_mark_last_busy(&dwc3->dev);
pm_runtime_put_sync_autosuspend(&dwc3->dev);
--
2.31.1
This reverts commit 90a239ee25fa3a483facec3de7c144361a3d3a51.
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.
Cc: https
Cc: Aditya Pakki <[email protected]>
Cc: Dennis Dalessandro <[email protected]>
Cc: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/sw/rdmavt/qp.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/sw/rdmavt/qp.c b/drivers/infiniband/sw/rdmavt/qp.c
index 9d13db68283c..5476dd37e421 100644
--- a/drivers/infiniband/sw/rdmavt/qp.c
+++ b/drivers/infiniband/sw/rdmavt/qp.c
@@ -1207,7 +1207,7 @@ struct ib_qp *rvt_create_qp(struct ib_pd *ibpd,
err = alloc_ud_wq_attr(qp, rdi->dparms.node);
if (err) {
ret = (ERR_PTR(err));
- goto bail_rq_rvt;
+ goto bail_driver_priv;
}
if (init_attr->create_flags & IB_QP_CREATE_NETDEV_USE)
@@ -1317,10 +1317,8 @@ struct ib_qp *rvt_create_qp(struct ib_pd *ibpd,
rvt_free_qpn(&rdi->qp_dev->qpn_table, qp->ibqp.qp_num);
bail_rq_wq:
- free_ud_wq_attr(qp);
-
-bail_rq_rvt:
rvt_free_rq(&qp->r_rq);
+ free_ud_wq_attr(qp);
bail_driver_priv:
rdi->driver_f.qp_priv_free(rdi, qp);
--
2.31.1
This reverts commit 64157b2cb1940449e7df2670e85781c690266588.
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.
Cc: Qiushi Wu <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/exynos4-is/mipi-csis.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/mipi-csis.c b/drivers/media/platform/exynos4-is/mipi-csis.c
index 1aac167abb17..540151bbf58f 100644
--- a/drivers/media/platform/exynos4-is/mipi-csis.c
+++ b/drivers/media/platform/exynos4-is/mipi-csis.c
@@ -510,10 +510,8 @@ static int s5pcsis_s_stream(struct v4l2_subdev *sd, int enable)
if (enable) {
s5pcsis_clear_counters(state);
ret = pm_runtime_get_sync(&state->pdev->dev);
- if (ret && ret != 1) {
- pm_runtime_put_noidle(&state->pdev->dev);
+ if (ret && ret != 1)
return ret;
- }
}
mutex_lock(&state->lock);
--
2.31.1
This reverts commit 7dae2aaaf432767ca7aa11fa84643a7c2600dbdd.
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.
Cc: Qiushi Wu <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/ti-vpe/vpe.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c
index 10251b787674..c7a0a7c19ca6 100644
--- a/drivers/media/platform/ti-vpe/vpe.c
+++ b/drivers/media/platform/ti-vpe/vpe.c
@@ -2473,8 +2473,6 @@ static int vpe_runtime_get(struct platform_device *pdev)
r = pm_runtime_get_sync(&pdev->dev);
WARN_ON(r < 0);
- if (r)
- pm_runtime_put_noidle(&pdev->dev);
return r < 0 ? r : 0;
}
--
2.31.1
This reverts commit d0675b67b42eb4f1a840d1513b5b00f78312f833.
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.
Cc: Qiushi Wu <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/qcom/camss/camss-csiphy.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c b/drivers/media/platform/qcom/camss/camss-csiphy.c
index 509c9a59c09c..a5d717d022a5 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
@@ -174,10 +174,8 @@ static int csiphy_set_power(struct v4l2_subdev *sd, int on)
int ret;
ret = pm_runtime_get_sync(dev);
- if (ret < 0) {
- pm_runtime_put_sync(dev);
+ if (ret < 0)
return ret;
- }
ret = csiphy_set_clock_rates(csiphy);
if (ret < 0) {
--
2.31.1
This reverts commit 4d8be4bc94f74bb7d096e1c2e44457b530d5a170.
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.
Cc: Qiushi Wu <[email protected]>
Cc: 4.10+ <[email protected]> # 4.10+
Cc: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/acpi/cppc_acpi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
index 69057fcd2c04..42650b34e45e 100644
--- a/drivers/acpi/cppc_acpi.c
+++ b/drivers/acpi/cppc_acpi.c
@@ -830,7 +830,6 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr)
"acpi_cppc");
if (ret) {
per_cpu(cpc_desc_ptr, pr->id) = NULL;
- kobject_put(&cpc_ptr->kobj);
goto out_free;
}
--
2.31.1
This reverts commit 78741ce98c2e36188e2343434406b0e0bc50b0e7.
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.
Cc: Qiushi Wu <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
index 62d2320a7218..7d52431c2c83 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_pm.c
@@ -79,10 +79,8 @@ int s5p_mfc_power_on(void)
int i, ret = 0;
ret = pm_runtime_get_sync(pm->device);
- if (ret < 0) {
- pm_runtime_put_noidle(pm->device);
+ if (ret < 0)
return ret;
- }
/* clock control */
for (i = 0; i < pm->num_clocks; i++) {
--
2.31.1
This reverts commit 57cc666d36adc7b45e37ba4cd7bc4e44ec4c43d7.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/sti/delta/delta-v4l2.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/platform/sti/delta/delta-v4l2.c b/drivers/media/platform/sti/delta/delta-v4l2.c
index c691b3d81549..2503224eeee5 100644
--- a/drivers/media/platform/sti/delta/delta-v4l2.c
+++ b/drivers/media/platform/sti/delta/delta-v4l2.c
@@ -954,10 +954,8 @@ static void delta_run_work(struct work_struct *work)
/* enable the hardware */
if (!dec->pm) {
ret = delta_get_sync(ctx);
- if (ret) {
- delta_put_autosuspend(ctx);
+ if (ret)
goto err;
- }
}
/* decode this access unit */
--
2.31.1
This reverts commit deca195383a6085be62cb453079e03e04d618d6e.
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.
Cc: Qiushi Wu <[email protected]>
Cc: Jon Hunter <[email protected]>
Cc: https
Cc: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/tegra/tegra30_ahub.c | 4 +---
sound/soc/tegra/tegra30_i2s.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/sound/soc/tegra/tegra30_ahub.c b/sound/soc/tegra/tegra30_ahub.c
index 9ef05ca4f6c4..b116b05e4e72 100644
--- a/sound/soc/tegra/tegra30_ahub.c
+++ b/sound/soc/tegra/tegra30_ahub.c
@@ -657,10 +657,8 @@ static int tegra30_ahub_resume(struct device *dev)
int ret;
ret = pm_runtime_get_sync(dev);
- if (ret < 0) {
- pm_runtime_put(dev);
+ if (ret < 0)
return ret;
- }
ret = regcache_sync(ahub->regmap_ahub);
ret |= regcache_sync(ahub->regmap_apbif);
pm_runtime_put(dev);
diff --git a/sound/soc/tegra/tegra30_i2s.c b/sound/soc/tegra/tegra30_i2s.c
index 6740df541508..3187a0f0c07a 100644
--- a/sound/soc/tegra/tegra30_i2s.c
+++ b/sound/soc/tegra/tegra30_i2s.c
@@ -567,10 +567,8 @@ static int tegra30_i2s_resume(struct device *dev)
int ret;
ret = pm_runtime_get_sync(dev);
- if (ret < 0) {
- pm_runtime_put(dev);
+ if (ret < 0)
return ret;
- }
ret = regcache_sync(i2s->regmap);
pm_runtime_put(dev);
--
2.31.1
This reverts commit 25bf943e4e7b47282bd86ae7d39e039217ebb007.
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.
Cc: Qiushi Wu <[email protected]>
Cc: https
Cc: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/img/img-i2s-in.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/img/img-i2s-in.c b/sound/soc/img/img-i2s-in.c
index e30b66b94bf6..a495d1050d49 100644
--- a/sound/soc/img/img-i2s-in.c
+++ b/sound/soc/img/img-i2s-in.c
@@ -482,7 +482,6 @@ static int img_i2s_in_probe(struct platform_device *pdev)
if (IS_ERR(rst)) {
if (PTR_ERR(rst) == -EPROBE_DEFER) {
ret = -EPROBE_DEFER;
- pm_runtime_put(&pdev->dev);
goto err_suspend;
}
--
2.31.1
This reverts commit 7cc31613734c4870ae32f5265d576ef296621343.
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.
Cc: Qiushi Wu <[email protected]>
Cc: https
Cc: Joerg Roedel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/iommu/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d0b0a15dba84..cd22cd0e6517 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -596,7 +596,7 @@ struct iommu_group *iommu_group_alloc(void)
NULL, "%d", group->id);
if (ret) {
ida_simple_remove(&iommu_group_ida, group->id);
- kobject_put(&group->kobj);
+ kfree(group);
return ERR_PTR(ret);
}
--
2.31.1
This reverts commit db857e6ae548f0f4f4a0f63fffeeedf3cca21f9d.
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.
Cc: https
Cc: Qiushi Wu <[email protected]>
Cc: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
index 4b6019e7de67..c5f8d2da07f6 100644
--- a/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
+++ b/drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c
@@ -800,7 +800,7 @@ static int pvrdma_pci_probe(struct pci_dev *pdev,
!(pci_resource_flags(pdev, 1) & IORESOURCE_MEM)) {
dev_err(&pdev->dev, "PCI BAR region not MMIO\n");
ret = -ENOMEM;
- goto err_disable_pdev;
+ goto err_free_device;
}
ret = pci_request_regions(pdev, DRV_NAME);
--
2.31.1
This reverts commit f45d01f4f30b53c3a0a1c6c1c154acb7ff74ab9f.
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.
Cc: Qiushi Wu <[email protected]>
Cc: David Howells <[email protected]>
Cc: Markus Elfring <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/rxrpc/rxkad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index e2e9e9b0a6d7..6cdbfb4f8cda 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -1241,7 +1241,7 @@ static int rxkad_verify_response(struct rxrpc_connection *conn,
ret = rxkad_decrypt_ticket(conn, server_key, skb, ticket, ticket_len,
&session_key, &expiry, _abort_code);
if (ret < 0)
- goto temporary_error_free_ticket;
+ goto temporary_error_free_resp;
/* use the session key from inside the ticket to decrypt the
* response */
--
2.31.1
This reverts commit a6379f0ad6375a707e915518ecd5c2270afcd395.
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.
Cc: Aditya Pakki <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
lib/test_objagg.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/test_objagg.c b/lib/test_objagg.c
index da137939a410..72c1abfa154d 100644
--- a/lib/test_objagg.c
+++ b/lib/test_objagg.c
@@ -979,10 +979,10 @@ static int test_hints_case(const struct hints_case *hints_case)
err_world2_obj_get:
for (i--; i >= 0; i--)
world_obj_put(&world2, objagg, hints_case->key_ids[i]);
- i = hints_case->key_ids_count;
+ objagg_hints_put(hints);
objagg_destroy(objagg2);
+ i = hints_case->key_ids_count;
err_check_expect_hints_stats:
- objagg_hints_put(hints);
err_hints_get:
err_check_expect_stats:
err_world_obj_get:
--
2.31.1
This reverts commit b975abbd382fe442713a4c233549abb90e57c22b.
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.
Cc: Qiushi Wu <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: https
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/char/agp/intel-gtt.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 5bfdf222d5f9..4b34a5195c65 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -304,10 +304,8 @@ static int intel_gtt_setup_scratch_page(void)
if (intel_private.needs_dmar) {
dma_addr = pci_map_page(intel_private.pcidev, page, 0,
PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
- if (pci_dma_mapping_error(intel_private.pcidev, dma_addr)) {
- __free_page(page);
+ if (pci_dma_mapping_error(intel_private.pcidev, dma_addr))
return -EINVAL;
- }
intel_private.scratch_page_dma = dma_addr;
} else
--
2.31.1
This reverts commit 8d7a577d04e8ce24b1b81ee44ec8cd1dda2a9cd9.
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.
Cc: Aditya Pakki <[email protected]>
Cc: https
Cc: Chanwoo Choi <[email protected]>
Cc: Stephen Boyd <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/clk/samsung/clk.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
index 1949ae7851b2..dad31308c071 100644
--- a/drivers/clk/samsung/clk.c
+++ b/drivers/clk/samsung/clk.c
@@ -356,6 +356,10 @@ struct samsung_clk_provider * __init samsung_cmu_register_one(
}
ctx = samsung_clk_init(np, reg_base, cmu->nr_clk_ids);
+ if (!ctx) {
+ panic("%s: unable to allocate ctx\n", __func__);
+ return ctx;
+ }
if (cmu->pll_clks)
samsung_clk_register_pll(ctx, cmu->pll_clks, cmu->nr_pll_clks,
--
2.31.1
This reverts commit 1ec4c6efe23154b4ab44c1a34dbc0eb121eb614a.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/common/saa7146/saa7146_video.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/common/saa7146/saa7146_video.c b/drivers/media/common/saa7146/saa7146_video.c
index 7b8795eca589..d9d7d82ca451 100644
--- a/drivers/media/common/saa7146/saa7146_video.c
+++ b/drivers/media/common/saa7146/saa7146_video.c
@@ -345,8 +345,7 @@ static int video_begin(struct saa7146_fh *fh)
fmt = saa7146_format_by_fourcc(dev, vv->video_fmt.pixelformat);
/* we need to have a valid format set here */
- if (!fmt)
- return -EINVAL;
+ BUG_ON(NULL == fmt);
if (0 != (fmt->flags & FORMAT_IS_PLANAR)) {
resource = RESOURCE_DMA1_HPS|RESOURCE_DMA2_CLP|RESOURCE_DMA3_BRS;
@@ -399,8 +398,7 @@ static int video_end(struct saa7146_fh *fh, struct file *file)
fmt = saa7146_format_by_fourcc(dev, vv->video_fmt.pixelformat);
/* we need to have a valid format set here */
- if (!fmt)
- return -EINVAL;
+ BUG_ON(NULL == fmt);
if (0 != (fmt->flags & FORMAT_IS_PLANAR)) {
resource = RESOURCE_DMA1_HPS|RESOURCE_DMA2_CLP|RESOURCE_DMA3_BRS;
--
2.31.1
This reverts commit 2c2a7552dd6465e8fde6bc9cccf8d66ed1c1eb72.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Tyler Hicks <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ecryptfs/crypto.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
index 943e523f4c9d..3d8623139538 100644
--- a/fs/ecryptfs/crypto.c
+++ b/fs/ecryptfs/crypto.c
@@ -296,10 +296,8 @@ static int crypt_scatterlist(struct ecryptfs_crypt_stat *crypt_stat,
struct extent_crypt_result ecr;
int rc = 0;
- if (!crypt_stat || !crypt_stat->tfm
- || !(crypt_stat->flags & ECRYPTFS_STRUCT_INITIALIZED))
- return -EINVAL;
-
+ BUG_ON(!crypt_stat || !crypt_stat->tfm
+ || !(crypt_stat->flags & ECRYPTFS_STRUCT_INITIALIZED));
if (unlikely(ecryptfs_verbosity > 0)) {
ecryptfs_printk(KERN_DEBUG, "Key size [%zd]; key:\n",
crypt_stat->key_size);
--
2.31.1
This reverts commit 639c0a5b0503fb57127fa8972208d43020a9bcf6.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/common/saa7146/saa7146_fops.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/common/saa7146/saa7146_fops.c b/drivers/media/common/saa7146/saa7146_fops.c
index baf5772c52a9..c256146fd3b6 100644
--- a/drivers/media/common/saa7146/saa7146_fops.c
+++ b/drivers/media/common/saa7146/saa7146_fops.c
@@ -95,6 +95,8 @@ void saa7146_buffer_finish(struct saa7146_dev *dev,
DEB_EE("dev:%p, dmaq:%p, state:%d\n", dev, q, state);
DEB_EE("q->curr:%p\n", q->curr);
+ BUG_ON(!q->curr);
+
/* finish current buffer */
if (NULL == q->curr) {
DEB_D("aiii. no current buffer\n");
--
2.31.1
This reverts commit 67e2d2eb542338145a2e0b2336c1cdabd2424fd3.
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.
Cc: http
Cc: Aditya Pakki <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Joel Becker <[email protected]>
Cc: Junxiao Bi <[email protected]>
Cc: Joseph Qi <[email protected]>
Cc: Changwei Ge <[email protected]>
Cc: Gang He <[email protected]>
Cc: Jun Piao <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/ocfs2/dlm/dlmmaster.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/ocfs2/dlm/dlmmaster.c b/fs/ocfs2/dlm/dlmmaster.c
index f105746063ed..f89dcf9b6217 100644
--- a/fs/ocfs2/dlm/dlmmaster.c
+++ b/fs/ocfs2/dlm/dlmmaster.c
@@ -2554,6 +2554,8 @@ static int dlm_migrate_lockres(struct dlm_ctxt *dlm,
if (!dlm_grab(dlm))
return -EINVAL;
+ BUG_ON(target == O2NM_MAX_NODES);
+
name = res->lockname.name;
namelen = res->lockname.len;
--
2.31.1
This reverts commit bd4af432cc71b5fbfe4833510359a6ad3ada250d.
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.
Cc: Qiushi Wu <[email protected]>
Cc: Jakub Kicinski <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/netronome/nfp/abm/main.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/nfp/abm/main.c b/drivers/net/ethernet/netronome/nfp/abm/main.c
index bdbf0726145e..341773b43a4d 100644
--- a/drivers/net/ethernet/netronome/nfp/abm/main.c
+++ b/drivers/net/ethernet/netronome/nfp/abm/main.c
@@ -283,7 +283,6 @@ nfp_abm_vnic_set_mac(struct nfp_pf *pf, struct nfp_abm *abm, struct nfp_net *nn,
if (!nfp_nsp_has_hwinfo_lookup(nsp)) {
nfp_warn(pf->cpp, "NSP doesn't support PF MAC generation\n");
eth_hw_addr_random(nn->dp.netdev);
- nfp_nsp_close(nsp);
return;
}
--
2.31.1
This reverts commit 93a24578de721006055b422c7772e0e417e1983c.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/usb/cx231xx/cx231xx-i2c.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/usb/cx231xx/cx231xx-i2c.c b/drivers/media/usb/cx231xx/cx231xx-i2c.c
index c6659253c6fb..f33b6a077d57 100644
--- a/drivers/media/usb/cx231xx/cx231xx-i2c.c
+++ b/drivers/media/usb/cx231xx/cx231xx-i2c.c
@@ -515,8 +515,7 @@ int cx231xx_i2c_register(struct cx231xx_i2c *bus)
{
struct cx231xx *dev = bus->dev;
- if (!dev->cx231xx_send_usb_command)
- return -EINVAL;
+ BUG_ON(!dev->cx231xx_send_usb_command);
bus->i2c_adap = cx231xx_adap_template;
bus->i2c_adap.dev.parent = dev->dev;
--
2.31.1
This reverts commit b0e4cfae483fe1e3db71ab2d8509490df60e52c6.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/davinci/vpfe_capture.c | 31 +++++++++----------
1 file changed, 15 insertions(+), 16 deletions(-)
diff --git a/drivers/media/platform/davinci/vpfe_capture.c b/drivers/media/platform/davinci/vpfe_capture.c
index f9f7dd17c57c..bcedaf4523e0 100644
--- a/drivers/media/platform/davinci/vpfe_capture.c
+++ b/drivers/media/platform/davinci/vpfe_capture.c
@@ -168,22 +168,21 @@ int vpfe_register_ccdc_device(const struct ccdc_hw_device *dev)
int ret = 0;
printk(KERN_NOTICE "vpfe_register_ccdc_device: %s\n", dev->name);
- if (!dev->hw_ops.open ||
- !dev->hw_ops.enable ||
- !dev->hw_ops.set_hw_if_params ||
- !dev->hw_ops.configure ||
- !dev->hw_ops.set_buftype ||
- !dev->hw_ops.get_buftype ||
- !dev->hw_ops.enum_pix ||
- !dev->hw_ops.set_frame_format ||
- !dev->hw_ops.get_frame_format ||
- !dev->hw_ops.get_pixel_format ||
- !dev->hw_ops.set_pixel_format ||
- !dev->hw_ops.set_image_window ||
- !dev->hw_ops.get_image_window ||
- !dev->hw_ops.get_line_length ||
- !dev->hw_ops.getfid)
- return -EINVAL;
+ BUG_ON(!dev->hw_ops.open);
+ BUG_ON(!dev->hw_ops.enable);
+ BUG_ON(!dev->hw_ops.set_hw_if_params);
+ BUG_ON(!dev->hw_ops.configure);
+ BUG_ON(!dev->hw_ops.set_buftype);
+ BUG_ON(!dev->hw_ops.get_buftype);
+ BUG_ON(!dev->hw_ops.enum_pix);
+ BUG_ON(!dev->hw_ops.set_frame_format);
+ BUG_ON(!dev->hw_ops.get_frame_format);
+ BUG_ON(!dev->hw_ops.get_pixel_format);
+ BUG_ON(!dev->hw_ops.set_pixel_format);
+ BUG_ON(!dev->hw_ops.set_image_window);
+ BUG_ON(!dev->hw_ops.get_image_window);
+ BUG_ON(!dev->hw_ops.get_line_length);
+ BUG_ON(!dev->hw_ops.getfid);
mutex_lock(&ccdc_lock);
if (!ccdc_cfg) {
--
2.31.1
This reverts commit 1d7a7128a2e9e1f137c99b0a44e94d70a77343e3.
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.
Cc: [email protected]
Cc: Qiushi Wu <[email protected]>
Cc: Sebastian Reichel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/power/supply/power_supply_hwmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/supply/power_supply_hwmon.c b/drivers/power/supply/power_supply_hwmon.c
index bffe6d84c429..62ca29e0d47a 100644
--- a/drivers/power/supply/power_supply_hwmon.c
+++ b/drivers/power/supply/power_supply_hwmon.c
@@ -356,7 +356,7 @@ int power_supply_add_hwmon_sysfs(struct power_supply *psy)
goto error;
}
- ret = devm_add_action_or_reset(dev, power_supply_hwmon_bitmap_free,
+ ret = devm_add_action(dev, power_supply_hwmon_bitmap_free,
psyhw->props);
if (ret)
goto error;
--
2.31.1
This reverts commit 6b9fbb073636906eee9fe4d4c05a4f445b9e2a23.
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.
Cc: Qiushi Wu <[email protected]>
Cc: https
Cc: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/img/img-parallel-out.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/sound/soc/img/img-parallel-out.c b/sound/soc/img/img-parallel-out.c
index 4da49a42e854..5ddbe3a31c2e 100644
--- a/sound/soc/img/img-parallel-out.c
+++ b/sound/soc/img/img-parallel-out.c
@@ -163,10 +163,8 @@ static int img_prl_out_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
}
ret = pm_runtime_get_sync(prl->dev);
- if (ret < 0) {
- pm_runtime_put_noidle(prl->dev);
+ if (ret < 0)
return ret;
- }
reg = img_prl_out_readl(prl, IMG_PRL_OUT_CTL);
reg = (reg & ~IMG_PRL_OUT_CTL_EDGE_MASK) | control_set;
--
2.31.1
This reverts commit 9f48db0d4a08624bb9ba847ea40c8abad753b396.
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.
Cc: https
Cc: Aditya Pakki <[email protected]>
Cc: Bart Van Assche <[email protected]>
Cc: Jason Gunthorpe <[email protected]>
Cc: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/ulp/srpt/ib_srpt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
index 6be60aa5ffe2..b5a7c4fbf23b 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -2807,6 +2807,8 @@ static void srpt_queue_response(struct se_cmd *cmd)
int resp_len, ret, i;
u8 srp_tm_status;
+ BUG_ON(!ch);
+
state = ioctx->state;
switch (state) {
case SRPT_STATE_NEW:
--
2.31.1
This reverts commit d7a336d67ab5443a0ef14b8335d139e855e8a682.
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.
Cc: Aditya Pakki <[email protected]>
Cc: https
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/kpc2000/kpc_dma/fileops.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/kpc2000/kpc_dma/fileops.c b/drivers/staging/kpc2000/kpc_dma/fileops.c
index 10dcd6646b01..7fdad86044ca 100644
--- a/drivers/staging/kpc2000/kpc_dma/fileops.c
+++ b/drivers/staging/kpc2000/kpc_dma/fileops.c
@@ -49,7 +49,9 @@ static int kpc_dma_transfer(struct dev_private_data *priv,
u64 dma_addr;
u64 user_ctl;
+ BUG_ON(priv == NULL);
ldev = priv->ldev;
+ BUG_ON(ldev == NULL);
acd = kzalloc(sizeof(*acd), GFP_KERNEL);
if (!acd) {
--
2.31.1
This reverts commit 52b894393cecdc303990e834778d39b85d0553fc.
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.
Cc: https
Cc: Hannes Reinecke <[email protected]>
Cc: Aditya Pakki <[email protected]>
Cc: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/target/tcm_fc/tfc_io.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/target/tcm_fc/tfc_io.c b/drivers/target/tcm_fc/tfc_io.c
index bbe2e29612fa..15d557a11f63 100644
--- a/drivers/target/tcm_fc/tfc_io.c
+++ b/drivers/target/tcm_fc/tfc_io.c
@@ -220,6 +220,7 @@ void ft_recv_write_data(struct ft_cmd *cmd, struct fc_frame *fp)
ep = fc_seq_exch(seq);
lport = ep->lp;
if (cmd->was_ddp_setup) {
+ BUG_ON(!ep);
BUG_ON(!lport);
/*
* Since DDP (Large Rx offload) was setup for this request,
--
2.31.1
This reverts commit 615f22f58029aa747b12768985e7f91cd053daa2.
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.
Cc: Aditya Pakki <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/nfc/s3fwrn5/firmware.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/nfc/s3fwrn5/firmware.c b/drivers/nfc/s3fwrn5/firmware.c
index eb5d7a5beac7..f77f183c9bd0 100644
--- a/drivers/nfc/s3fwrn5/firmware.c
+++ b/drivers/nfc/s3fwrn5/firmware.c
@@ -492,10 +492,7 @@ int s3fwrn5_fw_recv_frame(struct nci_dev *ndev, struct sk_buff *skb)
struct s3fwrn5_info *info = nci_get_drvdata(ndev);
struct s3fwrn5_fw_info *fw_info = &info->fw_info;
- if (WARN_ON(fw_info->rsp)) {
- kfree_skb(skb);
- return -EINVAL;
- }
+ BUG_ON(fw_info->rsp);
fw_info->rsp = skb;
--
2.31.1
This reverts commit a2be42f18d409213bb7e7a736e3ef6ba005115bb.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/codecs/cs43130.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/sound/soc/codecs/cs43130.c b/sound/soc/codecs/cs43130.c
index 80bc7c10ed75..c2b6f0ae6d57 100644
--- a/sound/soc/codecs/cs43130.c
+++ b/sound/soc/codecs/cs43130.c
@@ -2319,8 +2319,6 @@ static int cs43130_probe(struct snd_soc_component *component)
return ret;
cs43130->wq = create_singlethread_workqueue("cs43130_hp");
- if (!cs43130->wq)
- return -ENOMEM;
INIT_WORK(&cs43130->work, cs43130_imp_meas);
}
--
2.31.1
This reverts commit c4c59b95b7f7d4cef5071b151be2dadb33f3287b.
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.
Cc: Qiushi Wu <[email protected]>
Cc: https
Cc: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/img/img-i2s-in.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/sound/soc/img/img-i2s-in.c b/sound/soc/img/img-i2s-in.c
index 0843235d73c9..e30b66b94bf6 100644
--- a/sound/soc/img/img-i2s-in.c
+++ b/sound/soc/img/img-i2s-in.c
@@ -343,10 +343,8 @@ static int img_i2s_in_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
chan_control_mask = IMG_I2S_IN_CH_CTL_CLK_TRANS_MASK;
ret = pm_runtime_get_sync(i2s->dev);
- if (ret < 0) {
- pm_runtime_put_noidle(i2s->dev);
+ if (ret < 0)
return ret;
- }
for (i = 0; i < i2s->active_channels; i++)
img_i2s_in_ch_disable(i2s, i);
--
2.31.1
This reverts commit bbd20c939c8aa3f27fa30e86691af250bf92973a.
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.
Cc: Aditya Pakki <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/atm/fore200e.c | 25 +++++++------------------
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
index 495fd0a1f040..e83286e3216e 100644
--- a/drivers/atm/fore200e.c
+++ b/drivers/atm/fore200e.c
@@ -1412,14 +1412,12 @@ fore200e_open(struct atm_vcc *vcc)
static void
fore200e_close(struct atm_vcc* vcc)
{
+ struct fore200e* fore200e = FORE200E_DEV(vcc->dev);
struct fore200e_vcc* fore200e_vcc;
- struct fore200e* fore200e;
struct fore200e_vc_map* vc_map;
unsigned long flags;
ASSERT(vcc);
- fore200e = FORE200E_DEV(vcc->dev);
-
ASSERT((vcc->vpi >= 0) && (vcc->vpi < 1<<FORE200E_VPI_BITS));
ASSERT((vcc->vci >= 0) && (vcc->vci < 1<<FORE200E_VCI_BITS));
@@ -1464,10 +1462,10 @@ fore200e_close(struct atm_vcc* vcc)
static int
fore200e_send(struct atm_vcc *vcc, struct sk_buff *skb)
{
- struct fore200e* fore200e;
- struct fore200e_vcc* fore200e_vcc;
+ struct fore200e* fore200e = FORE200E_DEV(vcc->dev);
+ struct fore200e_vcc* fore200e_vcc = FORE200E_VCC(vcc);
struct fore200e_vc_map* vc_map;
- struct host_txq* txq;
+ struct host_txq* txq = &fore200e->host_txq;
struct host_txq_entry* entry;
struct tpd* tpd;
struct tpd_haddr tpd_haddr;
@@ -1480,18 +1478,9 @@ fore200e_send(struct atm_vcc *vcc, struct sk_buff *skb)
unsigned char* data;
unsigned long flags;
- if (!vcc)
- return -EINVAL;
-
- fore200e = FORE200E_DEV(vcc->dev);
- fore200e_vcc = FORE200E_VCC(vcc);
-
- if (!fore200e)
- return -EINVAL;
-
- txq = &fore200e->host_txq;
- if (!fore200e_vcc)
- return -EINVAL;
+ ASSERT(vcc);
+ ASSERT(fore200e);
+ ASSERT(fore200e_vcc);
if (!test_bit(ATM_VF_READY, &vcc->flags)) {
DPRINTK(1, "VC %d.%d.%d not ready for tx\n", vcc->itf, vcc->vpi, vcc->vpi);
--
2.31.1
This reverts commit c343bf1ba5efcbf2266a1fe3baefec9cc82f867f.
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.
Cc: Qiushi Wu <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/cpuidle/sysfs.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
index 53ec9585ccd4..23a219cedbdb 100644
--- a/drivers/cpuidle/sysfs.c
+++ b/drivers/cpuidle/sysfs.c
@@ -487,7 +487,7 @@ static int cpuidle_add_state_sysfs(struct cpuidle_device *device)
ret = kobject_init_and_add(&kobj->kobj, &ktype_state_cpuidle,
&kdev->kobj, "state%d", i);
if (ret) {
- kobject_put(&kobj->kobj);
+ kfree(kobj);
goto error_state;
}
cpuidle_add_s2idle_attr_group(kobj);
@@ -618,7 +618,7 @@ static int cpuidle_add_driver_sysfs(struct cpuidle_device *dev)
ret = kobject_init_and_add(&kdrv->kobj, &ktype_driver_cpuidle,
&kdev->kobj, "driver");
if (ret) {
- kobject_put(&kdrv->kobj);
+ kfree(kdrv);
return ret;
}
@@ -712,7 +712,7 @@ int cpuidle_add_sysfs(struct cpuidle_device *dev)
error = kobject_init_and_add(&kdev->kobj, &ktype_cpuidle, &cpu_dev->kobj,
"cpuidle");
if (error) {
- kobject_put(&kdev->kobj);
+ kfree(kdev);
return error;
}
--
2.31.1
This reverts commit 23015b22e47c5409620b1726a677d69e5cd032ba.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Alexandre Bounine <[email protected]>
Cc: Matt Porter <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Linus Torvalds <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/rapidio/rio_cm.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/rapidio/rio_cm.c b/drivers/rapidio/rio_cm.c
index 50ec53d67a4c..e6c16f04f2b4 100644
--- a/drivers/rapidio/rio_cm.c
+++ b/drivers/rapidio/rio_cm.c
@@ -2138,14 +2138,6 @@ static int riocm_add_mport(struct device *dev,
mutex_init(&cm->rx_lock);
riocm_rx_fill(cm, RIOCM_RX_RING_SIZE);
cm->rx_wq = create_workqueue(DRV_NAME "/rxq");
- if (!cm->rx_wq) {
- riocm_error("failed to allocate IBMBOX_%d on %s",
- cmbox, mport->name);
- rio_release_outb_mbox(mport, cmbox);
- kfree(cm);
- return -ENOMEM;
- }
-
INIT_WORK(&cm->rx_work, rio_ibmsg_handler);
cm->tx_slot = 0;
--
2.31.1
This reverts commit 51dd97d1df5fb9ac58b9b358e63e67b530f6ae21.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/soc/codecs/rt5645.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 63a7e052eaa0..ab06133a85da 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -3407,9 +3407,6 @@ static int rt5645_probe(struct snd_soc_component *component)
RT5645_HWEQ_NUM, sizeof(struct rt5645_eq_param_s),
GFP_KERNEL);
- if (!rt5645->eq_param)
- return -ENOMEM;
-
return 0;
}
--
2.31.1
This reverts commit cbb88db76a1536e02e93e5bd37ebbfbb6c4043a9.
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.
Cc: Wenwen Wang <[email protected]>
Cc: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/usb/usx2y/usbusx2y.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/sound/usb/usx2y/usbusx2y.c b/sound/usb/usx2y/usbusx2y.c
index 3cd28d24f0a7..bb188245b0e2 100644
--- a/sound/usb/usx2y/usbusx2y.c
+++ b/sound/usb/usx2y/usbusx2y.c
@@ -279,8 +279,10 @@ int usX2Y_In04_init(struct usX2Ydev *usX2Y)
if (! (usX2Y->In04urb = usb_alloc_urb(0, GFP_KERNEL)))
return -ENOMEM;
- if (! (usX2Y->In04Buf = kmalloc(21, GFP_KERNEL)))
+ if (! (usX2Y->In04Buf = kmalloc(21, GFP_KERNEL))) {
+ usb_free_urb(usX2Y->In04urb);
return -ENOMEM;
+ }
init_waitqueue_head(&usX2Y->In04WaitQueue);
usb_fill_int_urb(usX2Y->In04urb, usX2Y->dev, usb_rcvintpipe(usX2Y->dev, 0x4),
--
2.31.1
This reverts commit 91862cc7867bba4ee5c8fcf0ca2f1d30427b6129.
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.
Cc: http
Cc: [email protected]
Cc: Wenwen Wang <[email protected]>
Cc: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/trace/trace.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 5c777627212f..faed4f44d224 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -691,10 +691,8 @@ int trace_pid_write(struct trace_pid_list *filtered_pids,
* not modified.
*/
pid_list = kmalloc(sizeof(*pid_list), GFP_KERNEL);
- if (!pid_list) {
- trace_parser_put(&parser);
+ if (!pid_list)
return -ENOMEM;
- }
pid_list->pid_max = READ_ONCE(pid_max);
@@ -704,7 +702,6 @@ int trace_pid_write(struct trace_pid_list *filtered_pids,
pid_list->pids = vzalloc((pid_list->pid_max + 7) >> 3);
if (!pid_list->pids) {
- trace_parser_put(&parser);
kfree(pid_list);
return -ENOMEM;
}
--
2.31.1
This reverts commit d5414c2355b20ea8201156d2e874265f1cb0d775.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/rsi/rsi_91x_mac80211.c | 30 +++++++++------------
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index 16025300cddb..714d4d53236c 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -188,27 +188,27 @@ bool rsi_is_cipher_wep(struct rsi_common *common)
* @adapter: Pointer to the adapter structure.
* @band: Operating band to be set.
*
- * Return: int - 0 on success, negative error on failure.
+ * Return: None.
*/
-static int rsi_register_rates_channels(struct rsi_hw *adapter, int band)
+static void rsi_register_rates_channels(struct rsi_hw *adapter, int band)
{
struct ieee80211_supported_band *sbands = &adapter->sbands[band];
void *channels = NULL;
if (band == NL80211_BAND_2GHZ) {
- channels = kmemdup(rsi_2ghz_channels, sizeof(rsi_2ghz_channels),
- GFP_KERNEL);
- if (!channels)
- return -ENOMEM;
+ channels = kmalloc(sizeof(rsi_2ghz_channels), GFP_KERNEL);
+ memcpy(channels,
+ rsi_2ghz_channels,
+ sizeof(rsi_2ghz_channels));
sbands->band = NL80211_BAND_2GHZ;
sbands->n_channels = ARRAY_SIZE(rsi_2ghz_channels);
sbands->bitrates = rsi_rates;
sbands->n_bitrates = ARRAY_SIZE(rsi_rates);
} else {
- channels = kmemdup(rsi_5ghz_channels, sizeof(rsi_5ghz_channels),
- GFP_KERNEL);
- if (!channels)
- return -ENOMEM;
+ channels = kmalloc(sizeof(rsi_5ghz_channels), GFP_KERNEL);
+ memcpy(channels,
+ rsi_5ghz_channels,
+ sizeof(rsi_5ghz_channels));
sbands->band = NL80211_BAND_5GHZ;
sbands->n_channels = ARRAY_SIZE(rsi_5ghz_channels);
sbands->bitrates = &rsi_rates[4];
@@ -227,7 +227,6 @@ static int rsi_register_rates_channels(struct rsi_hw *adapter, int band)
sbands->ht_cap.mcs.rx_mask[0] = 0xff;
sbands->ht_cap.mcs.tx_params = IEEE80211_HT_MCS_TX_DEFINED;
/* sbands->ht_cap.mcs.rx_highest = 0x82; */
- return 0;
}
static int rsi_mac80211_hw_scan_start(struct ieee80211_hw *hw,
@@ -2067,16 +2066,11 @@ int rsi_mac80211_attach(struct rsi_common *common)
wiphy->available_antennas_rx = 1;
wiphy->available_antennas_tx = 1;
- status = rsi_register_rates_channels(adapter, NL80211_BAND_2GHZ);
- if (status)
- return status;
+ rsi_register_rates_channels(adapter, NL80211_BAND_2GHZ);
wiphy->bands[NL80211_BAND_2GHZ] =
&adapter->sbands[NL80211_BAND_2GHZ];
if (common->num_supp_bands > 1) {
- status = rsi_register_rates_channels(adapter,
- NL80211_BAND_5GHZ);
- if (status)
- return status;
+ rsi_register_rates_channels(adapter, NL80211_BAND_5GHZ);
wiphy->bands[NL80211_BAND_5GHZ] =
&adapter->sbands[NL80211_BAND_5GHZ];
}
--
2.31.1
This reverts commit 22e8860cf8f777fbf6a83f2fb7127f682a8e9de4.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Mukesh Ojha <[email protected]>
Cc: Stefan Schmidt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ieee802154/mcr20a.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
index 8dc04e2590b1..2ce5b41983f8 100644
--- a/drivers/net/ieee802154/mcr20a.c
+++ b/drivers/net/ieee802154/mcr20a.c
@@ -524,8 +524,6 @@ mcr20a_start(struct ieee802154_hw *hw)
dev_dbg(printdev(lp), "no slotted operation\n");
ret = regmap_update_bits(lp->regmap_dar, DAR_PHY_CTRL1,
DAR_PHY_CTRL1_SLOTTED, 0x0);
- if (ret < 0)
- return ret;
/* enable irq */
enable_irq(lp->spi->irq);
@@ -533,15 +531,11 @@ mcr20a_start(struct ieee802154_hw *hw)
/* Unmask SEQ interrupt */
ret = regmap_update_bits(lp->regmap_dar, DAR_PHY_CTRL2,
DAR_PHY_CTRL2_SEQMSK, 0x0);
- if (ret < 0)
- return ret;
/* Start the RX sequence */
dev_dbg(printdev(lp), "start the RX sequence\n");
ret = regmap_update_bits(lp->regmap_dar, DAR_PHY_CTRL1,
DAR_PHY_CTRL1_XCVSEQ_MASK, MCR20A_XCVSEQ_RX);
- if (ret < 0)
- return ret;
return 0;
}
--
2.31.1
This reverts commit ea094d53580f40c2124cef3d072b73b2425e7bfd.
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.
Cc: Wenwen Wang <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/pci/irq.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index d3a73f9335e1..52e55108404e 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1119,8 +1119,6 @@ static const struct dmi_system_id pciirq_dmi_table[] __initconst = {
void __init pcibios_irq_init(void)
{
- struct irq_routing_table *rtable = NULL;
-
DBG(KERN_DEBUG "PCI: IRQ init\n");
if (raw_pci_ops == NULL)
@@ -1131,10 +1129,8 @@ void __init pcibios_irq_init(void)
pirq_table = pirq_find_routing_table();
#ifdef CONFIG_PCI_BIOS
- if (!pirq_table && (pci_probe & PCI_BIOS_IRQ_SCAN)) {
+ if (!pirq_table && (pci_probe & PCI_BIOS_IRQ_SCAN))
pirq_table = pcibios_get_irq_routing_table();
- rtable = pirq_table;
- }
#endif
if (pirq_table) {
pirq_peer_trick();
@@ -1149,10 +1145,8 @@ void __init pcibios_irq_init(void)
* If we're using the I/O APIC, avoid using the PCI IRQ
* routing table
*/
- if (io_apic_assign_pci_irqs) {
- kfree(rtable);
+ if (io_apic_assign_pci_irqs)
pirq_table = NULL;
- }
}
x86_init.pci.fixup_irqs();
--
2.31.1
This reverts commit 70c4cf17e445264453bc5323db3e50aa0ac9e81f.
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.
Cc: Wenwen Wang <[email protected]>
Cc: Richard Guy Briggs <[email protected]>
Cc: Paul Moore <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
kernel/auditfilter.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 333b3bcfc545..19f908b96000 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -1125,24 +1125,22 @@ int audit_rule_change(int type, int seq, void *data, size_t datasz)
int err = 0;
struct audit_entry *entry;
+ entry = audit_data_to_entry(data, datasz);
+ if (IS_ERR(entry))
+ return PTR_ERR(entry);
+
switch (type) {
case AUDIT_ADD_RULE:
- entry = audit_data_to_entry(data, datasz);
- if (IS_ERR(entry))
- return PTR_ERR(entry);
err = audit_add_rule(entry);
audit_log_rule_change("add_rule", &entry->rule, !err);
break;
case AUDIT_DEL_RULE:
- entry = audit_data_to_entry(data, datasz);
- if (IS_ERR(entry))
- return PTR_ERR(entry);
err = audit_del_rule(entry);
audit_log_rule_change("remove_rule", &entry->rule, !err);
break;
default:
+ err = -EINVAL;
WARN_ON(1);
- return -EINVAL;
}
if (err || type == AUDIT_DEL_RULE) {
--
2.31.1
This reverts commit 1ee7826ab68f7e9fa1a01533983acf6a6f62e297.
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.
Cc: Aditya Pakki <[email protected]>
Cc: https
Cc: Johannes Berg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/mac80211/util.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index c0fa526a45b4..2de2e655be59 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -39,6 +39,7 @@ const void *const mac80211_wiphy_privid = &mac80211_wiphy_privid;
struct ieee80211_hw *wiphy_to_ieee80211_hw(struct wiphy *wiphy)
{
struct ieee80211_local *local;
+ BUG_ON(!wiphy);
local = wiphy_priv(wiphy);
return &local->hw;
--
2.31.1
This reverts commit 39416c5872db69859e867fa250b9cbb3f1e0d185.
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.
Cc: Wenwen Wang <[email protected]>
Cc: Jan Kara <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
fs/udf/namei.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/fs/udf/namei.c b/fs/udf/namei.c
index f146b3089f3d..77906b679187 100644
--- a/fs/udf/namei.c
+++ b/fs/udf/namei.c
@@ -304,6 +304,21 @@ static struct dentry *udf_lookup(struct inode *dir, struct dentry *dentry,
if (dentry->d_name.len > UDF_NAME_LEN)
return ERR_PTR(-ENAMETOOLONG);
+#ifdef UDF_RECOVERY
+ /* temporary shorthand for specifying files by inode number */
+ if (!strncmp(dentry->d_name.name, ".B=", 3)) {
+ struct kernel_lb_addr lb = {
+ .logicalBlockNum = 0,
+ .partitionReferenceNum =
+ simple_strtoul(dentry->d_name.name + 3,
+ NULL, 0),
+ };
+ inode = udf_iget(dir->i_sb, lb);
+ if (IS_ERR(inode))
+ return inode;
+ } else
+#endif /* UDF_RECOVERY */
+
fi = udf_find_entry(dir, &dentry->d_name, &fibh, &cfi);
if (IS_ERR(fi))
return ERR_CAST(fi);
--
2.31.1
This reverts commit 611025983b7976df0183390a63a2166411d177f1.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Ulf Hansson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mmc/host/mmc_spi.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index 02f4fd26e76a..cc40b050e302 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -800,10 +800,6 @@ mmc_spi_readblock(struct mmc_spi_host *host, struct spi_transfer *t,
}
status = spi_sync_locked(spi, &host->m);
- if (status < 0) {
- dev_dbg(&spi->dev, "read error %d\n", status);
- return status;
- }
if (host->dma_dev) {
dma_sync_single_for_cpu(host->dma_dev,
--
2.31.1
This reverts commit e183d4e414b64711baf7a04e214b61969ca08dfa.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Ursula Braun <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/smc/smc_ism.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/net/smc/smc_ism.c b/net/smc/smc_ism.c
index 9c6e95882553..6558cf7643a7 100644
--- a/net/smc/smc_ism.c
+++ b/net/smc/smc_ism.c
@@ -417,11 +417,6 @@ struct smcd_dev *smcd_alloc_dev(struct device *parent, const char *name,
init_waitqueue_head(&smcd->lgrs_deleted);
smcd->event_wq = alloc_ordered_workqueue("ism_evt_wq-%s)",
WQ_MEM_RECLAIM, name);
- if (!smcd->event_wq) {
- kfree(smcd->conn);
- kfree(smcd);
- return NULL;
- }
return smcd;
}
EXPORT_SYMBOL_GPL(smcd_alloc_dev);
--
2.31.1
This reverts commit 1adc90c7395742827d754a5f02f446818a77c379.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Linus Walleij <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pinctrl/pinctrl-axp209.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-axp209.c b/drivers/pinctrl/pinctrl-axp209.c
index 207cbae3a7bf..58f7149dd39b 100644
--- a/drivers/pinctrl/pinctrl-axp209.c
+++ b/drivers/pinctrl/pinctrl-axp209.c
@@ -365,8 +365,6 @@ static int axp20x_build_funcs_groups(struct platform_device *pdev)
pctl->funcs[i].groups = devm_kcalloc(&pdev->dev,
npins, sizeof(char *),
GFP_KERNEL);
- if (!pctl->funcs[i].groups)
- return -ENOMEM;
for (pin = 0; pin < npins; pin++)
pctl->funcs[i].groups[pin] = pctl->desc->pins[pin].name;
}
--
2.31.1
This reverts commit 507b820009a457afa78202da337bcb56791fbb12.
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.
Cc: Kangjie Lu <[email protected]>
Cc: commit log and code update]
Cc: Lorenzo Pieralisi <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pci/endpoint/functions/pci-epf-test.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
index c0ac4e9cbe72..39dd394284a5 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -915,11 +915,6 @@ static int __init pci_epf_test_init(void)
kpcitest_workqueue = alloc_workqueue("kpcitest",
WQ_MEM_RECLAIM | WQ_HIGHPRI, 0);
- if (!kpcitest_workqueue) {
- pr_err("Failed to allocate the kpcitest work queue\n");
- return -ENOMEM;
- }
-
ret = pci_epf_register_driver(&test_driver);
if (ret) {
pr_err("Failed to register pci epf test driver --> %d\n", ret);
--
2.31.1
This reverts commit 536cc27deade8f1ec3c1beefa60d5fbe0f6fcb28.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Jonathan Cameron <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/iio/magnetometer/hmc5843_i2c.c | 7 +------
drivers/iio/magnetometer/hmc5843_spi.c | 7 +------
2 files changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/iio/magnetometer/hmc5843_i2c.c b/drivers/iio/magnetometer/hmc5843_i2c.c
index 67fe657fdb3e..9a4491233d08 100644
--- a/drivers/iio/magnetometer/hmc5843_i2c.c
+++ b/drivers/iio/magnetometer/hmc5843_i2c.c
@@ -55,13 +55,8 @@ static const struct regmap_config hmc5843_i2c_regmap_config = {
static int hmc5843_i2c_probe(struct i2c_client *cli,
const struct i2c_device_id *id)
{
- struct regmap *regmap = devm_regmap_init_i2c(cli,
- &hmc5843_i2c_regmap_config);
- if (IS_ERR(regmap))
- return PTR_ERR(regmap);
-
return hmc5843_common_probe(&cli->dev,
- regmap,
+ devm_regmap_init_i2c(cli, &hmc5843_i2c_regmap_config),
id->driver_data, id->name);
}
diff --git a/drivers/iio/magnetometer/hmc5843_spi.c b/drivers/iio/magnetometer/hmc5843_spi.c
index d827554c346e..58bdbc7257ec 100644
--- a/drivers/iio/magnetometer/hmc5843_spi.c
+++ b/drivers/iio/magnetometer/hmc5843_spi.c
@@ -55,7 +55,6 @@ static const struct regmap_config hmc5843_spi_regmap_config = {
static int hmc5843_spi_probe(struct spi_device *spi)
{
int ret;
- struct regmap *regmap;
const struct spi_device_id *id = spi_get_device_id(spi);
spi->mode = SPI_MODE_3;
@@ -65,12 +64,8 @@ static int hmc5843_spi_probe(struct spi_device *spi)
if (ret)
return ret;
- regmap = devm_regmap_init_spi(spi, &hmc5843_spi_regmap_config);
- if (IS_ERR(regmap))
- return PTR_ERR(regmap);
-
return hmc5843_common_probe(&spi->dev,
- regmap,
+ devm_regmap_init_spi(spi, &hmc5843_spi_regmap_config),
id->driver_data, id->name);
}
--
2.31.1
This reverts commit 765976285a8c8db3f0eb7f033829a899d0c2786e.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/realtek/rtlwifi/base.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c b/drivers/net/wireless/realtek/rtlwifi/base.c
index 6e8bd99e8911..1d067536889e 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -452,11 +452,6 @@ static void _rtl_init_deferred_work(struct ieee80211_hw *hw)
/* <2> work queue */
rtlpriv->works.hw = hw;
rtlpriv->works.rtl_wq = alloc_workqueue("%s", 0, 0, rtlpriv->cfg->name);
- if (unlikely(!rtlpriv->works.rtl_wq)) {
- pr_err("Failed to allocate work queue\n");
- return;
- }
-
INIT_DELAYED_WORK(&rtlpriv->works.watchdog_wq,
rtl_watchdog_wq_callback);
INIT_DELAYED_WORK(&rtlpriv->works.ips_nic_off_wq,
--
2.31.1
This reverts commit e5b9b206f3f6376b9a1406b67eafe4e7bb9f123c.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/marvell/mwifiex/cmdevt.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
index 3a11342a6bde..bda8a236e386 100644
--- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
+++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
@@ -339,12 +339,6 @@ static int mwifiex_dnld_sleep_confirm_cmd(struct mwifiex_adapter *adapter)
sleep_cfm_tmp =
dev_alloc_skb(sizeof(struct mwifiex_opt_sleep_confirm)
+ MWIFIEX_TYPE_LEN);
- if (!sleep_cfm_tmp) {
- mwifiex_dbg(adapter, ERROR,
- "SLEEP_CFM: dev_alloc_skb failed\n");
- return -ENOMEM;
- }
-
skb_put(sleep_cfm_tmp, sizeof(struct mwifiex_opt_sleep_confirm)
+ MWIFIEX_TYPE_LEN);
put_unaligned_le32(MWIFIEX_USB_TYPE_CMD, sleep_cfm_tmp->data);
--
2.31.1
This reverts commit ec7f6aad57ad29e4e66cc2e18e1e1599ddb02542.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Aditya Pakki <[email protected]>
Cc: Ferenc Bakonyi <[email protected]>
Cc: Bartlomiej Zolnierkiewicz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/video/fbdev/hgafb.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/fbdev/hgafb.c b/drivers/video/fbdev/hgafb.c
index 8bbac7182ad3..fca29f219f8b 100644
--- a/drivers/video/fbdev/hgafb.c
+++ b/drivers/video/fbdev/hgafb.c
@@ -285,8 +285,6 @@ static int hga_card_detect(void)
hga_vram_len = 0x08000;
hga_vram = ioremap(0xb0000, hga_vram_len);
- if (!hga_vram)
- goto error;
if (request_region(0x3b0, 12, "hgafb"))
release_io_ports = 1;
--
2.31.1
This reverts commit 1d84353d205a953e2381044953b7fa31c8c9702d.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Aditya Pakki <[email protected]>
Cc: Finn Thain <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Bartlomiej Zolnierkiewicz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/video/fbdev/imsttfb.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c
index 3ac053b88495..e04411701ec8 100644
--- a/drivers/video/fbdev/imsttfb.c
+++ b/drivers/video/fbdev/imsttfb.c
@@ -1512,11 +1512,6 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
info->fix.smem_start = addr;
info->screen_base = (__u8 *)ioremap(addr, par->ramdac == IBM ?
0x400000 : 0x800000);
- if (!info->screen_base) {
- release_mem_region(addr, size);
- framebuffer_release(info);
- return -ENOMEM;
- }
info->fix.mmio_start = addr + 0x800000;
par->dc_regs = ioremap(addr + 0x800000, 0x1000);
par->cmap_regs_phys = addr + 0x840000;
--
2.31.1
This reverts commit 75cf4f5aa903604e1bd7bec2c0988d643c6fb946.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Sebastian Reichel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/power/supply/charger-manager.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/power/supply/charger-manager.c b/drivers/power/supply/charger-manager.c
index 4dea8ecd70bc..f34c07ffcfe6 100644
--- a/drivers/power/supply/charger-manager.c
+++ b/drivers/power/supply/charger-manager.c
@@ -1749,9 +1749,6 @@ static struct platform_driver charger_manager_driver = {
static int __init charger_manager_init(void)
{
cm_wq = create_freezable_workqueue("charger_manager");
- if (unlikely(!cm_wq))
- return -ENOMEM;
-
INIT_DELAYED_WORK(&cm_monitor_work, cm_monitor_poller);
return platform_driver_register(&charger_manager_driver);
--
2.31.1
This reverts commit 6fc232db9e8cd50b9b83534de9cd91ace711b2d7.
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.
Cc: Aditya Pakki <[email protected]>
Cc: https
Cc: Johannes Berg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/rfkill/core.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index ac15a944573f..8a27164d7f5f 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -1033,13 +1033,10 @@ static void rfkill_sync_work(struct work_struct *work)
int __must_check rfkill_register(struct rfkill *rfkill)
{
static unsigned long rfkill_no;
- struct device *dev;
+ struct device *dev = &rfkill->dev;
int error;
- if (!rfkill)
- return -EINVAL;
-
- dev = &rfkill->dev;
+ BUG_ON(!rfkill);
mutex_lock(&rfkill_global_mutex);
--
2.31.1
This reverts commit 57a25a5f754ce27da2cfa6f413cfd366f878db76.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: https
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 5d3302249779..f89c2088dc2d 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -405,8 +405,6 @@ static bool cdv_intel_find_dp_pll(const struct gma_limit_t *limit,
struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
struct gma_clock_t clock;
- memset(&clock, 0, sizeof(clock));
-
switch (refclk) {
case 27000:
if (target < 200000) {
--
2.31.1
This reverts commit 02a896ca84874bbfcedc006303f2951dda89b298.
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.
Cc: Aditya Pakki <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ppp/pppoe.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
index d7f50b835050..803a4fe1ca18 100644
--- a/drivers/net/ppp/pppoe.c
+++ b/drivers/net/ppp/pppoe.c
@@ -119,6 +119,8 @@ static inline bool stage_session(__be16 sid)
static inline struct pppoe_net *pppoe_pernet(struct net *net)
{
+ BUG_ON(!net);
+
return net_generic(net, pppoe_net_id);
}
--
2.31.1
This reverts commit d39083234c60519724c6ed59509a2129fd2aed41.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Geert Uytterhoeven <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/rcar_drif.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/platform/rcar_drif.c b/drivers/media/platform/rcar_drif.c
index 83bd9a412a56..1e3b68a8743a 100644
--- a/drivers/media/platform/rcar_drif.c
+++ b/drivers/media/platform/rcar_drif.c
@@ -915,7 +915,6 @@ static int rcar_drif_g_fmt_sdr_cap(struct file *file, void *priv,
{
struct rcar_drif_sdr *sdr = video_drvdata(file);
- memset(f->fmt.sdr.reserved, 0, sizeof(f->fmt.sdr.reserved));
f->fmt.sdr.pixelformat = sdr->fmt->pixelformat;
f->fmt.sdr.buffersize = sdr->fmt->buffersize;
--
2.31.1
This reverts commit 20d437ee8f4899573e6ea76c06ef0206e98bccb6.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Andrew Bowers <[email protected]>
Cc: Mukesh Ojha <[email protected]>
Cc: Jeff Kirsher <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/intel/ixgbevf/vf.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
index bfe6dfcec4ab..501823f2d1c0 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
@@ -508,8 +508,9 @@ static s32 ixgbevf_update_mc_addr_list_vf(struct ixgbe_hw *hw,
vector_list[i++] = ixgbevf_mta_vector(hw, ha->addr);
}
- return ixgbevf_write_msg_read_ack(hw, msgbuf, msgbuf,
- IXGBE_VFMAILBOX_SIZE);
+ ixgbevf_write_msg_read_ack(hw, msgbuf, msgbuf, IXGBE_VFMAILBOX_SIZE);
+
+ return 0;
}
/**
--
2.31.1
This reverts commit 699ca30162686bf305cdf94861be02eb0cf9bda2.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Lorenzo Pieralisi <[email protected]>
Cc: Steven Price <[email protected]>
Cc: Mukesh Ojha <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/pci/controller/pcie-xilinx.c | 12 ++----------
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/drivers/pci/controller/pcie-xilinx.c b/drivers/pci/controller/pcie-xilinx.c
index fa5baeb82653..942c25bf7980 100644
--- a/drivers/pci/controller/pcie-xilinx.c
+++ b/drivers/pci/controller/pcie-xilinx.c
@@ -326,19 +326,14 @@ static const struct irq_domain_ops msi_domain_ops = {
* xilinx_pcie_enable_msi - Enable MSI support
* @port: PCIe port information
*/
-static int xilinx_pcie_enable_msi(struct xilinx_pcie_port *port)
+static void xilinx_pcie_enable_msi(struct xilinx_pcie_port *port)
{
phys_addr_t msg_addr;
port->msi_pages = __get_free_pages(GFP_KERNEL, 0);
- if (!port->msi_pages)
- return -ENOMEM;
-
msg_addr = virt_to_phys((void *)port->msi_pages);
pcie_write(port, 0x0, XILINX_PCIE_REG_MSIBASE1);
pcie_write(port, msg_addr, XILINX_PCIE_REG_MSIBASE2);
-
- return 0;
}
/* INTx Functions */
@@ -493,7 +488,6 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)
struct device *dev = port->dev;
struct device_node *node = dev->of_node;
struct device_node *pcie_intc_node;
- int ret;
/* Setup INTx */
pcie_intc_node = of_get_next_child(node, NULL);
@@ -522,9 +516,7 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)
return -ENODEV;
}
- ret = xilinx_pcie_enable_msi(port);
- if (ret)
- return ret;
+ xilinx_pcie_enable_msi(port);
}
return 0;
--
2.31.1
This reverts commit b5af36e3e5aa074605a4d90a89dd8f714b30909b.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Vaibhav Agarwal <[email protected]>
Cc: Viresh Kumar <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/greybus/audio_manager.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/staging/greybus/audio_manager.c b/drivers/staging/greybus/audio_manager.c
index 9a3f7c034ab4..7c7ca671876d 100644
--- a/drivers/staging/greybus/audio_manager.c
+++ b/drivers/staging/greybus/audio_manager.c
@@ -45,9 +45,6 @@ int gb_audio_manager_add(struct gb_audio_manager_module_descriptor *desc)
int err;
id = ida_simple_get(&module_id, 0, 0, GFP_KERNEL);
- if (id < 0)
- return id;
-
err = gb_audio_manager_module_create(&module, manager_kset,
id, desc);
if (err) {
--
2.31.1
This reverts commit 31fa6e2ae65feed0de10823c5d1eea21a93086c9.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Kangjie Lu <[email protected]>
Cc: Bartlomiej Zolnierkiewicz <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c b/drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c
index 0ae0cab252d3..05d87dcbdd8b 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c
@@ -100,8 +100,6 @@ static void __init omapdss_omapify_node(struct device_node *node)
new_len = prop->length + strlen(prefix) * num_strs;
new_compat = kmalloc(new_len, GFP_KERNEL);
- if (!new_compat)
- return;
omapdss_prefix_strcpy(new_compat, new_len, prop->value, prop->length);
--
2.31.1
This reverts commit aeb0d0f581e2079868e64a2e5ee346d340376eae.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/video-mux.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/media/platform/video-mux.c b/drivers/media/platform/video-mux.c
index 133122e38515..a754e20850c2 100644
--- a/drivers/media/platform/video-mux.c
+++ b/drivers/media/platform/video-mux.c
@@ -442,14 +442,9 @@ static int video_mux_probe(struct platform_device *pdev)
vmux->active = -1;
vmux->pads = devm_kcalloc(dev, num_pads, sizeof(*vmux->pads),
GFP_KERNEL);
- if (!vmux->pads)
- return -ENOMEM;
-
vmux->format_mbus = devm_kcalloc(dev, num_pads,
sizeof(*vmux->format_mbus),
GFP_KERNEL);
- if (!vmux->format_mbus)
- return -ENOMEM;
for (i = 0; i < num_pads; i++) {
vmux->pads[i].flags = (i < num_pads - 1) ? MEDIA_PAD_FL_SINK
--
2.31.1
This reverts commit 60f5c4aaae452ae9252128ef7f9ae222aa70c569.
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.
Cc: Aditya Pakki <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/atm/clip.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/atm/clip.c b/net/atm/clip.c
index 294cb9efe3d3..a7972da7235d 100644
--- a/net/atm/clip.c
+++ b/net/atm/clip.c
@@ -89,7 +89,7 @@ static void unlink_clip_vcc(struct clip_vcc *clip_vcc)
struct clip_vcc **walk;
if (!entry) {
- pr_err("!clip_vcc->entry (clip_vcc %p)\n", clip_vcc);
+ pr_crit("!clip_vcc->entry (clip_vcc %p)\n", clip_vcc);
return;
}
netif_tx_lock_bh(entry->neigh->dev); /* block clip_start_xmit() */
@@ -109,10 +109,10 @@ static void unlink_clip_vcc(struct clip_vcc *clip_vcc)
error = neigh_update(entry->neigh, NULL, NUD_NONE,
NEIGH_UPDATE_F_ADMIN, 0);
if (error)
- pr_err("neigh_update failed with %d\n", error);
+ pr_crit("neigh_update failed with %d\n", error);
goto out;
}
- pr_err("ATMARP: failed (entry %p, vcc 0x%p)\n", entry, clip_vcc);
+ pr_crit("ATMARP: failed (entry %p, vcc 0x%p)\n", entry, clip_vcc);
out:
netif_tx_unlock_bh(entry->neigh->dev);
}
--
2.31.1
This reverts commit c5dea815834c7d2e9fc633785455bc428b7a1956.
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.
Cc: Aditya Pakki <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/caif/caif_serial.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/caif/caif_serial.c b/drivers/net/caif/caif_serial.c
index 8215cd77301f..4720a7bac4fb 100644
--- a/drivers/net/caif/caif_serial.c
+++ b/drivers/net/caif/caif_serial.c
@@ -269,9 +269,7 @@ static netdev_tx_t caif_xmit(struct sk_buff *skb, struct net_device *dev)
{
struct ser_device *ser;
- if (WARN_ON(!dev))
- return -EINVAL;
-
+ BUG_ON(dev == NULL);
ser = netdev_priv(dev);
/* Send flow off once, on high water mark */
--
2.31.1
This reverts commit 1bbb1c318cd8a3a39e8c3e2e83d5e90542d6c3e3.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David Sterba <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/ipwireless/main.c | 8 --------
1 file changed, 8 deletions(-)
diff --git a/drivers/tty/ipwireless/main.c b/drivers/tty/ipwireless/main.c
index 4c18bbfe1a92..3475e841ef5c 100644
--- a/drivers/tty/ipwireless/main.c
+++ b/drivers/tty/ipwireless/main.c
@@ -114,10 +114,6 @@ static int ipwireless_probe(struct pcmcia_device *p_dev, void *priv_data)
ipw->common_memory = ioremap(p_dev->resource[2]->start,
resource_size(p_dev->resource[2]));
- if (!ipw->common_memory) {
- ret = -ENOMEM;
- goto exit1;
- }
if (!request_mem_region(p_dev->resource[2]->start,
resource_size(p_dev->resource[2]),
IPWIRELESS_PCCARD_NAME)) {
@@ -138,10 +134,6 @@ static int ipwireless_probe(struct pcmcia_device *p_dev, void *priv_data)
ipw->attr_memory = ioremap(p_dev->resource[3]->start,
resource_size(p_dev->resource[3]));
- if (!ipw->attr_memory) {
- ret = -ENOMEM;
- goto exit3;
- }
if (!request_mem_region(p_dev->resource[3]->start,
resource_size(p_dev->resource[3]),
IPWIRELESS_PCCARD_NAME)) {
--
2.31.1
This reverts commit e4dfdd5804cce1255f99c5dd033526a18135a616.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Mika Westerberg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/thunderbolt/property.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/thunderbolt/property.c b/drivers/thunderbolt/property.c
index 841314deb446..ee76449524a3 100644
--- a/drivers/thunderbolt/property.c
+++ b/drivers/thunderbolt/property.c
@@ -176,10 +176,6 @@ static struct tb_property_dir *__tb_property_parse_dir(const u32 *block,
} else {
dir->uuid = kmemdup(&block[dir_offset], sizeof(*dir->uuid),
GFP_KERNEL);
- if (!dir->uuid) {
- tb_property_free_dir(dir);
- return NULL;
- }
content_offset = dir_offset + 4;
content_len = dir_len - 4; /* Length includes UUID */
}
--
2.31.1
This reverts commit 106204b56f60abf1bead7dceb88f2be3e34433da.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Mika Westerberg <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/thunderbolt/property.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/thunderbolt/property.c b/drivers/thunderbolt/property.c
index ee76449524a3..b2f0d6386cee 100644
--- a/drivers/thunderbolt/property.c
+++ b/drivers/thunderbolt/property.c
@@ -548,11 +548,6 @@ int tb_property_add_data(struct tb_property_dir *parent, const char *key,
property->length = size / 4;
property->value.data = kzalloc(size, GFP_KERNEL);
- if (!property->value.data) {
- kfree(property);
- return -ENOMEM;
- }
-
memcpy(property->value.data, buf, buflen);
list_add_tail(&property->list, &parent->properties);
--
2.31.1
This reverts commit 6734330654dac550f12e932996b868c6d0dcb421.
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.
Cc: Kangjie Lu <[email protected]>
Cc: stable <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/serial/mxs-auart.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index f414d6acad69..edad6ebbdfd5 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -1644,10 +1644,6 @@ static int mxs_auart_probe(struct platform_device *pdev)
s->port.mapbase = r->start;
s->port.membase = ioremap(r->start, resource_size(r));
- if (!s->port.membase) {
- ret = -ENOMEM;
- goto out_disable_clks;
- }
s->port.ops = &mxs_auart_ops;
s->port.iotype = UPIO_MEM;
s->port.fifosize = MXS_AUART_FIFO_SIZE;
--
2.31.1
This reverts commit c85be041065c0be8bc48eda4c45e0319caf1d0e5.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Richard Genoud <[email protected]>
Cc: stable <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/serial/atmel_serial.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index a24e5c2b30bc..9786d8e5f04f 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1256,10 +1256,6 @@ static int atmel_prepare_rx_dma(struct uart_port *port)
sg_dma_len(&atmel_port->sg_rx)/2,
DMA_DEV_TO_MEM,
DMA_PREP_INTERRUPT);
- if (!desc) {
- dev_err(port->dev, "Preparing DMA cyclic failed\n");
- goto chan_err;
- }
desc->callback = atmel_complete_rx_dma;
desc->callback_param = port;
atmel_port->desc_rx = desc;
--
2.31.1
This reverts commit 0ab34a08812a3334350dbaf69a018ee0ab3d2ddd.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Matthias Schwarzott <[email protected]>
Cc: Matthias Schwarzott <[email protected]>
Cc: Sean Young <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/dvb-frontends/si2165.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb-frontends/si2165.c b/drivers/media/dvb-frontends/si2165.c
index ebee230afb7b..dc39543e0db1 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -266,20 +266,18 @@ static u32 si2165_get_fe_clk(struct si2165_state *state)
static int si2165_wait_init_done(struct si2165_state *state)
{
- int ret;
+ int ret = -EINVAL;
u8 val = 0;
int i;
for (i = 0; i < 3; ++i) {
- ret = si2165_readreg8(state, REG_INIT_DONE, &val);
- if (ret < 0)
- return ret;
+ si2165_readreg8(state, REG_INIT_DONE, &val);
if (val == 0x01)
return 0;
usleep_range(1000, 50000);
}
dev_err(&state->client->dev, "init_done was not set\n");
- return -EINVAL;
+ return ret;
}
static int si2165_upload_firmware_block(struct si2165_state *state,
--
2.31.1
This reverts commit 63a06181d7ce169d09843645c50fea1901bc9f0a.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Avri Altman <[email protected]>
Cc: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/ufs/ufs-hisi.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-hisi.c b/drivers/scsi/ufs/ufs-hisi.c
index 0aa58131e791..7d1e07a9d9dd 100644
--- a/drivers/scsi/ufs/ufs-hisi.c
+++ b/drivers/scsi/ufs/ufs-hisi.c
@@ -468,10 +468,6 @@ static int ufs_hisi_init_common(struct ufs_hba *hba)
ufshcd_set_variant(hba, host);
host->rst = devm_reset_control_get(dev, "rst");
- if (IS_ERR(host->rst)) {
- dev_err(dev, "%s: failed to get reset control\n", __func__);
- return PTR_ERR(host->rst);
- }
ufs_hisi_set_pm_lvl(hba);
--
2.31.1
This reverts commit 32f47179833b63de72427131169809065db6745e.
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.
Cc: Aditya Pakki <[email protected]>
Cc: stable <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/serial/mvebu-uart.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
index e0c00a1b0763..51b0ecabf2ec 100644
--- a/drivers/tty/serial/mvebu-uart.c
+++ b/drivers/tty/serial/mvebu-uart.c
@@ -818,9 +818,6 @@ static int mvebu_uart_probe(struct platform_device *pdev)
return -EINVAL;
}
- if (!match)
- return -ENODEV;
-
/* Assume that all UART ports have a DT alias or none has */
id = of_alias_get_id(pdev->dev.of_node, "serial");
if (!pdev->dev.of_node || id < 0)
--
2.31.1
This reverts commit 6c44b15e1c9076d925d5236ddadf1318b0a25ce2.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Jiri Kosina <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/hid/hid-logitech-hidpp.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index d459e2dbe647..cb73febbe893 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -2547,13 +2547,6 @@ static int hidpp_ff_init(struct hidpp_device *hidpp,
kfree(data);
return -ENOMEM;
}
- data->wq = create_singlethread_workqueue("hidpp-ff-sendqueue");
- if (!data->wq) {
- kfree(data->effect_ids);
- kfree(data);
- return -ENOMEM;
- }
-
data->hidpp = hidpp;
data->version = version;
for (j = 0; j < num_slots; j++)
@@ -2575,6 +2568,7 @@ static int hidpp_ff_init(struct hidpp_device *hidpp,
hid_warn(hidpp->hid_dev, "Unable to create sysfs interface for \"range\", errno %d!\n", error);
/* init the hardware command queue */
+ data->wq = create_singlethread_workqueue("hidpp-ff-sendqueue");
atomic_set(&data->workqueue_size, 0);
hid_info(hid, "Force feedback support loaded (firmware release %d).\n",
--
2.31.1
This reverts commit 6d65561f3d5ec933151939c543d006b79044e7a6.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Pablo Neira Ayuso <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/netfilter/ip6t_srh.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/net/ipv6/netfilter/ip6t_srh.c b/net/ipv6/netfilter/ip6t_srh.c
index db0fd64d8986..f172702257a7 100644
--- a/net/ipv6/netfilter/ip6t_srh.c
+++ b/net/ipv6/netfilter/ip6t_srh.c
@@ -206,8 +206,6 @@ static bool srh1_mt6(const struct sk_buff *skb, struct xt_action_param *par)
psidoff = srhoff + sizeof(struct ipv6_sr_hdr) +
((srh->segments_left + 1) * sizeof(struct in6_addr));
psid = skb_header_pointer(skb, psidoff, sizeof(_psid), &_psid);
- if (!psid)
- return false;
if (NF_SRH_INVF(srhinfo, IP6T_SRH_INV_PSID,
ipv6_masked_addr_cmp(psid, &srhinfo->psid_msk,
&srhinfo->psid_addr)))
@@ -221,8 +219,6 @@ static bool srh1_mt6(const struct sk_buff *skb, struct xt_action_param *par)
nsidoff = srhoff + sizeof(struct ipv6_sr_hdr) +
((srh->segments_left - 1) * sizeof(struct in6_addr));
nsid = skb_header_pointer(skb, nsidoff, sizeof(_nsid), &_nsid);
- if (!nsid)
- return false;
if (NF_SRH_INVF(srhinfo, IP6T_SRH_INV_NSID,
ipv6_masked_addr_cmp(nsid, &srhinfo->nsid_msk,
&srhinfo->nsid_addr)))
@@ -233,8 +229,6 @@ static bool srh1_mt6(const struct sk_buff *skb, struct xt_action_param *par)
if (srhinfo->mt_flags & IP6T_SRH_LSID) {
lsidoff = srhoff + sizeof(struct ipv6_sr_hdr);
lsid = skb_header_pointer(skb, lsidoff, sizeof(_lsid), &_lsid);
- if (!lsid)
- return false;
if (NF_SRH_INVF(srhinfo, IP6T_SRH_INV_LSID,
ipv6_masked_addr_cmp(lsid, &srhinfo->lsid_msk,
&srhinfo->lsid_addr)))
--
2.31.1
This reverts commit f37d8e67f39e6d3eaf4cc5471e8a3d21209843c6.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/spi/spi-topcliff-pch.c | 15 ++-------------
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/spi/spi-topcliff-pch.c b/drivers/spi/spi-topcliff-pch.c
index b459e369079f..12d749e9436b 100644
--- a/drivers/spi/spi-topcliff-pch.c
+++ b/drivers/spi/spi-topcliff-pch.c
@@ -1290,27 +1290,18 @@ static void pch_free_dma_buf(struct pch_spi_board_data *board_dat,
dma->rx_buf_virt, dma->rx_buf_dma);
}
-static int pch_alloc_dma_buf(struct pch_spi_board_data *board_dat,
+static void pch_alloc_dma_buf(struct pch_spi_board_data *board_dat,
struct pch_spi_data *data)
{
struct pch_spi_dma_ctrl *dma;
- int ret;
dma = &data->dma;
- ret = 0;
/* Get Consistent memory for Tx DMA */
dma->tx_buf_virt = dma_alloc_coherent(&board_dat->pdev->dev,
PCH_BUF_SIZE, &dma->tx_buf_dma, GFP_KERNEL);
- if (!dma->tx_buf_virt)
- ret = -ENOMEM;
-
/* Get Consistent memory for Rx DMA */
dma->rx_buf_virt = dma_alloc_coherent(&board_dat->pdev->dev,
PCH_BUF_SIZE, &dma->rx_buf_dma, GFP_KERNEL);
- if (!dma->rx_buf_virt)
- ret = -ENOMEM;
-
- return ret;
}
static int pch_spi_pd_probe(struct platform_device *plat_dev)
@@ -1387,9 +1378,7 @@ static int pch_spi_pd_probe(struct platform_device *plat_dev)
if (use_dma) {
dev_info(&plat_dev->dev, "Use DMA for data transfers\n");
- ret = pch_alloc_dma_buf(board_dat, data);
- if (ret)
- goto err_spi_register_master;
+ pch_alloc_dma_buf(board_dat, data);
}
ret = spi_register_master(master);
--
2.31.1
This reverts commit c7cbc3e937b885c9394bf9d0ca21ceb75c2ac262.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/8390/pcnet_cs.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/net/ethernet/8390/pcnet_cs.c b/drivers/net/ethernet/8390/pcnet_cs.c
index 9d3b1e0e425c..0a408fa2b7a4 100644
--- a/drivers/net/ethernet/8390/pcnet_cs.c
+++ b/drivers/net/ethernet/8390/pcnet_cs.c
@@ -289,11 +289,6 @@ static struct hw_info *get_hwinfo(struct pcmcia_device *link)
virt = ioremap(link->resource[2]->start,
resource_size(link->resource[2]));
- if (unlikely(!virt)) {
- pcmcia_release_window(link, link->resource[2]);
- return NULL;
- }
-
for (i = 0; i < NR_INFO; i++) {
pcmcia_map_mem_page(link, link->resource[2],
hw_info[i].offset & ~(resource_size(link->resource[2])-1));
@@ -1430,11 +1425,6 @@ static int setup_shmem_window(struct pcmcia_device *link, int start_pg,
/* Try scribbling on the buffer */
info->base = ioremap(link->resource[3]->start,
resource_size(link->resource[3]));
- if (unlikely(!info->base)) {
- ret = -ENOMEM;
- goto failed;
- }
-
for (i = 0; i < (TX_PAGES<<8); i += 2)
__raw_writew((i>>1), info->base+offset+i);
udelay(100);
--
2.31.1
This reverts commit 9f4d6358e11bbc7b839f9419636188e4151fb6e4.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/fujitsu/fmvj18x_cs.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/ethernet/fujitsu/fmvj18x_cs.c b/drivers/net/ethernet/fujitsu/fmvj18x_cs.c
index a7b7a4aace79..dc90c61fc827 100644
--- a/drivers/net/ethernet/fujitsu/fmvj18x_cs.c
+++ b/drivers/net/ethernet/fujitsu/fmvj18x_cs.c
@@ -547,11 +547,6 @@ static int fmvj18x_get_hwinfo(struct pcmcia_device *link, u_char *node_id)
return -1;
base = ioremap(link->resource[2]->start, resource_size(link->resource[2]));
- if (!base) {
- pcmcia_release_window(link, link->resource[2]);
- return -ENOMEM;
- }
-
pcmcia_map_mem_page(link, link->resource[2], 0);
/*
--
2.31.1
This reverts commit eb32cfcdef2305dc0e44a65d42801315669bb27e.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/qlogic/qla3xxx.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c b/drivers/net/ethernet/qlogic/qla3xxx.c
index 214e347097a7..50dbb8205e6c 100644
--- a/drivers/net/ethernet/qlogic/qla3xxx.c
+++ b/drivers/net/ethernet/qlogic/qla3xxx.c
@@ -3863,12 +3863,6 @@ static int ql3xxx_probe(struct pci_dev *pdev,
netif_stop_queue(ndev);
qdev->workqueue = create_singlethread_workqueue(ndev->name);
- if (!qdev->workqueue) {
- unregister_netdev(ndev);
- err = -ENOMEM;
- goto err_out_iounmap;
- }
-
INIT_DELAYED_WORK(&qdev->reset_work, ql_reset_work);
INIT_DELAYED_WORK(&qdev->tx_timeout_work, ql_tx_timeout_work);
INIT_DELAYED_WORK(&qdev->link_state_work, ql_link_state_machine_work);
--
2.31.1
This reverts commit e406f12dde1a8375d77ea02d91f313fb1a9c6aec.
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.
Cc: [email protected] # v3.16+
Cc: Guoqing Jiang <[email protected]>
Cc: Aditya Pakki <[email protected]>
Cc: Song Liu <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/md/raid10.c | 2 --
drivers/md/raid5.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index a9ae7d113492..4fec1cdd4207 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -3896,8 +3896,6 @@ static int raid10_run(struct mddev *mddev)
set_bit(MD_RECOVERY_RUNNING, &mddev->recovery);
mddev->sync_thread = md_register_thread(md_do_sync, mddev,
"reshape");
- if (!mddev->sync_thread)
- goto out_free_conf;
}
return 0;
diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
index 5d57a5bd171f..9b2bd50beee7 100644
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -7677,8 +7677,6 @@ static int raid5_run(struct mddev *mddev)
set_bit(MD_RECOVERY_RUNNING, &mddev->recovery);
mddev->sync_thread = md_register_thread(md_do_sync, mddev,
"reshape");
- if (!mddev->sync_thread)
- goto abort;
}
/* Ok, everything is just fine now */
--
2.31.1
This reverts commit 4589e28db46ee4961edfd794c5bb43887d38c8e5.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/tipc/group.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/tipc/group.c b/net/tipc/group.c
index 3e137d8c9d2f..d18d497af4de 100644
--- a/net/tipc/group.c
+++ b/net/tipc/group.c
@@ -927,9 +927,6 @@ int tipc_group_fill_sock_diag(struct tipc_group *grp, struct sk_buff *skb)
{
struct nlattr *group = nla_nest_start_noflag(skb, TIPC_NLA_SOCK_GROUP);
- if (!group)
- return -EMSGSIZE;
-
if (nla_put_u32(skb, TIPC_NLA_SOCK_GROUP_ID,
grp->type) ||
nla_put_u32(skb, TIPC_NLA_SOCK_GROUP_INSTANCE,
--
2.31.1
This reverts commit dcd0feac9bab901d5739de51b3f69840851f8919.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/isa/sb/sb8.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/sound/isa/sb/sb8.c b/sound/isa/sb/sb8.c
index 6c9d534ce8b6..95290ffe5c6e 100644
--- a/sound/isa/sb/sb8.c
+++ b/sound/isa/sb/sb8.c
@@ -95,10 +95,6 @@ static int snd_sb8_probe(struct device *pdev, unsigned int dev)
/* block the 0x388 port to avoid PnP conflicts */
acard->fm_res = request_region(0x388, 4, "SoundBlaster FM");
- if (!acard->fm_res) {
- err = -EBUSY;
- goto _err;
- }
if (port[dev] != SNDRV_AUTO_PORT) {
if ((err = snd_sbdsp_create(card, port[dev], irq[dev],
--
2.31.1
This reverts commit 6f19893b644a9454d85e593b5e90914e7a72b7dd.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/openvswitch/datapath.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 9d6ef6cb9b26..99e63f4bbcaf 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -443,10 +443,6 @@ static int queue_userspace_packet(struct datapath *dp, struct sk_buff *skb,
upcall = genlmsg_put(user_skb, 0, 0, &dp_packet_genl_family,
0, upcall_info->cmd);
- if (!upcall) {
- err = -EINVAL;
- goto out;
- }
upcall->dp_ifindex = dp_ifindex;
err = ovs_nla_put_key(key, key, OVS_PACKET_ATTR_KEY, false, user_skb);
--
2.31.1
This reverts commit 228cd2dba27cee9956c1af97e6445be056881e41.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/strparser/strparser.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/strparser/strparser.c b/net/strparser/strparser.c
index b3815c1e8f2e..efce4ddaa320 100644
--- a/net/strparser/strparser.c
+++ b/net/strparser/strparser.c
@@ -542,8 +542,6 @@ EXPORT_SYMBOL_GPL(strp_check_rcv);
static int __init strp_dev_init(void)
{
strp_wq = create_singlethread_workqueue("kstrp");
- if (unlikely(!strp_wq))
- return -ENOMEM;
return 0;
}
--
2.31.1
This reverts commit 5bf7295fe34a5251b1d241b9736af4697b590670.
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.
Cc: Aditya Pakki <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
index d8a3ecaed3fc..985cf8cb2ec0 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
@@ -1047,8 +1047,6 @@ int qlcnic_do_lb_test(struct qlcnic_adapter *adapter, u8 mode)
for (i = 0; i < QLCNIC_NUM_ILB_PKT; i++) {
skb = netdev_alloc_skb(adapter->netdev, QLCNIC_ILB_PKT_SIZE);
- if (!skb)
- break;
qlcnic_create_loopback_buff(skb->data, adapter->mac_addr);
skb_put(skb, QLCNIC_ILB_PKT_SIZE);
adapter->ahw->diag_cnt = 0;
--
2.31.1
This reverts commit a2c6433ee5a35a8de6d563f6512a26f87835ea0f.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/usb/usx2y/usb_stream.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/sound/usb/usx2y/usb_stream.c b/sound/usb/usx2y/usb_stream.c
index 091c071b270a..6bba17bf689a 100644
--- a/sound/usb/usx2y/usb_stream.c
+++ b/sound/usb/usx2y/usb_stream.c
@@ -91,12 +91,7 @@ static int init_urbs(struct usb_stream_kernel *sk, unsigned use_packsize,
for (u = 0; u < USB_STREAM_NURBS; ++u) {
sk->inurb[u] = usb_alloc_urb(sk->n_o_ps, GFP_KERNEL);
- if (!sk->inurb[u])
- return -ENOMEM;
-
sk->outurb[u] = usb_alloc_urb(sk->n_o_ps, GFP_KERNEL);
- if (!sk->outurb[u])
- return -ENOMEM;
}
if (init_pipe_urbs(sk, use_packsize, sk->inurb, indata, dev, in_pipe) ||
--
2.31.1
This reverts commit 3de3dbe7c13210171ba8411e36b409a2c29c7415.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/host/u132-hcd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
index eb96e1e15b71..2b7bcbe2df4b 100644
--- a/drivers/usb/host/u132-hcd.c
+++ b/drivers/usb/host/u132-hcd.c
@@ -3195,8 +3195,6 @@ static int __init u132_hcd_init(void)
return -ENODEV;
printk(KERN_INFO "driver %s\n", hcd_name);
workqueue = create_singlethread_workqueue("u132");
- if (!workqueue)
- return -ENOMEM;
retval = platform_driver_register(&u132_platform_driver);
if (retval)
destroy_workqueue(workqueue);
--
2.31.1
This reverts commit 2e84f116afca3719c9d0a1a78b47b48f75fd5724.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: Borislav Petkov <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Joe Perches <[email protected]>
Cc: Nicolai Stange <[email protected]>
Cc: Roland Dreier <[email protected]>
Cc: https
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
arch/x86/kernel/hpet.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index 08651a4e6aa0..0515a97bf6f5 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -930,8 +930,6 @@ int __init hpet_enable(void)
return 0;
hpet_set_mapping();
- if (!hpet_virt_address)
- return 0;
/* Validate that the config register is working */
if (!hpet_cfg_working())
--
2.31.1
This reverts commit b05ae01fdb8966afff5b153e7a7ee24684745e2d.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/misc/ics932s401.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/misc/ics932s401.c b/drivers/misc/ics932s401.c
index 2bdf560ee681..733e5c2b57ce 100644
--- a/drivers/misc/ics932s401.c
+++ b/drivers/misc/ics932s401.c
@@ -133,8 +133,6 @@ static struct ics932s401_data *ics932s401_update_device(struct device *dev)
*/
for (i = 0; i < NUM_MIRRORED_REGS; i++) {
temp = i2c_smbus_read_word_data(client, regs_to_copy[i]);
- if (temp < 0)
- data->regs[regs_to_copy[i]] = 0;
data->regs[regs_to_copy[i]] = temp >> 8;
}
--
2.31.1
This reverts commit e85bb0beb6498c0dffe18a2f1f16d575bc175c32.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Dmitry Torokhov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/input/touchscreen/ad7879.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/input/touchscreen/ad7879.c b/drivers/input/touchscreen/ad7879.c
index e850853328f1..8c4f3c193550 100644
--- a/drivers/input/touchscreen/ad7879.c
+++ b/drivers/input/touchscreen/ad7879.c
@@ -245,14 +245,11 @@ static void ad7879_timer(struct timer_list *t)
static irqreturn_t ad7879_irq(int irq, void *handle)
{
struct ad7879 *ts = handle;
- int error;
- error = regmap_bulk_read(ts->regmap, AD7879_REG_XPLUS,
- ts->conversion_data, AD7879_NR_SENSE);
- if (error)
- dev_err_ratelimited(ts->dev, "failed to read %#02x: %d\n",
- AD7879_REG_XPLUS, error);
- else if (!ad7879_report(ts))
+ regmap_bulk_read(ts->regmap, AD7879_REG_XPLUS,
+ ts->conversion_data, AD7879_NR_SENSE);
+
+ if (!ad7879_report(ts))
mod_timer(&ts->timer, jiffies + TS_PEN_UP_TIMEOUT);
return IRQ_HANDLED;
--
2.31.1
This reverts commit 5ceaf5452c1b2a452dadaf377f9f07af7bda9cc3.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/usb/gspca/cpia1.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/media/usb/gspca/cpia1.c b/drivers/media/usb/gspca/cpia1.c
index d93d384286c1..99e594559a0c 100644
--- a/drivers/media/usb/gspca/cpia1.c
+++ b/drivers/media/usb/gspca/cpia1.c
@@ -537,14 +537,10 @@ static int do_command(struct gspca_dev *gspca_dev, u16 command,
}
if (sd->params.qx3.button) {
/* button pressed - unlock the latch */
- ret = do_command(gspca_dev, CPIA_COMMAND_WriteMCPort,
+ do_command(gspca_dev, CPIA_COMMAND_WriteMCPort,
3, 0xdf, 0xdf, 0);
- if (ret)
- return ret;
- ret = do_command(gspca_dev, CPIA_COMMAND_WriteMCPort,
+ do_command(gspca_dev, CPIA_COMMAND_WriteMCPort,
3, 0xff, 0xff, 0);
- if (ret)
- return ret;
}
/* test whether microscope is cradled */
--
2.31.1
This reverts commit 51f689cc11333944c7a457f25ec75fcb41e99410.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/tty/serial/max310x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index 1b61d26bb7af..93f69b66b896 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -1518,10 +1518,10 @@ static int __init max310x_uart_init(void)
return ret;
#ifdef CONFIG_SPI_MASTER
- ret = spi_register_driver(&max310x_spi_driver);
+ spi_register_driver(&max310x_spi_driver);
#endif
- return ret;
+ return 0;
}
module_init(max310x_uart_init);
--
2.31.1
This reverts commit fc6a6521556c8250e356ddc6a3f2391aa62dc976.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/ath/ath6kl/wmi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c b/drivers/net/wireless/ath/ath6kl/wmi.c
index b137e7f34397..aca9732ec1ee 100644
--- a/drivers/net/wireless/ath/ath6kl/wmi.c
+++ b/drivers/net/wireless/ath/ath6kl/wmi.c
@@ -776,8 +776,10 @@ int ath6kl_wmi_set_roam_lrssi_cmd(struct wmi *wmi, u8 lrssi)
cmd->info.params.roam_rssi_floor = DEF_LRSSI_ROAM_FLOOR;
cmd->roam_ctrl = WMI_SET_LRSSI_SCAN_PARAMS;
- return ath6kl_wmi_cmd_send(wmi, 0, skb, WMI_SET_ROAM_CTRL_CMDID,
+ ath6kl_wmi_cmd_send(wmi, 0, skb, WMI_SET_ROAM_CTRL_CMDID,
NO_SYNC_WMIFLAG);
+
+ return 0;
}
int ath6kl_wmi_force_roam_cmd(struct wmi *wmi, const u8 *bssid)
--
2.31.1
This reverts commit 94edd87a1c59f3efa6fdf4e98d6d492e6cec6173.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Devesh Sharma <[email protected]>
Cc: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/hw/bnxt_re/qplib_sp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/bnxt_re/qplib_sp.c b/drivers/infiniband/hw/bnxt_re/qplib_sp.c
index 049b3576302b..c9cc03e2130c 100644
--- a/drivers/infiniband/hw/bnxt_re/qplib_sp.c
+++ b/drivers/infiniband/hw/bnxt_re/qplib_sp.c
@@ -775,8 +775,9 @@ int bnxt_qplib_map_tc2cos(struct bnxt_qplib_res *res, u16 *cids)
req.cos0 = cpu_to_le16(cids[0]);
req.cos1 = cpu_to_le16(cids[1]);
- return bnxt_qplib_rcfw_send_message(rcfw, (void *)&req, (void *)&resp,
- NULL, 0);
+ bnxt_qplib_rcfw_send_message(rcfw, (void *)&req, (void *)&resp, NULL,
+ 0);
+ return 0;
}
int bnxt_qplib_get_roce_stats(struct bnxt_qplib_rcfw *rcfw,
--
2.31.1
This reverts commit 9e28989d41c0eab57ec0bb156617a8757406ff8a.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Lee Jones <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/mfd/mc13xxx-core.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
index 1abe7432aad8..b2beb7c39cc5 100644
--- a/drivers/mfd/mc13xxx-core.c
+++ b/drivers/mfd/mc13xxx-core.c
@@ -271,9 +271,7 @@ int mc13xxx_adc_do_conversion(struct mc13xxx *mc13xxx, unsigned int mode,
mc13xxx->adcflags |= MC13XXX_ADC_WORKING;
- ret = mc13xxx_reg_read(mc13xxx, MC13XXX_ADC0, &old_adc0);
- if (ret)
- goto out;
+ mc13xxx_reg_read(mc13xxx, MC13XXX_ADC0, &old_adc0);
adc0 = MC13XXX_ADC0_ADINC1 | MC13XXX_ADC0_ADINC2 |
MC13XXX_ADC0_CHRGRAWDIV;
--
2.31.1
This reverts commit 093c48213ee37c3c3ff1cf5ac1aa2a9d8bc66017.
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.
Cc: Wenwen Wang <[email protected]>
Cc: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/cdrom/gdrom.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/cdrom/gdrom.c b/drivers/cdrom/gdrom.c
index 9874fc1c815b..466fc3eee8bb 100644
--- a/drivers/cdrom/gdrom.c
+++ b/drivers/cdrom/gdrom.c
@@ -863,7 +863,6 @@ static void __exit exit_gdrom(void)
platform_device_unregister(pd);
platform_driver_unregister(&gdrom_driver);
kfree(gd.toc);
- kfree(gd.cd_info);
}
module_init(init_gdrom);
--
2.31.1
This reverts commit 92ee77d148bf06d8c52664be4d1b862583fd5c0e.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 1767c60056c5..f1a70b37227f 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -7328,8 +7328,6 @@ static int mvpp2_probe(struct platform_device *pdev)
if (has_acpi_companion(&pdev->dev)) {
acpi_id = acpi_match_device(pdev->dev.driver->acpi_match_table,
&pdev->dev);
- if (!acpi_id)
- return -EINVAL;
priv->hw_version = (unsigned long)acpi_id->driver_data;
} else {
priv->hw_version =
--
2.31.1
This reverts commit 2d822f2dbab7f4c820f72eb8570aacf3f35855bd.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/ti/cpts.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
index 43222a34cba0..60fde1bb9665 100644
--- a/drivers/net/ethernet/ti/cpts.c
+++ b/drivers/net/ethernet/ti/cpts.c
@@ -778,9 +778,7 @@ struct cpts *cpts_create(struct device *dev, void __iomem *regs,
return ERR_CAST(cpts->refclk);
}
- ret = clk_prepare(cpts->refclk);
- if (ret)
- return ERR_PTR(ret);
+ clk_prepare(cpts->refclk);
cpts->cc.read = cpts_systim_read;
cpts->cc.mask = CLOCKSOURCE_MASK(32);
--
2.31.1
This reverts commit 6f12e46eebf1a7d4fdd66df5e815df96b8f8b1b5.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Sebastian Reichel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/power/supply/twl4030_charger.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/power/supply/twl4030_charger.c b/drivers/power/supply/twl4030_charger.c
index 1bc49b2e12e8..dcbd9f03f31a 100644
--- a/drivers/power/supply/twl4030_charger.c
+++ b/drivers/power/supply/twl4030_charger.c
@@ -805,9 +805,7 @@ static int twl4030_bci_get_property(struct power_supply *psy,
is_charging = state & TWL4030_MSTATEC_AC;
if (!is_charging) {
u8 s;
- ret = twl4030_bci_read(TWL4030_BCIMDEN, &s);
- if (ret < 0)
- return ret;
+ twl4030_bci_read(TWL4030_BCIMDEN, &s);
if (psy->desc->type == POWER_SUPPLY_TYPE_USB)
is_charging = s & 1;
else
--
2.31.1
This reverts commit beae77170c60aa786f3e4599c18ead2854d8694d.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/isa/sb/sb16_main.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/sound/isa/sb/sb16_main.c b/sound/isa/sb/sb16_main.c
index 38dc1fde25f3..aa4870531023 100644
--- a/sound/isa/sb/sb16_main.c
+++ b/sound/isa/sb/sb16_main.c
@@ -846,14 +846,10 @@ int snd_sb16dsp_pcm(struct snd_sb *chip, int device)
snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &snd_sb16_playback_ops);
snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &snd_sb16_capture_ops);
- if (chip->dma16 >= 0 && chip->dma8 != chip->dma16) {
- err = snd_ctl_add(card, snd_ctl_new1(
- &snd_sb16_dma_control, chip));
- if (err)
- return err;
- } else {
+ if (chip->dma16 >= 0 && chip->dma8 != chip->dma16)
+ snd_ctl_add(card, snd_ctl_new1(&snd_sb16_dma_control, chip));
+ else
pcm->info_flags = SNDRV_PCM_INFO_HALF_DUPLEX;
- }
snd_pcm_set_managed_buffer_all(pcm, SNDRV_DMA_TYPE_DEV,
card->dev, 64*1024, 128*1024);
--
2.31.1
This reverts commit 0781168e23a2fc8dceb989f11fc5b39b3ccacc35.
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.
Cc: Wenwen Wang <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/hamradio/yam.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c
index 5ab53e9942f3..616db3a0d2f4 100644
--- a/drivers/net/hamradio/yam.c
+++ b/drivers/net/hamradio/yam.c
@@ -951,8 +951,6 @@ static int yam_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
sizeof(struct yamdrv_ioctl_mcs));
if (IS_ERR(ym))
return PTR_ERR(ym);
- if (ym->cmd != SIOCYAMSMCS)
- return -EINVAL;
if (ym->bitrate > YAM_MAXBITRATE) {
kfree(ym);
return -EINVAL;
@@ -968,8 +966,6 @@ static int yam_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
if (copy_from_user(&yi, ifr->ifr_data, sizeof(struct yamdrv_ioctl_cfg)))
return -EFAULT;
- if (yi.cmd != SIOCYAMSCFG)
- return -EINVAL;
if ((yi.cfg.mask & YAM_IOBASE) && netif_running(dev))
return -EINVAL; /* Cannot change this parameter when up */
if ((yi.cfg.mask & YAM_IRQ) && netif_running(dev))
--
2.31.1
This reverts commit 2c05d88818ab6571816b93edce4d53703870d7ae.
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.
Cc: Wenwen Wang <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 17 -----------------
1 file changed, 17 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
index 84ad7261e243..cc6314aa0154 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
@@ -2157,8 +2157,6 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EPERM;
if (copy_from_user(&t, useraddr, sizeof(t)))
return -EFAULT;
- if (t.cmd != CHELSIO_SET_QSET_PARAMS)
- return -EINVAL;
if (t.qset_idx >= SGE_QSETS)
return -EINVAL;
if (!in_range(t.intr_lat, 0, M_NEWTIMER) ||
@@ -2258,9 +2256,6 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
if (copy_from_user(&t, useraddr, sizeof(t)))
return -EFAULT;
- if (t.cmd != CHELSIO_GET_QSET_PARAMS)
- return -EINVAL;
-
/* Display qsets for all ports when offload enabled */
if (test_bit(OFFLOAD_DEVMAP_BIT, &adapter->open_device_map)) {
q1 = 0;
@@ -2306,8 +2301,6 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EBUSY;
if (copy_from_user(&edata, useraddr, sizeof(edata)))
return -EFAULT;
- if (edata.cmd != CHELSIO_SET_QSET_NUM)
- return -EINVAL;
if (edata.val < 1 ||
(edata.val > 1 && !(adapter->flags & USING_MSIX)))
return -EINVAL;
@@ -2348,8 +2341,6 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EPERM;
if (copy_from_user(&t, useraddr, sizeof(t)))
return -EFAULT;
- if (t.cmd != CHELSIO_LOAD_FW)
- return -EINVAL;
/* Check t.len sanity ? */
fw_data = memdup_user(useraddr + sizeof(t), t.len);
if (IS_ERR(fw_data))
@@ -2373,8 +2364,6 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EBUSY;
if (copy_from_user(&m, useraddr, sizeof(m)))
return -EFAULT;
- if (m.cmd != CHELSIO_SETMTUTAB)
- return -EINVAL;
if (m.nmtus != NMTUS)
return -EINVAL;
if (m.mtus[0] < 81) /* accommodate SACK */
@@ -2416,8 +2405,6 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EBUSY;
if (copy_from_user(&m, useraddr, sizeof(m)))
return -EFAULT;
- if (m.cmd != CHELSIO_SET_PM)
- return -EINVAL;
if (!is_power_of_2(m.rx_pg_sz) ||
!is_power_of_2(m.tx_pg_sz))
return -EINVAL; /* not power of 2 */
@@ -2453,8 +2440,6 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EIO; /* need the memory controllers */
if (copy_from_user(&t, useraddr, sizeof(t)))
return -EFAULT;
- if (t.cmd != CHELSIO_GET_MEM)
- return -EINVAL;
if ((t.addr & 7) || (t.len & 7))
return -EINVAL;
if (t.mem_id == MEM_CM)
@@ -2507,8 +2492,6 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EAGAIN;
if (copy_from_user(&t, useraddr, sizeof(t)))
return -EFAULT;
- if (t.cmd != CHELSIO_SET_TRACE_FILTER)
- return -EINVAL;
tp = (const struct trace_params *)&t.sip;
if (t.config_tx)
--
2.31.1
This reverts commit 7c97381e7a9a5ec359007c0d491a143e3d9f787c.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Vinod Koul <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/dma/mv_xor.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
index 23b232b57518..78bd52565571 100644
--- a/drivers/dma/mv_xor.c
+++ b/drivers/dma/mv_xor.c
@@ -1144,10 +1144,7 @@ mv_xor_channel_add(struct mv_xor_device *xordev,
dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask) ? "cpy " : "",
dma_has_cap(DMA_INTERRUPT, dma_dev->cap_mask) ? "intr " : "");
- ret = dma_async_device_register(dma_dev);
- if (ret)
- goto err_free_irq;
-
+ dma_async_device_register(dma_dev);
return mv_chan;
err_free_irq:
--
2.31.1
This reverts commit 656025850074f5c1ba2e05be37bda57ba2b8d491.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/usb/gspca/m5602/m5602_mt9m111.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/usb/gspca/m5602/m5602_mt9m111.c b/drivers/media/usb/gspca/m5602/m5602_mt9m111.c
index bfa3b381d8a2..50481dc928d0 100644
--- a/drivers/media/usb/gspca/m5602/m5602_mt9m111.c
+++ b/drivers/media/usb/gspca/m5602/m5602_mt9m111.c
@@ -195,7 +195,7 @@ static const struct v4l2_ctrl_config mt9m111_greenbal_cfg = {
int mt9m111_probe(struct sd *sd)
{
u8 data[2] = {0x00, 0x00};
- int i, rc = 0;
+ int i;
struct gspca_dev *gspca_dev = (struct gspca_dev *)sd;
if (force_sensor) {
@@ -213,18 +213,16 @@ int mt9m111_probe(struct sd *sd)
/* Do the preinit */
for (i = 0; i < ARRAY_SIZE(preinit_mt9m111); i++) {
if (preinit_mt9m111[i][0] == BRIDGE) {
- rc |= m5602_write_bridge(sd,
+ m5602_write_bridge(sd,
preinit_mt9m111[i][1],
preinit_mt9m111[i][2]);
} else {
data[0] = preinit_mt9m111[i][2];
data[1] = preinit_mt9m111[i][3];
- rc |= m5602_write_sensor(sd,
+ m5602_write_sensor(sd,
preinit_mt9m111[i][1], data, 2);
}
}
- if (rc < 0)
- return rc;
if (m5602_read_sensor(sd, MT9M111_SC_CHIPVER, data, 2))
return -ENODEV;
--
2.31.1
This reverts commit 2bb3207dbbd4d30e96dd0e1c8e013104193bd59c.
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.
Cc: Wenwen Wang <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ethtool/ioctl.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
index 771688e1b0da..807bc9465add 100644
--- a/net/ethtool/ioctl.c
+++ b/net/ethtool/ioctl.c
@@ -876,9 +876,6 @@ static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev,
return -EINVAL;
}
- if (info.cmd != cmd)
- return -EINVAL;
-
if (info.cmd == ETHTOOL_GRXCLSRLALL) {
if (info.rule_cnt > 0) {
if (info.rule_cnt <= KMALLOC_MAX_SIZE / sizeof(u32))
--
2.31.1
This reverts commit 42daad3343be4a4e1ee03e30a5f5cc731dadfef5.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
index 586f4dfc638b..d2a803fc8ac6 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
@@ -1586,10 +1586,6 @@ void brcmf_usb_exit(void)
void brcmf_usb_register(void)
{
- int ret;
-
brcmf_dbg(USB, "Enter\n");
- ret = usb_register(&brcmf_usbdrvr);
- if (ret)
- brcmf_err("usb_register failed %d\n", ret);
+ usb_register(&brcmf_usbdrvr);
}
--
2.31.1
This reverts commit d656fe49e33df48ee6bc19e871f5862f49895c9e.
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.
Cc: Wenwen Wang <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ethtool/ioctl.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
index 807bc9465add..542f2428014c 100644
--- a/net/ethtool/ioctl.c
+++ b/net/ethtool/ioctl.c
@@ -869,11 +869,6 @@ static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev,
info_size = sizeof(info);
if (copy_from_user(&info, useraddr, info_size))
return -EFAULT;
- /* Since malicious users may modify the original data,
- * we need to check whether FLOW_RSS is still requested.
- */
- if (!(info.flow_type & FLOW_RSS))
- return -EINVAL;
}
if (info.cmd == ETHTOOL_GRXCLSRLALL) {
--
2.31.1
This reverts commit 800a7340ab7dd667edf95e74d8e4f23a17e87076.
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.
Cc: [email protected]
Cc: Wenwen Wang <[email protected]>
Cc: Mike Snitzer <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/md/dm-ioctl.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
index 1ca65b434f1f..820342de92cd 100644
--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -1747,7 +1747,8 @@ static void free_params(struct dm_ioctl *param, size_t param_size, int param_fla
}
static int copy_params(struct dm_ioctl __user *user, struct dm_ioctl *param_kernel,
- int ioctl_flags, struct dm_ioctl **param, int *param_flags)
+ int ioctl_flags,
+ struct dm_ioctl **param, int *param_flags)
{
struct dm_ioctl *dmi;
int secure_data;
@@ -1788,13 +1789,18 @@ static int copy_params(struct dm_ioctl __user *user, struct dm_ioctl *param_kern
*param_flags |= DM_PARAMS_MALLOC;
- /* Copy from param_kernel (which was already copied from user) */
- memcpy(dmi, param_kernel, minimum_data_size);
-
- if (copy_from_user(&dmi->data, (char __user *)user + minimum_data_size,
- param_kernel->data_size - minimum_data_size))
+ if (copy_from_user(dmi, user, param_kernel->data_size))
goto bad;
+
data_copied:
+ /*
+ * Abort if something changed the ioctl data while it was being copied.
+ */
+ if (dmi->data_size != param_kernel->data_size) {
+ DMERR("rejecting ioctl: data size modified while processing parameters");
+ goto bad;
+ }
+
/* Wipe the user buffer so we do not return it to userspace */
if (secure_data && clear_user(user, param_kernel->data_size))
goto bad;
--
2.31.1
This reverts commit 41af8b3a097c6fd17a4867efa25966927094f57c.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/cavium/liquidio/lio_core.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_core.c b/drivers/net/ethernet/cavium/liquidio/lio_core.c
index 2a0d64e5797c..3532730eb936 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_core.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_core.c
@@ -1211,11 +1211,6 @@ int liquidio_change_mtu(struct net_device *netdev, int new_mtu)
sc = (struct octeon_soft_command *)
octeon_alloc_soft_command(oct, OCTNET_CMD_SIZE, 16, 0);
- if (!sc) {
- netif_info(lio, rx_err, lio->netdev,
- "Failed to allocate soft command\n");
- return -ENOMEM;
- }
ncmd = (union octnet_cmd *)sc->virtdptr;
@@ -1689,11 +1684,6 @@ int liquidio_set_fec(struct lio *lio, int on_off)
sc = octeon_alloc_soft_command(oct, OCTNET_CMD_SIZE,
sizeof(struct oct_nic_seapi_resp), 0);
- if (!sc) {
- dev_err(&oct->pci_dev->dev,
- "Failed to allocate soft command\n");
- return -ENOMEM;
- }
ncmd = sc->virtdptr;
resp = sc->virtrptr;
--
2.31.1
This reverts commit 434256833d8eb988cb7f3b8a41699e2fe48d9332.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Kalle Valo <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/wireless/marvell/libertas/mesh.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/wireless/marvell/libertas/mesh.c b/drivers/net/wireless/marvell/libertas/mesh.c
index f5b78257d551..c611e6668b21 100644
--- a/drivers/net/wireless/marvell/libertas/mesh.c
+++ b/drivers/net/wireless/marvell/libertas/mesh.c
@@ -805,12 +805,7 @@ static void lbs_persist_config_init(struct net_device *dev)
{
int ret;
ret = sysfs_create_group(&(dev->dev.kobj), &boot_opts_group);
- if (ret)
- pr_err("failed to create boot_opts_group.\n");
-
ret = sysfs_create_group(&(dev->dev.kobj), &mesh_ie_group);
- if (ret)
- pr_err("failed to create mesh_ie_group.\n");
}
static void lbs_persist_config_remove(struct net_device *dev)
--
2.31.1
This reverts commit 1a137b47ce6bd4f4b14662d2f5ace913ea7ffbf8.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Alan Stern <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/usb/storage/sierra_ms.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/storage/sierra_ms.c b/drivers/usb/storage/sierra_ms.c
index b9f78ef3edc3..0f5c9cd8535f 100644
--- a/drivers/usb/storage/sierra_ms.c
+++ b/drivers/usb/storage/sierra_ms.c
@@ -190,6 +190,8 @@ int sierra_ms_init(struct us_data *us)
kfree(swocInfo);
}
complete:
- return device_create_file(&us->pusb_intf->dev, &dev_attr_truinst);
+ result = device_create_file(&us->pusb_intf->dev, &dev_attr_truinst);
+
+ return 0;
}
--
2.31.1
This reverts commit 486fa92df4707b5df58d6508728bdb9321a59766.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Dan Williams <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/nvdimm/btt_devs.c | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
index 05feb97e11ce..995573905dfb 100644
--- a/drivers/nvdimm/btt_devs.c
+++ b/drivers/nvdimm/btt_devs.c
@@ -191,15 +191,14 @@ static struct device *__nd_btt_create(struct nd_region *nd_region,
return NULL;
nd_btt->id = ida_simple_get(&nd_region->btt_ida, 0, 0, GFP_KERNEL);
- if (nd_btt->id < 0)
- goto out_nd_btt;
+ if (nd_btt->id < 0) {
+ kfree(nd_btt);
+ return NULL;
+ }
nd_btt->lbasize = lbasize;
- if (uuid) {
+ if (uuid)
uuid = kmemdup(uuid, 16, GFP_KERNEL);
- if (!uuid)
- goto out_put_id;
- }
nd_btt->uuid = uuid;
dev = &nd_btt->dev;
dev_set_name(dev, "btt%d.%d", nd_region->id, nd_btt->id);
@@ -213,13 +212,6 @@ static struct device *__nd_btt_create(struct nd_region *nd_region,
return NULL;
}
return dev;
-
-out_put_id:
- ida_simple_remove(&nd_region->btt_ida, nd_btt->id);
-
-out_nd_btt:
- kfree(nd_btt);
- return NULL;
}
struct device *nd_btt_create(struct nd_region *nd_region)
--
2.31.1
This reverts commit fba1bdd2a9a93f3e2181ec1936a3c2f6b37e7ed6.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Manish Rangankar <[email protected]>
Cc: Mukesh Ojha <[email protected]>
Cc: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/qla4xxx/ql4_os.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
index 7bd9a4a04ad5..5cb0dfe7a83b 100644
--- a/drivers/scsi/qla4xxx/ql4_os.c
+++ b/drivers/scsi/qla4xxx/ql4_os.c
@@ -3229,8 +3229,6 @@ static int qla4xxx_conn_bind(struct iscsi_cls_session *cls_session,
if (iscsi_conn_bind(cls_session, cls_conn, is_leading))
return -EINVAL;
ep = iscsi_lookup_endpoint(transport_fd);
- if (!ep)
- return -EINVAL;
conn = cls_conn->dd_data;
qla_conn = conn->dd_data;
qla_conn->qla_ep = ep->dd_data;
--
2.31.1
This reverts commit 0f25e000cb4398081748e54f62a902098aa79ec1.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/isa/gus/gus_main.c | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/sound/isa/gus/gus_main.c b/sound/isa/gus/gus_main.c
index afc088f0377c..b7518122a10d 100644
--- a/sound/isa/gus/gus_main.c
+++ b/sound/isa/gus/gus_main.c
@@ -77,17 +77,8 @@ static const struct snd_kcontrol_new snd_gus_joystick_control = {
static void snd_gus_init_control(struct snd_gus_card *gus)
{
- int ret;
-
- if (!gus->ace_flag) {
- ret =
- snd_ctl_add(gus->card,
- snd_ctl_new1(&snd_gus_joystick_control,
- gus));
- if (ret)
- snd_printk(KERN_ERR "gus: snd_ctl_add failed: %d\n",
- ret);
- }
+ if (!gus->ace_flag)
+ snd_ctl_add(gus->card, snd_ctl_new1(&snd_gus_joystick_control, gus));
}
/*
--
2.31.1
This reverts commit 73b69c01cc925d9c48e5b4f78e3d8b88c4e5b924.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Dan Carpenter <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/staging/rts5208/ms.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/staging/rts5208/ms.c b/drivers/staging/rts5208/ms.c
index 9001570a8c94..37b60ba1bdfe 100644
--- a/drivers/staging/rts5208/ms.c
+++ b/drivers/staging/rts5208/ms.c
@@ -1665,10 +1665,7 @@ static int ms_copy_page(struct rtsx_chip *chip, u16 old_blk, u16 new_blk,
return STATUS_FAIL;
}
- retval = ms_read_extra_data(chip, old_blk, i, extra,
- MS_EXTRA_SIZE);
- if (retval != STATUS_SUCCESS)
- return STATUS_FAIL;
+ ms_read_extra_data(chip, old_blk, i, extra, MS_EXTRA_SIZE);
retval = ms_set_rw_reg_addr(chip, OVERWRITE_FLAG,
MS_EXTRA_SIZE, SYSTEM_PARAM, 6);
--
2.31.1
This reverts commit ae0b3773721f08526c850e2d8dec85bdb870cd12.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Jonathan Cameron <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/iio/frequency/ad9523.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/iio/frequency/ad9523.c b/drivers/iio/frequency/ad9523.c
index bdb0bc3b12dd..91eb47e27db0 100644
--- a/drivers/iio/frequency/ad9523.c
+++ b/drivers/iio/frequency/ad9523.c
@@ -944,14 +944,11 @@ static int ad9523_setup(struct iio_dev *indio_dev)
}
}
- for_each_clear_bit(i, &active_mask, AD9523_NUM_CHAN) {
- ret = ad9523_write(indio_dev,
+ for_each_clear_bit(i, &active_mask, AD9523_NUM_CHAN)
+ ad9523_write(indio_dev,
AD9523_CHANNEL_CLOCK_DIST(i),
AD9523_CLK_DIST_DRIVER_MODE(TRISTATE) |
AD9523_CLK_DIST_PWR_DOWN_EN);
- if (ret < 0)
- return ret;
- }
ret = ad9523_write(indio_dev, AD9523_POWER_DOWN_CTRL, 0);
if (ret < 0)
--
2.31.1
This reverts commit ff07d48d7bc0974d4f96a85a4df14564fb09f1ef.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
index ff9f96de74b8..85f9cb769e30 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
@@ -455,9 +455,7 @@ static void atl1e_mdio_write(struct net_device *netdev, int phy_id,
{
struct atl1e_adapter *adapter = netdev_priv(netdev);
- if (atl1e_write_phy_reg(&adapter->hw,
- reg_num & MDIO_REG_ADDR_MASK, val))
- netdev_err(netdev, "write phy register failed\n");
+ atl1e_write_phy_reg(&adapter->hw, reg_num & MDIO_REG_ADDR_MASK, val);
}
static int atl1e_mii_ioctl(struct net_device *netdev,
--
2.31.1
This reverts commit f86a3b83833e7cfe558ca4d70b64ebc48903efec.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
index 0e1ca2cba3c7..0e86553fc06f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
@@ -50,9 +50,7 @@ static int sun7i_gmac_init(struct platform_device *pdev, void *priv)
gmac->clk_enabled = 1;
} else {
clk_set_rate(gmac->tx_clk, SUN7I_GMAC_MII_RATE);
- ret = clk_prepare(gmac->tx_clk);
- if (ret)
- return ret;
+ clk_prepare(gmac->tx_clk);
}
return 0;
--
2.31.1
This reverts commit e49505f7255be8ced695919c08a29bf2c3d79616.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/dsa/bcm_sf2.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index ba5d546d06aa..b4f3d458143a 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -361,10 +361,11 @@ static int bcm_sf2_sw_mdio_write(struct mii_bus *bus, int addr, int regnum,
* send them to our master MDIO bus controller
*/
if (addr == BRCM_PSEUDO_PHY_ADDR && priv->indir_phy_mask & BIT(addr))
- return bcm_sf2_sw_indir_rw(priv, 0, addr, regnum, val);
+ bcm_sf2_sw_indir_rw(priv, 0, addr, regnum, val);
else
- return mdiobus_write_nested(priv->master_mii_bus, addr,
- regnum, val);
+ mdiobus_write_nested(priv->master_mii_bus, addr, regnum, val);
+
+ return 0;
}
static irqreturn_t bcm_sf2_switch_0_isr(int irq, void *dev_id)
--
2.31.1
This reverts commit 467a37fba93f2b4fe3ab597ff6a517b22b566882.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Sean Young <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/dvb-frontends/sp8870.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/dvb-frontends/sp8870.c b/drivers/media/dvb-frontends/sp8870.c
index 655db8272268..ee893a2f2261 100644
--- a/drivers/media/dvb-frontends/sp8870.c
+++ b/drivers/media/dvb-frontends/sp8870.c
@@ -280,9 +280,7 @@ static int sp8870_set_frontend_parameters(struct dvb_frontend *fe)
sp8870_writereg(state, 0xc05, reg0xc05);
// read status reg in order to clear pending irqs
- err = sp8870_readreg(state, 0x200);
- if (err)
- return err;
+ sp8870_readreg(state, 0x200);
// system controller start
sp8870_microcontroller_start(state);
--
2.31.1
This reverts commit ca19fcb6285bfce1601c073bf4b9d2942e2df8d9.
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.
Cc: Aditya Pakki <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c b/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
index 23a2ebdfd503..c7378da78a83 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
@@ -1638,10 +1638,6 @@ int cudbg_collect_hw_sched(struct cudbg_init *pdbg_init,
rc = cudbg_get_buff(pdbg_init, dbg_buff, sizeof(struct cudbg_hw_sched),
&temp_buff);
-
- if (rc)
- return rc;
-
hw_sched_buff = (struct cudbg_hw_sched *)temp_buff.data;
hw_sched_buff->map = t4_read_reg(padap, TP_TX_MOD_QUEUE_REQ_MAP_A);
hw_sched_buff->mode = TIMERMODE_G(t4_read_reg(padap, TP_MOD_CONFIG_A));
--
2.31.1
This reverts commit 0eb987c874dc93f9c9d85a6465dbde20fdd3884c.
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.
Cc: Aditya Pakki <[email protected]>
Cc: Kirill Tkhai <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/core/net_namespace.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 43b6ac4c4439..9ae0b275238e 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -1101,8 +1101,7 @@ static int __init net_ns_init(void)
init_net_initialized = true;
up_write(&pernet_ops_rwsem);
- if (register_pernet_subsys(&net_ns_ops))
- panic("Could not register network namespace subsystems");
+ register_pernet_subsys(&net_ns_ops);
rtnl_register(PF_UNSPEC, RTM_NEWNSID, rtnl_net_newid, NULL,
RTNL_FLAG_DOIT_UNLOCKED);
--
2.31.1
This reverts commit 966e927bf8cc6a44f8b72582a1d6d3ffc73b12ad.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/regulator/palmas-regulator.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c
index 337dd614695e..f27ad8254291 100644
--- a/drivers/regulator/palmas-regulator.c
+++ b/drivers/regulator/palmas-regulator.c
@@ -438,16 +438,13 @@ static int palmas_ldo_write(struct palmas *palmas, unsigned int reg,
static int palmas_set_mode_smps(struct regulator_dev *dev, unsigned int mode)
{
int id = rdev_get_id(dev);
- int ret;
struct palmas_pmic *pmic = rdev_get_drvdata(dev);
struct palmas_pmic_driver_data *ddata = pmic->palmas->pmic_ddata;
struct palmas_regs_info *rinfo = &ddata->palmas_regs_info[id];
unsigned int reg;
bool rail_enable = true;
- ret = palmas_smps_read(pmic->palmas, rinfo->ctrl_addr, ®);
- if (ret)
- return ret;
+ palmas_smps_read(pmic->palmas, rinfo->ctrl_addr, ®);
reg &= ~PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
--
2.31.1
This reverts commit c9b7d8f252a5a6f8ca6e948151367cbc7bc4b776.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Sean Young <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/dvb-frontends/lgdt3306a.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/media/dvb-frontends/lgdt3306a.c b/drivers/media/dvb-frontends/lgdt3306a.c
index 722576f1732a..f34263a33ede 100644
--- a/drivers/media/dvb-frontends/lgdt3306a.c
+++ b/drivers/media/dvb-frontends/lgdt3306a.c
@@ -1690,10 +1690,7 @@ static int lgdt3306a_read_signal_strength(struct dvb_frontend *fe,
case QAM_256:
case QAM_AUTO:
/* need to know actual modulation to set proper SNR baseline */
- ret = lgdt3306a_read_reg(state, 0x00a6, &val);
- if (lg_chkerr(ret))
- goto fail;
-
+ lgdt3306a_read_reg(state, 0x00a6, &val);
if(val & 0x04)
ref_snr = 2800; /* QAM-256 28dB */
else
--
2.31.1
This reverts commit 9502cdf0807058a10029488052b064cecceb7fc9.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Matthias Schwarzott <[email protected]>
Cc: Sean Young <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/dvb-frontends/mt312.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/dvb-frontends/mt312.c b/drivers/media/dvb-frontends/mt312.c
index d43a67045dbe..1dc6adefb8fe 100644
--- a/drivers/media/dvb-frontends/mt312.c
+++ b/drivers/media/dvb-frontends/mt312.c
@@ -627,9 +627,7 @@ static int mt312_set_frontend(struct dvb_frontend *fe)
if (ret < 0)
return ret;
- ret = mt312_reset(state, 0);
- if (ret < 0)
- return ret;
+ mt312_reset(state, 0);
return 0;
}
--
2.31.1
This reverts commit 5b711870bec4dc9a6d705d41e127e73944fa3650.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/usb/gspca/cpia1.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/media/usb/gspca/cpia1.c b/drivers/media/usb/gspca/cpia1.c
index a4f7431486f3..d93d384286c1 100644
--- a/drivers/media/usb/gspca/cpia1.c
+++ b/drivers/media/usb/gspca/cpia1.c
@@ -1424,7 +1424,6 @@ static int sd_config(struct gspca_dev *gspca_dev,
{
struct sd *sd = (struct sd *) gspca_dev;
struct cam *cam;
- int ret;
sd->mainsFreq = FREQ_DEF == V4L2_CID_POWER_LINE_FREQUENCY_60HZ;
reset_camera_params(gspca_dev);
@@ -1436,10 +1435,7 @@ static int sd_config(struct gspca_dev *gspca_dev,
cam->cam_mode = mode;
cam->nmodes = ARRAY_SIZE(mode);
- ret = goto_low_power(gspca_dev);
- if (ret)
- gspca_err(gspca_dev, "Cannot go to low power mode: %d\n",
- ret);
+ goto_low_power(gspca_dev);
/* Check the firmware version. */
sd->params.version.firmwareVersion = 0;
get_version_information(gspca_dev);
--
2.31.1
This reverts commit 0b31d98d90f09868dce71319615e19cd1f146fb6.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index c33b4e837515..b10608c55db0 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -2246,12 +2246,6 @@ static int nicvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
nic->nicvf_rx_mode_wq = alloc_ordered_workqueue("nicvf_rx_mode_wq_VF%d",
WQ_MEM_RECLAIM,
nic->vf_id);
- if (!nic->nicvf_rx_mode_wq) {
- err = -ENOMEM;
- dev_err(dev, "Failed to allocate work queue\n");
- goto err_unregister_interrupts;
- }
-
INIT_WORK(&nic->rx_mode_work.work, nicvf_set_rx_mode_task);
spin_lock_init(&nic->rx_mode_wq_lock);
--
2.31.1
This reverts commit fe543b2f174f34a7a751aa08b334fe6b105c4569.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/cavium/liquidio/lio_main.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c b/drivers/net/ethernet/cavium/liquidio/lio_main.c
index 7c5af4beedc6..6fa570068648 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
@@ -1166,11 +1166,6 @@ static void send_rx_ctrl_cmd(struct lio *lio, int start_stop)
sc = (struct octeon_soft_command *)
octeon_alloc_soft_command(oct, OCTNET_CMD_SIZE,
16, 0);
- if (!sc) {
- netif_info(lio, rx_err, lio->netdev,
- "Failed to allocate octeon_soft_command\n");
- return;
- }
ncmd = (union octnet_cmd *)sc->virtdptr;
--
2.31.1
This reverts commit d721fe99f6ada070ae8fc0ec3e01ce5a42def0d9.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/isdn/hardware/mISDN/mISDNinfineon.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/isdn/hardware/mISDN/mISDNinfineon.c b/drivers/isdn/hardware/mISDN/mISDNinfineon.c
index a16c7a2a7f3d..fa9c491f9c38 100644
--- a/drivers/isdn/hardware/mISDN/mISDNinfineon.c
+++ b/drivers/isdn/hardware/mISDN/mISDNinfineon.c
@@ -697,11 +697,8 @@ setup_io(struct inf_hw *hw)
(ulong)hw->addr.start, (ulong)hw->addr.size);
return err;
}
- if (hw->ci->addr_mode == AM_MEMIO) {
+ if (hw->ci->addr_mode == AM_MEMIO)
hw->addr.p = ioremap(hw->addr.start, hw->addr.size);
- if (unlikely(!hw->addr.p))
- return -ENOMEM;
- }
hw->addr.mode = hw->ci->addr_mode;
if (debug & DEBUG_HW)
pr_notice("%s: IO addr %lx (%lu bytes) mode%d\n",
--
2.31.1
This reverts commit 38d22659803a033b1b66cd2624c33570c0dde77d.
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.
Cc: Aditya Pakki <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/isdn/hardware/mISDN/hfcsusb.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c b/drivers/isdn/hardware/mISDN/hfcsusb.c
index 70061991915a..4bb470d3963d 100644
--- a/drivers/isdn/hardware/mISDN/hfcsusb.c
+++ b/drivers/isdn/hardware/mISDN/hfcsusb.c
@@ -249,9 +249,6 @@ hfcsusb_ph_info(struct hfcsusb *hw)
int i;
phi = kzalloc(struct_size(phi, bch, dch->dev.nrbchan), GFP_ATOMIC);
- if (!phi)
- return;
-
phi->dch.ch.protocol = hw->protocol;
phi->dch.ch.Flags = dch->Flags;
phi->dch.state = dch->state;
--
2.31.1
This reverts commit 9a20b5e35a536d6bb4b2d4a3b14a0457e205356c.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Alexandre Belloni <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/rtc/rtc-hym8563.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/rtc/rtc-hym8563.c b/drivers/rtc/rtc-hym8563.c
index 0751cae27285..a9d033eff61e 100644
--- a/drivers/rtc/rtc-hym8563.c
+++ b/drivers/rtc/rtc-hym8563.c
@@ -94,8 +94,6 @@ static int hym8563_rtc_read_time(struct device *dev, struct rtc_time *tm)
int ret;
ret = i2c_smbus_read_i2c_block_data(client, HYM8563_SEC, 7, buf);
- if (ret < 0)
- return ret;
if (buf[0] & HYM8563_SEC_VL) {
dev_warn(&client->dev,
--
2.31.1
This reverts commit 55c1fc0af29a6c1b92f217b7eb7581a882e0c07c.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Dan Williams <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/nvdimm/namespace_devs.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
index 2403b71b601e..04f7cb7a23b7 100644
--- a/drivers/nvdimm/namespace_devs.c
+++ b/drivers/nvdimm/namespace_devs.c
@@ -2297,12 +2297,9 @@ static struct device *create_namespace_blk(struct nd_region *nd_region,
if (!nsblk->uuid)
goto blk_err;
memcpy(name, nd_label->name, NSLABEL_NAME_LEN);
- if (name[0]) {
+ if (name[0])
nsblk->alt_name = kmemdup(name, NSLABEL_NAME_LEN,
GFP_KERNEL);
- if (!nsblk->alt_name)
- goto blk_err;
- }
res = nsblk_add_resource(nd_region, ndd, nsblk,
__le64_to_cpu(nd_label->dpa));
if (!res)
--
2.31.1
This reverts commit 26fd962bde0b15e54234fe762d86bc0349df1de4.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Shannon Nelson <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/sun/niu.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
index 707ccdd03b19..d70cdea756d1 100644
--- a/drivers/net/ethernet/sun/niu.c
+++ b/drivers/net/ethernet/sun/niu.c
@@ -8097,8 +8097,6 @@ static int niu_pci_vpd_scan_props(struct niu *np, u32 start, u32 end)
start += 3;
prop_len = niu_pci_eeprom_read(np, start + 4);
- if (prop_len < 0)
- return prop_len;
err = niu_pci_vpd_get_propname(np, start + 5, namebuf, 64);
if (err < 0)
return err;
@@ -8143,12 +8141,8 @@ static int niu_pci_vpd_scan_props(struct niu *np, u32 start, u32 end)
netif_printk(np, probe, KERN_DEBUG, np->dev,
"VPD_SCAN: Reading in property [%s] len[%d]\n",
namebuf, prop_len);
- for (i = 0; i < prop_len; i++) {
- err = niu_pci_eeprom_read(np, off + i);
- if (err >= 0)
- *prop_buf = err;
- ++prop_buf;
- }
+ for (i = 0; i < prop_len; i++)
+ *prop_buf++ = niu_pci_eeprom_read(np, off + i);
}
start += len;
--
2.31.1
This reverts commit d134e486e831defd26130770181f01dfc6195f7d.
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.
Cc: Kangjie Lu <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
index 08f9477d2ee8..32b9e28dda16 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
@@ -1107,8 +1107,7 @@ netxen_validate_firmware(struct netxen_adapter *adapter)
return -EINVAL;
}
val = nx_get_bios_version(adapter);
- if (netxen_rom_fast_read(adapter, NX_BIOS_VERSION_OFFSET, (int *)&bios))
- return -EIO;
+ netxen_rom_fast_read(adapter, NX_BIOS_VERSION_OFFSET, (int *)&bios);
if ((__force u32)val != bios) {
dev_err(&pdev->dev, "%s: firmware bios is incompatible\n",
fw_name[fw_type]);
--
2.31.1
This reverts commit b6168562c8ce2bd5a30e213021650422e08764dc.
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.
Cc: Wenwen Wang <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/socket.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index 84a8049c2b09..d4176362a27b 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -3182,14 +3182,9 @@ static int ethtool_ioctl(struct net *net, struct compat_ifreq __user *ifr32)
copy_in_user(&rxnfc->fs.ring_cookie,
&compat_rxnfc->fs.ring_cookie,
(void __user *)(&rxnfc->fs.location + 1) -
- (void __user *)&rxnfc->fs.ring_cookie))
- return -EFAULT;
- if (ethcmd == ETHTOOL_GRXCLSRLALL) {
- if (put_user(rule_cnt, &rxnfc->rule_cnt))
- return -EFAULT;
- } else if (copy_in_user(&rxnfc->rule_cnt,
- &compat_rxnfc->rule_cnt,
- sizeof(rxnfc->rule_cnt)))
+ (void __user *)&rxnfc->fs.ring_cookie) ||
+ copy_in_user(&rxnfc->rule_cnt, &compat_rxnfc->rule_cnt,
+ sizeof(rxnfc->rule_cnt)))
return -EFAULT;
}
--
2.31.1
This reverts commit a26ac6c1bed951b2066cc4b2257facd919e35c0b.
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.
Cc: Wenwen Wang <[email protected]>
Cc: Hans Verkuil <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/media/platform/davinci/isif.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/platform/davinci/isif.c b/drivers/media/platform/davinci/isif.c
index c53cecd072b1..5355a14c090b 100644
--- a/drivers/media/platform/davinci/isif.c
+++ b/drivers/media/platform/davinci/isif.c
@@ -1086,8 +1086,7 @@ static int isif_probe(struct platform_device *pdev)
while (i >= 0) {
res = platform_get_resource(pdev, IORESOURCE_MEM, i);
- if (res)
- release_mem_region(res->start, resource_size(res));
+ release_mem_region(res->start, resource_size(res));
i--;
}
vpfe_unregister_ccdc_device(&isif_hw_dev);
--
2.31.1
This reverts commit f0fb9b288d0a7e9cc324ae362e2dfd2cc2217ded.
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.
Cc: Aditya Pakki <[email protected]>
Cc: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
net/ipv6/route.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 373d48073106..0e85741423d7 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -6169,16 +6169,12 @@ static int ipv6_sysctl_rtcache_flush(struct ctl_table *ctl, int write,
{
struct net *net;
int delay;
- int ret;
if (!write)
return -EINVAL;
net = (struct net *)ctl->extra1;
delay = net->ipv6.sysctl.flush_delay;
- ret = proc_dointvec(ctl, write, buffer, lenp, ppos);
- if (ret)
- return ret;
-
+ proc_dointvec(ctl, write, buffer, lenp, ppos);
fib6_run_gc(delay <= 0 ? 0 : (unsigned long)delay, net, delay > 0);
return 0;
}
--
2.31.1
This reverts commit 3f12888dfae2a48741c4caa9214885b3aaf350f9.
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.
Cc: Wenwen Wang <[email protected]>
Cc: <[email protected]>
Cc: Takashi Iwai <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
sound/core/control_compat.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/core/control_compat.c b/sound/core/control_compat.c
index 1d708aab9c98..857acf83ae47 100644
--- a/sound/core/control_compat.c
+++ b/sound/core/control_compat.c
@@ -381,7 +381,8 @@ static int snd_ctl_elem_add_compat(struct snd_ctl_file *file,
if (copy_from_user(&data->id, &data32->id, sizeof(data->id)) ||
copy_from_user(&data->type, &data32->type, 3 * sizeof(u32)))
goto error;
- if (get_user(data->owner, &data32->owner))
+ if (get_user(data->owner, &data32->owner) ||
+ get_user(data->type, &data32->type))
goto error;
switch (data->type) {
case SNDRV_CTL_ELEM_TYPE_BOOLEAN:
--
2.31.1
This reverts commit 9899e4d3523faaef17c67141aa80ff2088f17871.
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.
Cc: Wenwen Wang <[email protected]>
Cc: Adam Radford <[email protected]>
Cc: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/3w-xxxx.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/scsi/3w-xxxx.c b/drivers/scsi/3w-xxxx.c
index d90b9fca4aea..8f52f35e40f1 100644
--- a/drivers/scsi/3w-xxxx.c
+++ b/drivers/scsi/3w-xxxx.c
@@ -1035,9 +1035,6 @@ static int tw_chrdev_open(struct inode *inode, struct file *file)
dprintk(KERN_WARNING "3w-xxxx: tw_ioctl_open()\n");
- if (!capable(CAP_SYS_ADMIN))
- return -EACCES;
-
minor_number = iminor(inode);
if (minor_number >= tw_device_extension_count)
return -ENODEV;
--
2.31.1
This reverts commit c9318a3e0218bc9dacc25be46b9eec363259536f.
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.
Cc: Wenwen Wang <[email protected]>
Cc: Adam Radford <[email protected]>
Cc: Martin K. Petersen <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/scsi/3w-9xxx.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
index b96e82de4237..4c5d4ea8a592 100644
--- a/drivers/scsi/3w-9xxx.c
+++ b/drivers/scsi/3w-9xxx.c
@@ -886,11 +886,6 @@ static int twa_chrdev_open(struct inode *inode, struct file *file)
unsigned int minor_number;
int retval = TW_IOCTL_ERROR_OS_ENODEV;
- if (!capable(CAP_SYS_ADMIN)) {
- retval = -EACCES;
- goto out;
- }
-
minor_number = iminor(inode);
if (minor_number >= twa_device_extension_count)
goto out;
--
2.31.1
This reverts commit bd23a7269834dc7c1f93e83535d16ebc44b75eba.
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.
Cc: Wenwen Wang <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/virt/vboxguest/vboxguest_linux.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/virt/vboxguest/vboxguest_linux.c b/drivers/virt/vboxguest/vboxguest_linux.c
index 73eb34849eab..f5cd9cfa1ef6 100644
--- a/drivers/virt/vboxguest/vboxguest_linux.c
+++ b/drivers/virt/vboxguest/vboxguest_linux.c
@@ -142,9 +142,7 @@ static long vbg_misc_device_ioctl(struct file *filp, unsigned int req,
if (!buf)
return -ENOMEM;
- *((struct vbg_ioctl_hdr *)buf) = hdr;
- if (copy_from_user(buf + sizeof(hdr), (void *)arg + sizeof(hdr),
- hdr.size_in - sizeof(hdr))) {
+ if (copy_from_user(buf, (void *)arg, hdr.size_in)) {
ret = -EFAULT;
goto out;
}
--
2.31.1
This reverts commit e2a438bd7116889af36304903b92e56d0f347228.
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.
Cc: Kangjie Lu <[email protected]>
Cc: Shiraz, Saleem <[email protected]>
Cc: Jason Gunthorpe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/infiniband/hw/i40iw/i40iw.h | 2 +-
drivers/infiniband/hw/i40iw/i40iw_cm.c | 18 +++---------------
drivers/infiniband/hw/i40iw/i40iw_main.c | 5 +----
3 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/drivers/infiniband/hw/i40iw/i40iw.h b/drivers/infiniband/hw/i40iw/i40iw.h
index 6a79502c8b53..a6bf8f42e7da 100644
--- a/drivers/infiniband/hw/i40iw/i40iw.h
+++ b/drivers/infiniband/hw/i40iw/i40iw.h
@@ -561,7 +561,7 @@ enum i40iw_status_code i40iw_obj_aligned_mem(struct i40iw_device *iwdev,
void i40iw_request_reset(struct i40iw_device *iwdev);
void i40iw_destroy_rdma_device(struct i40iw_ib_device *iwibdev);
-int i40iw_setup_cm_core(struct i40iw_device *iwdev);
+void i40iw_setup_cm_core(struct i40iw_device *iwdev);
void i40iw_cleanup_cm_core(struct i40iw_cm_core *cm_core);
void i40iw_process_ceq(struct i40iw_device *, struct i40iw_ceq *iwceq);
void i40iw_process_aeq(struct i40iw_device *);
diff --git a/drivers/infiniband/hw/i40iw/i40iw_cm.c b/drivers/infiniband/hw/i40iw/i40iw_cm.c
index ac65c8237b2e..450271fde637 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
@@ -3236,7 +3236,7 @@ void i40iw_receive_ilq(struct i40iw_sc_vsi *vsi, struct i40iw_puda_buf *rbuf)
* core
* @iwdev: iwarp device structure
*/
-int i40iw_setup_cm_core(struct i40iw_device *iwdev)
+void i40iw_setup_cm_core(struct i40iw_device *iwdev)
{
struct i40iw_cm_core *cm_core = &iwdev->cm_core;
@@ -3255,19 +3255,9 @@ int i40iw_setup_cm_core(struct i40iw_device *iwdev)
cm_core->event_wq = alloc_ordered_workqueue("iwewq",
WQ_MEM_RECLAIM);
- if (!cm_core->event_wq)
- goto error;
cm_core->disconn_wq = alloc_ordered_workqueue("iwdwq",
WQ_MEM_RECLAIM);
- if (!cm_core->disconn_wq)
- goto error;
-
- return 0;
-error:
- i40iw_cleanup_cm_core(&iwdev->cm_core);
-
- return -ENOMEM;
}
/**
@@ -3287,10 +3277,8 @@ void i40iw_cleanup_cm_core(struct i40iw_cm_core *cm_core)
del_timer_sync(&cm_core->tcp_timer);
spin_unlock_irqrestore(&cm_core->ht_lock, flags);
- if (cm_core->event_wq)
- destroy_workqueue(cm_core->event_wq);
- if (cm_core->disconn_wq)
- destroy_workqueue(cm_core->disconn_wq);
+ destroy_workqueue(cm_core->event_wq);
+ destroy_workqueue(cm_core->disconn_wq);
}
/**
diff --git a/drivers/infiniband/hw/i40iw/i40iw_main.c b/drivers/infiniband/hw/i40iw/i40iw_main.c
index ab4cb11950dc..9db84ec08fc0 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_main.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_main.c
@@ -1634,10 +1634,7 @@ static int i40iw_open(struct i40e_info *ldev, struct i40e_client *client)
iwdev = &hdl->device;
iwdev->hdl = hdl;
dev = &iwdev->sc_dev;
- if (i40iw_setup_cm_core(iwdev)) {
- kfree(iwdev->hdl);
- return -ENOMEM;
- }
+ i40iw_setup_cm_core(iwdev);
dev->back_dev = (void *)iwdev;
iwdev->ldev = &hdl->ldev;
--
2.31.1
Hi Greg,
Thank you for the patch.
On Wed, Apr 21, 2021 at 02:59:23PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 611025983b7976df0183390a63a2166411d177f1.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Laurent Pinchart <[email protected]>
> Cc: Ulf Hansson <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
I don't spot an obvious issue with the original patch though.
> ---
> drivers/mmc/host/mmc_spi.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
> index 02f4fd26e76a..cc40b050e302 100644
> --- a/drivers/mmc/host/mmc_spi.c
> +++ b/drivers/mmc/host/mmc_spi.c
> @@ -800,10 +800,6 @@ mmc_spi_readblock(struct mmc_spi_host *host, struct spi_transfer *t,
> }
>
> status = spi_sync_locked(spi, &host->m);
> - if (status < 0) {
> - dev_dbg(&spi->dev, "read error %d\n", status);
> - return status;
> - }
>
> if (host->dma_dev) {
> dma_sync_single_for_cpu(host->dma_dev,
--
Regards,
Laurent Pinchart
Hello.
On 21.04.21 14:59, Greg Kroah-Hartman wrote:
> This reverts commit 22e8860cf8f777fbf6a83f2fb7127f682a8e9de4.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Mukesh Ojha <[email protected]>
> Cc: Stefan Schmidt <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ieee802154/mcr20a.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
> index 8dc04e2590b1..2ce5b41983f8 100644
> --- a/drivers/net/ieee802154/mcr20a.c
> +++ b/drivers/net/ieee802154/mcr20a.c
> @@ -524,8 +524,6 @@ mcr20a_start(struct ieee802154_hw *hw)
> dev_dbg(printdev(lp), "no slotted operation\n");
> ret = regmap_update_bits(lp->regmap_dar, DAR_PHY_CTRL1,
> DAR_PHY_CTRL1_SLOTTED, 0x0);
> - if (ret < 0)
> - return ret;
>
> /* enable irq */
> enable_irq(lp->spi->irq);
> @@ -533,15 +531,11 @@ mcr20a_start(struct ieee802154_hw *hw)
> /* Unmask SEQ interrupt */
> ret = regmap_update_bits(lp->regmap_dar, DAR_PHY_CTRL2,
> DAR_PHY_CTRL2_SEQMSK, 0x0);
> - if (ret < 0)
> - return ret;
>
> /* Start the RX sequence */
> dev_dbg(printdev(lp), "start the RX sequence\n");
> ret = regmap_update_bits(lp->regmap_dar, DAR_PHY_CTRL1,
> DAR_PHY_CTRL1_XCVSEQ_MASK, MCR20A_XCVSEQ_RX);
> - if (ret < 0)
> - return ret;
>
> return 0;
> }
>
Acked-by: Stefan Schmidt <[email protected]>
regards
Stefan Schmidt
On Wed, 21 Apr 2021 14:59:16 +0200
Greg Kroah-Hartman <[email protected]> wrote:
> This reverts commit 91862cc7867bba4ee5c8fcf0ca2f1d30427b6129.
>
> 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.
>
I have reviewed this change, and this is a valid fix and does not need to
be reverted.
The code before the change is:
if (trace_parser_get_init(&parser, PID_BUF_SIZE + 1))
return -ENOMEM;
Where that does:
int trace_parser_get_init(struct trace_parser *parser, int size)
{
memset(parser, 0, sizeof(*parser));
parser->buffer = kmalloc(size, GFP_KERNEL);
if (!parser->buffer)
return 1;
parser->size = size;
return 0;
}
And the trace_parser_put() does:
void trace_parser_put(struct trace_parser *parser)
{
kfree(parser->buffer);
parser->buffer = NULL;
}
Hence, exiting the function without calling trace_parser_put() will indeed
leak memory.
Please do not revert this patch.
Reviewed-by: Steven Rostedt (VMware) <[email protected]>
-- Steve
> Cc: http
> Cc: [email protected]
> Cc: Wenwen Wang <[email protected]>
> Cc: Steven Rostedt (VMware) <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> kernel/trace/trace.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 5c777627212f..faed4f44d224 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -691,10 +691,8 @@ int trace_pid_write(struct trace_pid_list *filtered_pids,
> * not modified.
> */
> pid_list = kmalloc(sizeof(*pid_list), GFP_KERNEL);
> - if (!pid_list) {
> - trace_parser_put(&parser);
> + if (!pid_list)
> return -ENOMEM;
> - }
>
> pid_list->pid_max = READ_ONCE(pid_max);
>
> @@ -704,7 +702,6 @@ int trace_pid_write(struct trace_pid_list *filtered_pids,
>
> pid_list->pids = vzalloc((pid_list->pid_max + 7) >> 3);
> if (!pid_list->pids) {
> - trace_parser_put(&parser);
> kfree(pid_list);
> return -ENOMEM;
> }
On Wed, 2021-04-21 at 12:59 +0000, Greg Kroah-Hartman wrote:
> This reverts commit 1ee7826ab68f7e9fa1a01533983acf6a6f62e297.
>
That commit was actually correct, though sort of irrelevant. I think we
can go either way on it, but better not spend any (more) time on it.
johannes
On Wed, 2021-04-21 at 12:59 +0000, Greg Kroah-Hartman wrote:
> This reverts commit 6fc232db9e8cd50b9b83534de9cd91ace711b2d7.
This commit was fine, though the commit log is misleading since there's
no dereference yet, just a pointer calculation. I may not have seen that
at the time, or have decided that the slight commit log inaccuracy
didn't matter.
I'm inclined towards keeping it, since it removed a BUG_ON(), but
there's no reasonable scenario where somebody could end up calling this
function with a NULL pointer.
johannes
On Wed 21-04-21 14:59:22, Greg Kroah-Hartman wrote:
> This reverts commit 39416c5872db69859e867fa250b9cbb3f1e0d185.
>
> 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.
>
> Cc: Wenwen Wang <[email protected]>
> Cc: Jan Kara <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Hi Greg!
I'm pretty confident this particular report & fix was valid (in fact it was
me who suggested the particular change). So I don't see point in reverting
it...
Honza
> ---
> fs/udf/namei.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/fs/udf/namei.c b/fs/udf/namei.c
> index f146b3089f3d..77906b679187 100644
> --- a/fs/udf/namei.c
> +++ b/fs/udf/namei.c
> @@ -304,6 +304,21 @@ static struct dentry *udf_lookup(struct inode *dir, struct dentry *dentry,
> if (dentry->d_name.len > UDF_NAME_LEN)
> return ERR_PTR(-ENAMETOOLONG);
>
> +#ifdef UDF_RECOVERY
> + /* temporary shorthand for specifying files by inode number */
> + if (!strncmp(dentry->d_name.name, ".B=", 3)) {
> + struct kernel_lb_addr lb = {
> + .logicalBlockNum = 0,
> + .partitionReferenceNum =
> + simple_strtoul(dentry->d_name.name + 3,
> + NULL, 0),
> + };
> + inode = udf_iget(dir->i_sb, lb);
> + if (IS_ERR(inode))
> + return inode;
> + } else
> +#endif /* UDF_RECOVERY */
> +
> fi = udf_find_entry(dir, &dentry->d_name, &fibh, &cfi);
> if (IS_ERR(fi))
> return ERR_CAST(fi);
> --
> 2.31.1
>
--
Jan Kara <[email protected]>
SUSE Labs, CR
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
On Wed, Apr 21, 2021 at 11:02:47AM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 21, 2021 at 02:58:54PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 9f48db0d4a08624bb9ba847ea40c8abad753b396.
> >
> > 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.
> >
> > Cc: https
> > Cc: Aditya Pakki <[email protected]>
> > Cc: Bart Van Assche <[email protected]>
> > Cc: Jason Gunthorpe <[email protected]>
> > Cc: Jason Gunthorpe <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > drivers/infiniband/ulp/srpt/ib_srpt.c | 2 ++
> > 1 file changed, 2 insertions(+)
>
> I think this one is fine
Sorry, I realize that is unclear. I mean I don't see a reason to
revert this patch.
Jason
On Wed, 21 Apr 2021 09:29:19 -0400
Steven Rostedt <[email protected]> wrote:
> Reviewed-by: Steven Rostedt (VMware) <[email protected]>
Just to clear up any confusion about my tag above. It was a second review
of the original patch, not for the revert.
-- Steve
On Wed, Apr 21, 2021 at 09:33:43AM -0400, Steven Rostedt wrote:
> On Wed, 21 Apr 2021 09:29:19 -0400
> Steven Rostedt <[email protected]> wrote:
>
> > Reviewed-by: Steven Rostedt (VMware) <[email protected]>
>
> Just to clear up any confusion about my tag above. It was a second review
> of the original patch, not for the revert.
Fair enough, I'll handle it, thanks!
greg k-h
On Wed, Apr 21, 2021 at 03:43:31PM +0200, Johannes Berg wrote:
> On Wed, 2021-04-21 at 12:59 +0000, Greg Kroah-Hartman wrote:
> > This reverts commit 6fc232db9e8cd50b9b83534de9cd91ace711b2d7.
>
> This commit was fine, though the commit log is misleading since there's
> no dereference yet, just a pointer calculation. I may not have seen that
> at the time, or have decided that the slight commit log inaccuracy
> didn't matter.
>
> I'm inclined towards keeping it, since it removed a BUG_ON(), but
> there's no reasonable scenario where somebody could end up calling this
> function with a NULL pointer.
Yeah, these "pointless" patches are not good as they waste maintainers
bandwidth, which is why I want to discourage them.
thanks for reviewing these reverts, much apprecated.
greg k-h
On Wed, Apr 21, 2021 at 02:59:42PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit e2a438bd7116889af36304903b92e56d0f347228.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Shiraz, Saleem <[email protected]>
> Cc: Jason Gunthorpe <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/infiniband/hw/i40iw/i40iw.h | 2 +-
> drivers/infiniband/hw/i40iw/i40iw_cm.c | 18 +++---------------
> drivers/infiniband/hw/i40iw/i40iw_main.c | 5 +----
> 3 files changed, 5 insertions(+), 20 deletions(-)
I don't see a reason to revert this one, the new code structure
appears OK
Jason
On Wed, Apr 21, 2021 at 02:58:39PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit db857e6ae548f0f4f4a0f63fffeeedf3cca21f9d.
>
> 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.
>
> Cc: https
> Cc: Qiushi Wu <[email protected]>
> Cc: Jason Gunthorpe <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Can't see a reason to revert this one
Jason
On Wed, Apr 21, 2021 at 7:38 PM Jason Gunthorpe <[email protected]> wrote:
>
> On Wed, Apr 21, 2021 at 03:00:41PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 94edd87a1c59f3efa6fdf4e98d6d492e6cec6173.
> >
> > 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.
> >
> > Cc: Aditya Pakki <[email protected]>
> > Cc: Devesh Sharma <[email protected]>
> > Cc: Jason Gunthorpe <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/infiniband/hw/bnxt_re/qplib_sp.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
>
> Can't see a reason to revert this one, I re-checked the callers error
> paths and it looks OK
>
> Jason
Acked-By: Devesh Sharma <[email protected]>
--
-Regards
Devesh
On Wed, Apr 21, 2021 at 02:58:23PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 90a239ee25fa3a483facec3de7c144361a3d3a51.
>
> 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.
>
> Cc: https
> Cc: Aditya Pakki <[email protected]>
> Cc: Dennis Dalessandro <[email protected]>
> Cc: Jason Gunthorpe <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/infiniband/sw/rdmavt/qp.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
While I don't see anything obviously wrong here it is tricky enough
that I would revert it unless Dennis says otherwise.
Jason
Hello,
On 21/04/2021 15:00:17+0200, Greg Kroah-Hartman wrote:
> This reverts commit 9a20b5e35a536d6bb4b2d4a3b14a0457e205356c.
>
> 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.
>
There is really nothing wrong in the patch, it was not completely useful
but not wrong either.
> Cc: Kangjie Lu <[email protected]>
> Cc: Alexandre Belloni <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/rtc/rtc-hym8563.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/rtc/rtc-hym8563.c b/drivers/rtc/rtc-hym8563.c
> index 0751cae27285..a9d033eff61e 100644
> --- a/drivers/rtc/rtc-hym8563.c
> +++ b/drivers/rtc/rtc-hym8563.c
> @@ -94,8 +94,6 @@ static int hym8563_rtc_read_time(struct device *dev, struct rtc_time *tm)
> int ret;
>
> ret = i2c_smbus_read_i2c_block_data(client, HYM8563_SEC, 7, buf);
> - if (ret < 0)
> - return ret;
>
> if (buf[0] & HYM8563_SEC_VL) {
> dev_warn(&client->dev,
> --
> 2.31.1
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
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
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
SUSE Labs
On Wed, Apr 21, 2021 at 02:58:54PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 9f48db0d4a08624bb9ba847ea40c8abad753b396.
>
> 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.
>
> Cc: https
> Cc: Aditya Pakki <[email protected]>
> Cc: Bart Van Assche <[email protected]>
> Cc: Jason Gunthorpe <[email protected]>
> Cc: Jason Gunthorpe <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/infiniband/ulp/srpt/ib_srpt.c | 2 ++
> 1 file changed, 2 insertions(+)
I think this one is fine
Jason
On Wed, Apr 21, 2021 at 03:00:41PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 94edd87a1c59f3efa6fdf4e98d6d492e6cec6173.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Devesh Sharma <[email protected]>
> Cc: Jason Gunthorpe <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/infiniband/hw/bnxt_re/qplib_sp.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
Can't see a reason to revert this one, I re-checked the callers error
paths and it looks OK
Jason
On Wed, Apr 21, 2021 at 03:00:17PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 9a20b5e35a536d6bb4b2d4a3b14a0457e205356c.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Alexandre Belloni <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/rtc/rtc-hym8563.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/rtc/rtc-hym8563.c b/drivers/rtc/rtc-hym8563.c
> index 0751cae27285..a9d033eff61e 100644
> --- a/drivers/rtc/rtc-hym8563.c
> +++ b/drivers/rtc/rtc-hym8563.c
> @@ -94,8 +94,6 @@ static int hym8563_rtc_read_time(struct device *dev, struct rtc_time *tm)
> int ret;
>
> ret = i2c_smbus_read_i2c_block_data(client, HYM8563_SEC, 7, buf);
> - if (ret < 0)
> - return ret;
>
> if (buf[0] & HYM8563_SEC_VL) {
> dev_warn(&client->dev,
Seems like this one was a valid fix, and that the description matched
what was done; plenty of other drivers also proceed similarly. I suspect
it should be kept.
Willy
On 2021-04-21 8:58 a.m., Greg Kroah-Hartman wrote:
> This reverts commit 20eca0123a35305e38b344d571cf32768854168c.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: Felix Kuehling <[email protected]>
> Cc: Felix Kuehling <[email protected]>
> Cc: Alex Deucher <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
As far as I can tell, this patch was correct and should not be reverted.
Thanks,
Felix
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 20 +++++---------------
> 1 file changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
> index 0be72789ccbc..d3c3fa25c2cc 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
> @@ -637,10 +637,8 @@ static int kfd_build_sysfs_node_entry(struct kfd_topology_device *dev,
>
> ret = kobject_init_and_add(dev->kobj_node, &node_type,
> sys_props.kobj_nodes, "%d", id);
> - if (ret < 0) {
> - kobject_put(dev->kobj_node);
> + if (ret < 0)
> return ret;
> - }
>
> dev->kobj_mem = kobject_create_and_add("mem_banks", dev->kobj_node);
> if (!dev->kobj_mem)
> @@ -687,10 +685,8 @@ static int kfd_build_sysfs_node_entry(struct kfd_topology_device *dev,
> return -ENOMEM;
> ret = kobject_init_and_add(mem->kobj, &mem_type,
> dev->kobj_mem, "%d", i);
> - if (ret < 0) {
> - kobject_put(mem->kobj);
> + if (ret < 0)
> return ret;
> - }
>
> mem->attr.name = "properties";
> mem->attr.mode = KFD_SYSFS_FILE_MODE;
> @@ -708,10 +704,8 @@ static int kfd_build_sysfs_node_entry(struct kfd_topology_device *dev,
> return -ENOMEM;
> ret = kobject_init_and_add(cache->kobj, &cache_type,
> dev->kobj_cache, "%d", i);
> - if (ret < 0) {
> - kobject_put(cache->kobj);
> + if (ret < 0)
> return ret;
> - }
>
> cache->attr.name = "properties";
> cache->attr.mode = KFD_SYSFS_FILE_MODE;
> @@ -729,10 +723,8 @@ static int kfd_build_sysfs_node_entry(struct kfd_topology_device *dev,
> return -ENOMEM;
> ret = kobject_init_and_add(iolink->kobj, &iolink_type,
> dev->kobj_iolink, "%d", i);
> - if (ret < 0) {
> - kobject_put(iolink->kobj);
> + if (ret < 0)
> return ret;
> - }
>
> iolink->attr.name = "properties";
> iolink->attr.mode = KFD_SYSFS_FILE_MODE;
> @@ -811,10 +803,8 @@ static int kfd_topology_update_sysfs(void)
> ret = kobject_init_and_add(sys_props.kobj_topology,
> &sysprops_type, &kfd_device->kobj,
> "topology");
> - if (ret < 0) {
> - kobject_put(sys_props.kobj_topology);
> + if (ret < 0)
> return ret;
> - }
>
> sys_props.kobj_nodes = kobject_create_and_add("nodes",
> sys_props.kobj_topology);
On Wed, 21 Apr 2021, Greg Kroah-Hartman wrote:
> This reverts commit 6c44b15e1c9076d925d5236ddadf1318b0a25ce2.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Jiri Kosina <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
This particular one doesn't have to be reverted, I have reviewed it again
and it does fix an actual bug.
Thanks,
--
Jiri Kosina
SUSE Labs
Hi Greg,
Thanks for taking for preventing this type of abuse.
On Wed, 21 Apr 2021 at 15:03, Greg Kroah-Hartman
<[email protected]> wrote:
>
> This reverts commit d0675b67b42eb4f1a840d1513b5b00f78312f833.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: Hans Verkuil <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
I think this patch is good, NAK.
Rob.
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.
--
Jiri Kosina
SUSE Labs
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.
--
Jiri Kosina
SUSE Labs
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/
--
Regards,
Laurent Pinchart
On 2021-04-21, Greg Kroah-Hartman wrote:
> This reverts commit bd23a7269834dc7c1f93e83535d16ebc44b75eba.
>
> - *((struct vbg_ioctl_hdr *)buf) = hdr;
> - if (copy_from_user(buf + sizeof(hdr), (void *)arg + sizeof(hdr),
> - hdr.size_in - sizeof(hdr))) {
> + if (copy_from_user(buf, (void *)arg, hdr.size_in)) {
> ret = -EFAULT;
> goto out;
> }
This one seems like a real bugfix, otherwise there's a double-fetch from
userspace, and a TOCTOU with the hdr fields that could cause a OOB read.
Reviewed-by: Tavis Ormandy <[email protected]>
Tavis.
--
_o) $ lynx lock.cmpxchg8b.com
/\\ _o) _o) $ finger [email protected]
_\_V _( ) _( ) @taviso
On Wed, Apr 21, 2021 at 09:44:52AM -0500, Kangjie Lu wrote:
> On Wed, Apr 21, 2021 at 9:32 AM Jiri Kosina <[email protected]> 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 <[email protected]>, 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
Hi,
On Wed, Apr 21, 2021 at 02:58:46PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 1d7a7128a2e9e1f137c99b0a44e94d70a77343e3.
>
> 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.
>
> Cc: [email protected]
> Cc: Qiushi Wu <[email protected]>
> Cc: Sebastian Reichel <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
Change is quite simple, so doing another review now:
It is correct that power_supply_hwmon_bitmap_free() must be called
when devm_add_action() fails. This is not already done in the error
path, so the original patch is correct and the revert reintroduces a
memory leak in error path.
I suggest dropping the revert.
Thanks,
-- Sebastian
> drivers/power/supply/power_supply_hwmon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/power/supply/power_supply_hwmon.c b/drivers/power/supply/power_supply_hwmon.c
> index bffe6d84c429..62ca29e0d47a 100644
> --- a/drivers/power/supply/power_supply_hwmon.c
> +++ b/drivers/power/supply/power_supply_hwmon.c
> @@ -356,7 +356,7 @@ int power_supply_add_hwmon_sysfs(struct power_supply *psy)
> goto error;
> }
>
> - ret = devm_add_action_or_reset(dev, power_supply_hwmon_bitmap_free,
> + ret = devm_add_action(dev, power_supply_hwmon_bitmap_free,
> psyhw->props);
> if (ret)
> goto error;
> --
> 2.31.1
>
On Wed, Apr 21, 2021 at 12:18:44PM -0400, Paul Moore wrote:
> On Wed, Apr 21, 2021 at 9:04 AM Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This reverts commit 70c4cf17e445264453bc5323db3e50aa0ac9e81f.
> >
> > 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.
> >
> > Cc: Wenwen Wang <[email protected]>
> > Cc: Richard Guy Briggs <[email protected]>
> > Cc: Paul Moore <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > kernel/auditfilter.c | 12 +++++-------
> > 1 file changed, 5 insertions(+), 7 deletions(-)
>
> NACK on this revert. I've looked at the original patch again this
> morning, and the original patch still looks correct and doesn't appear
> to introduce any new faults to the best of my understanding.
>
Thanks for the review, much appreciate it, I'll drop it.
greg k-h
On Wed, 21 Apr 2021 15:00:02 +0200,
Greg Kroah-Hartman wrote:
>
> This reverts commit dcd0feac9bab901d5739de51b3f69840851f8919.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Takashi Iwai <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
This code change itself looks OK, OTOH, the original commit message is
slightly wrong: the code path can never result in NULL deference in
this case, as it's just an optional resource reservation. So, it's
safe to revert this.
thanks,
Takashi
> ---
> sound/isa/sb/sb8.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/sound/isa/sb/sb8.c b/sound/isa/sb/sb8.c
> index 6c9d534ce8b6..95290ffe5c6e 100644
> --- a/sound/isa/sb/sb8.c
> +++ b/sound/isa/sb/sb8.c
> @@ -95,10 +95,6 @@ static int snd_sb8_probe(struct device *pdev, unsigned int dev)
>
> /* block the 0x388 port to avoid PnP conflicts */
> acard->fm_res = request_region(0x388, 4, "SoundBlaster FM");
> - if (!acard->fm_res) {
> - err = -EBUSY;
> - goto _err;
> - }
>
> if (port[dev] != SNDRV_AUTO_PORT) {
> if ((err = snd_sbdsp_create(card, port[dev], irq[dev],
> --
> 2.31.1
>
Hi Greg,
On 4/21/21 3:01 PM, Greg Kroah-Hartman wrote:
> This reverts commit bd23a7269834dc7c1f93e83535d16ebc44b75eba.
>
> 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.
>
> Cc: Wenwen Wang <[email protected]>
> Cc: Hans de Goede <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Ugh what a mess (the whole umn.edu thing).
I still remember reviewing this patch during its original submission
and I've reviewed it again this morning when you just send it out.
And now after letting it sit for a bit I've reviewed it a third time
and it seems to do what it says on the label / in the original commit
msg; and if fixes a real, potentially security, issue.
I'm not sure what the process is for "good" patches in the set
which you are reverting. I would prefer for this patch to be dropped
from the set of reveert. But I can also submit a revert of the revert(?)
once this set of reverts has been merged.
Regards,
Hans
> ---
> drivers/virt/vboxguest/vboxguest_linux.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/virt/vboxguest/vboxguest_linux.c b/drivers/virt/vboxguest/vboxguest_linux.c
> index 73eb34849eab..f5cd9cfa1ef6 100644
> --- a/drivers/virt/vboxguest/vboxguest_linux.c
> +++ b/drivers/virt/vboxguest/vboxguest_linux.c
> @@ -142,9 +142,7 @@ static long vbg_misc_device_ioctl(struct file *filp, unsigned int req,
> if (!buf)
> return -ENOMEM;
>
> - *((struct vbg_ioctl_hdr *)buf) = hdr;
> - if (copy_from_user(buf + sizeof(hdr), (void *)arg + sizeof(hdr),
> - hdr.size_in - sizeof(hdr))) {
> + if (copy_from_user(buf, (void *)arg, hdr.size_in)) {
> ret = -EFAULT;
> goto out;
> }
>
On Wed, Apr 21, 2021 at 06:51:24PM +0200, Hans de Goede wrote:
> Hi Greg,
>
> On 4/21/21 3:01 PM, Greg Kroah-Hartman wrote:
> > This reverts commit bd23a7269834dc7c1f93e83535d16ebc44b75eba.
> >
> > 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.
> >
> > Cc: Wenwen Wang <[email protected]>
> > Cc: Hans de Goede <[email protected]>
> > Cc: Greg Kroah-Hartman <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> Ugh what a mess (the whole umn.edu thing).
>
> I still remember reviewing this patch during its original submission
> and I've reviewed it again this morning when you just send it out.
>
> And now after letting it sit for a bit I've reviewed it a third time
> and it seems to do what it says on the label / in the original commit
> msg; and if fixes a real, potentially security, issue.
>
> I'm not sure what the process is for "good" patches in the set
> which you are reverting. I would prefer for this patch to be dropped
> from the set of reveert. But I can also submit a revert of the revert(?)
> once this set of reverts has been merged.
If you have reviewed it, and think it should stay, I will drop the
revert from my patch series. Other maintainers/reviewers have asked the
same thing for their patches, which is fine.
Anything that I do end up reverting, that was not reviewed, will be
again reviewed by me and others to determine if it is "safe" to come
back in at a later point in time.
So thanks for the review, I'll drop this one.
thanks,
greg k-h
On 2021-04-21 12:18, Paul Moore wrote:
> On Wed, Apr 21, 2021 at 9:04 AM Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This reverts commit 70c4cf17e445264453bc5323db3e50aa0ac9e81f.
> >
> > 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.
> >
> > Cc: Wenwen Wang <[email protected]>
> > Cc: Richard Guy Briggs <[email protected]>
> > Cc: Paul Moore <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > kernel/auditfilter.c | 12 +++++-------
> > 1 file changed, 5 insertions(+), 7 deletions(-)
>
> NACK on this revert. I've looked at the original patch again this
> morning, and the original patch still looks correct and doesn't appear
> to introduce any new faults to the best of my understanding.
Agreed. Though on review, a much simpler fix to my original patch that
caused this problem requiring this fix
e85322d21cfebeac64f58a204e9adc0bc5c1e46f rgb 2014-10-02 ("audit: cull redundancy in audit_rule_change")
would have been the two-liner in the error path similar to the pattern
in audit_data_to_entry() error path would have been:
if (entry->rule.tree)
audit_put_tree(entry->rule.tree); /* that's the temporary one */
> > diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
> > index 333b3bcfc545..19f908b96000 100644
> > --- a/kernel/auditfilter.c
> > +++ b/kernel/auditfilter.c
> > @@ -1125,24 +1125,22 @@ int audit_rule_change(int type, int seq, void *data, size_t datasz)
> > int err = 0;
> > struct audit_entry *entry;
> >
> > + entry = audit_data_to_entry(data, datasz);
> > + if (IS_ERR(entry))
> > + return PTR_ERR(entry);
> > +
> > switch (type) {
> > case AUDIT_ADD_RULE:
> > - entry = audit_data_to_entry(data, datasz);
> > - if (IS_ERR(entry))
> > - return PTR_ERR(entry);
> > err = audit_add_rule(entry);
> > audit_log_rule_change("add_rule", &entry->rule, !err);
> > break;
> > case AUDIT_DEL_RULE:
> > - entry = audit_data_to_entry(data, datasz);
> > - if (IS_ERR(entry))
> > - return PTR_ERR(entry);
> > err = audit_del_rule(entry);
> > audit_log_rule_change("remove_rule", &entry->rule, !err);
> > break;
> > default:
> > + err = -EINVAL;
> > WARN_ON(1);
> > - return -EINVAL;
> > }
> >
> > if (err || type == AUDIT_DEL_RULE) {
> > --
> > 2.31.1
>
> --
> paul moore
> http://www.paul-moore.com
>
- RGB
--
Richard Guy Briggs <[email protected]>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
Hi Greg,
On Wed, Apr 21, 2021 at 03:00:32PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit e85bb0beb6498c0dffe18a2f1f16d575bc175c32.
>
> 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 one looks really OK to me and does not have to be reverted (unless
Aditya will come clean and show the error introduced?).
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Dmitry Torokhov <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/input/touchscreen/ad7879.c | 11 ++++-------
> 1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/input/touchscreen/ad7879.c b/drivers/input/touchscreen/ad7879.c
> index e850853328f1..8c4f3c193550 100644
> --- a/drivers/input/touchscreen/ad7879.c
> +++ b/drivers/input/touchscreen/ad7879.c
> @@ -245,14 +245,11 @@ static void ad7879_timer(struct timer_list *t)
> static irqreturn_t ad7879_irq(int irq, void *handle)
> {
> struct ad7879 *ts = handle;
> - int error;
>
> - error = regmap_bulk_read(ts->regmap, AD7879_REG_XPLUS,
> - ts->conversion_data, AD7879_NR_SENSE);
> - if (error)
> - dev_err_ratelimited(ts->dev, "failed to read %#02x: %d\n",
> - AD7879_REG_XPLUS, error);
> - else if (!ad7879_report(ts))
> + regmap_bulk_read(ts->regmap, AD7879_REG_XPLUS,
> + ts->conversion_data, AD7879_NR_SENSE);
> +
> + if (!ad7879_report(ts))
> mod_timer(&ts->timer, jiffies + TS_PEN_UP_TIMEOUT);
>
> return IRQ_HANDLED;
> --
> 2.31.1
>
Thanks.
--
Dmitry
On Wed, Apr 21, 2021 at 11:13:29AM -0500, Tyler Hicks wrote:
> > It *is* functionally harmless, AFAICS, but only because the condition
> > is really impossible. However,
> > * it refers to vague (s)tool they'd produced, nevermind that
> > all they really do is "find BUG_ON(), replace with returning an error".
> > * unlike BUG_ON(), the replacement does *NOT* document the
> > fact that condition should be impossible.
> > IMO either should be sufficient for rejecting the patch.
>
> I agree that it was not a malicious change. There are other places
> within the same function that return -EINVAL and the expectation is that
> errors from this function should be handled safely.
Umm... Assuming that failure exits in the callers will function properly
if those conditions are true. Which is not obvious at all.
> That said, I can find no real-world reports of this BUG_ON() ever being
> a problem and I don't think that there's any actual need for this
> change. So, I'm alright with it being reverted considering the
> circumstances.
AFAICS, at least some parts of that BUG_ON() are provably impossible
(e.g. NULL crypt_stat would've oopsed well upstream of the only call
of that function). ECRYPTFS_STRUCT_INITIALIZED is set after
ecryptfs_alloc_inode() and never cleared, i.e. it should be present
in ecryptfs_inode_to_private(ecryptfs_inode)->crypt_stat.flags for
all inodes. And crypt_stat we are passing to that thing is
calculated as &(ecryptfs_inode_to_private(ecryptfs_inode)->crypt_stat),
which is another reason why it can't be NULL.
Incidentally, what's ecryptfs_setattr() doing with similar check?
It had been introduced in e10f281bca03 "eCryptfs: initialize crypt_stat
in setattr", which claims
Recent changes in eCryptfs have made it possible to get to ecryptfs_setattr()
with an uninitialized crypt_stat struct. This results in a wide and colorful
variety of unpleasantries. This patch properly initializes the crypt_stat
structure in ecryptfs_setattr() when it is necessary to do so.
and AFAICS at that point the call of ecryptfs_init_crypt_stat() in
ecryptfs_alloc_inode() had already been there and EXCRYPTFS_STRUCT_INITIALIZED
had been (unconditionally) set by it. So how could that check trigger in
ecryptfs_setattr()? No direct calls of that function (then as well as now),
it's only reachable as ecryptfs_{symlink,dir,main}_iops.setattr. The first
two could only end up set by ecryptfs_interpose(), for inode returned by
iget5_locked() (i.e. one that had been returned by ->alloc_inode()),
the last is set by ecryptfs_init_inode(), called by ecryptfs_inode_set(),
passed as callback to iget5_locked() by the same ecryptfs_interpose().
IOW, again, the inode must have been returned by ->alloc_inode().
I realize that it had been a long time ago, but... could somebody
recall what that patch had been about? Michael?
Commit in question contains another (and much bigger) chunk; do
the comments in commit message refer to it? Because it really
looks like
if (!(crypt_stat->flags & ECRYPTFS_STRUCT_INITIALIZED))
ecryptfs_init_crypt_stat(crypt_stat);
part in ecryptfs_setattr() is a confusing no-op...
On Wed, Apr 21, 2021 at 1:03 PM Richard Guy Briggs <[email protected]> wrote:
> On 2021-04-21 12:18, Paul Moore wrote:
> > On Wed, Apr 21, 2021 at 9:04 AM Greg Kroah-Hartman
> > <[email protected]> wrote:
> > >
> > > This reverts commit 70c4cf17e445264453bc5323db3e50aa0ac9e81f.
> > >
> > > 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.
> > >
> > > Cc: Wenwen Wang <[email protected]>
> > > Cc: Richard Guy Briggs <[email protected]>
> > > Cc: Paul Moore <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > ---
> > > kernel/auditfilter.c | 12 +++++-------
> > > 1 file changed, 5 insertions(+), 7 deletions(-)
> >
> > NACK on this revert. I've looked at the original patch again this
> > morning, and the original patch still looks correct and doesn't appear
> > to introduce any new faults to the best of my understanding.
>
> Agreed. Though on review, a much simpler fix to my original patch that
> caused this problem requiring this fix
> e85322d21cfebeac64f58a204e9adc0bc5c1e46f rgb 2014-10-02 ("audit: cull redundancy in audit_rule_change")
> would have been the two-liner in the error path similar to the pattern
> in audit_data_to_entry() error path would have been:
>
> if (entry->rule.tree)
> audit_put_tree(entry->rule.tree); /* that's the temporary one */
Given the situation this morning I think it is best to limit
discussion on this thread to just the safety of the patches in
question and the necessity of the reverts Greg is proposing here. If
you have suggestions about how to clean-up or otherwise improve the
code relating to these patches I think it is better to have that
discussion in the appropriate subsystem list/forum/etc (as one would
do normally).
--
paul moore
http://www.paul-moore.com
On Wed, Apr 21, 2021 at 3:01 PM Greg Kroah-Hartman
<[email protected]> 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 <[email protected]>
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
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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 <[email protected]>
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.
On 4/21/2021 2:58 PM, Greg Kroah-Hartman wrote:
> This reverts commit 4d8be4bc94f74bb7d096e1c2e44457b530d5a170.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: 4.10+ <[email protected]> # 4.10+
> Cc: Rafael J. Wysocki <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
> ---
> drivers/acpi/cppc_acpi.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> index 69057fcd2c04..42650b34e45e 100644
> --- a/drivers/acpi/cppc_acpi.c
> +++ b/drivers/acpi/cppc_acpi.c
> @@ -830,7 +830,6 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr)
> "acpi_cppc");
> if (ret) {
> per_cpu(cpc_desc_ptr, pr->id) = NULL;
> - kobject_put(&cpc_ptr->kobj);
> goto out_free;
> }
>
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
On 4/21/2021 2:58 PM, Greg Kroah-Hartman wrote:
> This reverts commit c343bf1ba5efcbf2266a1fe3baefec9cc82f867f.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: Rafael J. Wysocki <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
> ---
> drivers/cpuidle/sysfs.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
> index 53ec9585ccd4..23a219cedbdb 100644
> --- a/drivers/cpuidle/sysfs.c
> +++ b/drivers/cpuidle/sysfs.c
> @@ -487,7 +487,7 @@ static int cpuidle_add_state_sysfs(struct cpuidle_device *device)
> ret = kobject_init_and_add(&kobj->kobj, &ktype_state_cpuidle,
> &kdev->kobj, "state%d", i);
> if (ret) {
> - kobject_put(&kobj->kobj);
> + kfree(kobj);
> goto error_state;
> }
> cpuidle_add_s2idle_attr_group(kobj);
> @@ -618,7 +618,7 @@ static int cpuidle_add_driver_sysfs(struct cpuidle_device *dev)
> ret = kobject_init_and_add(&kdrv->kobj, &ktype_driver_cpuidle,
> &kdev->kobj, "driver");
> if (ret) {
> - kobject_put(&kdrv->kobj);
> + kfree(kdrv);
> return ret;
> }
>
> @@ -712,7 +712,7 @@ int cpuidle_add_sysfs(struct cpuidle_device *dev)
> error = kobject_init_and_add(&kdev->kobj, &ktype_cpuidle, &cpu_dev->kobj,
> "cpuidle");
> if (error) {
> - kobject_put(&kdev->kobj);
> + kfree(kdev);
> return error;
> }
>
> I think this patch is good, NAK.
Let me revise this, if this series is going to be reverted in its
entirety, feel free to add my a-b.
Acked-by: Robert Foss <[email protected]>
Greg Kroah-Hartman <[email protected]> writes:
> This reverts commit 25bf943e4e7b47282bd86ae7d39e039217ebb007.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: https
Cc https looks wrong.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
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 <[email protected]>
> 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
Hi Greg,
On Wed, Apr 21, 2021 at 3:06 PM Greg Kroah-Hartman
<[email protected]> wrote:
> This reverts commit d39083234c60519724c6ed59509a2129fd2aed41.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Geert Uytterhoeven <[email protected]>
> Cc: Hans Verkuil <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Upon a second look, I still see nothing wrong with the original commit.
However, as I'm no v4l expert, I'd like to defer to the experts for final
judgement.
> --- a/drivers/media/platform/rcar_drif.c
> +++ b/drivers/media/platform/rcar_drif.c
> @@ -915,7 +915,6 @@ static int rcar_drif_g_fmt_sdr_cap(struct file *file, void *priv,
> {
> struct rcar_drif_sdr *sdr = video_drvdata(file);
>
> - memset(f->fmt.sdr.reserved, 0, sizeof(f->fmt.sdr.reserved));
> f->fmt.sdr.pixelformat = sdr->fmt->pixelformat;
> f->fmt.sdr.buffersize = sdr->fmt->buffersize;
>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
This is a really weird one because the patch actually looks correct
and the revert looks wrong??
ret = pci_enable_device(pdev);
[...dbg statements...]
if (!(pci_resource_flags(pdev, 0) & IORESOURCE_MEM) ||
!(pci_resource_flags(pdev, 1) & IORESOURCE_MEM)) {
dev_err(&pdev->dev, "PCI BAR region not MMIO\n");
ret = -ENOMEM;
goto err_disable_pdev;
}
- R.
On Wed, 21 Apr 2021, Greg Kroah-Hartman wrote:
> This reverts commit c9318a3e0218bc9dacc25be46b9eec363259536f.
>
> 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.
>
> Cc: Wenwen Wang <[email protected]>
> Cc: Adam Radford <[email protected]>
> Cc: Martin K. Petersen <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
The original patch here looks valid and necessary.
Please un-revert.
Reviewed-by: James Morris <[email protected]>
> ---
> drivers/scsi/3w-9xxx.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/scsi/3w-9xxx.c b/drivers/scsi/3w-9xxx.c
> index b96e82de4237..4c5d4ea8a592 100644
> --- a/drivers/scsi/3w-9xxx.c
> +++ b/drivers/scsi/3w-9xxx.c
> @@ -886,11 +886,6 @@ static int twa_chrdev_open(struct inode *inode, struct file *file)
> unsigned int minor_number;
> int retval = TW_IOCTL_ERROR_OS_ENODEV;
>
> - if (!capable(CAP_SYS_ADMIN)) {
> - retval = -EACCES;
> - goto out;
> - }
> -
> minor_number = iminor(inode);
> if (minor_number >= twa_device_extension_count)
> goto out;
> --
> 2.31.1
>
--
James Morris
<[email protected]>
On Wed, 21 Apr 2021, Greg Kroah-Hartman wrote:
> This reverts commit 2bb3207dbbd4d30e96dd0e1c8e013104193bd59c.
>
> 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.
>
> Cc: Wenwen Wang <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> net/ethtool/ioctl.c | 3 ---
> 1 file changed, 3 deletions(-)
The original patch looks valid and fixes a race.
Reviewed-by: James Morris <[email protected]>
--
James Morris
<[email protected]>
On Wed, Apr 21, 2021 at 02:59:48PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 2e84f116afca3719c9d0a1a78b47b48f75fd5724.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Cc: [email protected]
> Cc: Borislav Petkov <[email protected]>
> Cc: "H. Peter Anvin" <[email protected]>
> Cc: Kees Cook <[email protected]>
> Cc: Joe Perches <[email protected]>
> Cc: Nicolai Stange <[email protected]>
> Cc: Roland Dreier <[email protected]>
> Cc: https
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> arch/x86/kernel/hpet.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> index 08651a4e6aa0..0515a97bf6f5 100644
> --- a/arch/x86/kernel/hpet.c
> +++ b/arch/x86/kernel/hpet.c
> @@ -930,8 +930,6 @@ int __init hpet_enable(void)
> return 0;
>
> hpet_set_mapping();
> - if (!hpet_virt_address)
> - return 0;
>
> /* Validate that the config register is working */
> if (!hpet_cfg_working())
FWIW, this patch looks harmless. It is checking for a failure in
hpet_set_mapping(), and avoids the following code from performing
0-offset reads. hpet_set_mapping() is likely to never fail in real-world
situations. *shrug*
I think it would make more sense for the check to live in
hpet_cfg_working(), though.
--
Kees Cook
On Wed, 21 Apr 2021, Greg Kroah-Hartman wrote:
> This reverts commit d656fe49e33df48ee6bc19e871f5862f49895c9e.
>
> 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.
>
> Cc: Wenwen Wang <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
The original patch looks valid and fixes a race.
Reviewed-by: James Morris <[email protected]>
> ---
> net/ethtool/ioctl.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/net/ethtool/ioctl.c b/net/ethtool/ioctl.c
> index 807bc9465add..542f2428014c 100644
> --- a/net/ethtool/ioctl.c
> +++ b/net/ethtool/ioctl.c
> @@ -869,11 +869,6 @@ static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev,
> info_size = sizeof(info);
> if (copy_from_user(&info, useraddr, info_size))
> return -EFAULT;
> - /* Since malicious users may modify the original data,
> - * we need to check whether FLOW_RSS is still requested.
> - */
> - if (!(info.flow_type & FLOW_RSS))
> - return -EINVAL;
> }
>
> if (info.cmd == ETHTOOL_GRXCLSRLALL) {
> --
> 2.31.1
>
--
James Morris
<[email protected]>
On Wed, 21 Apr 2021, Greg Kroah-Hartman wrote:
> This reverts commit 106204b56f60abf1bead7dceb88f2be3e34433da.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Mika Westerberg <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/thunderbolt/property.c | 5 -----
> 1 file changed, 5 deletions(-)
The original patch looks correct.
Reviewed-by: James Morris <[email protected]>
>
> diff --git a/drivers/thunderbolt/property.c b/drivers/thunderbolt/property.c
> index ee76449524a3..b2f0d6386cee 100644
> --- a/drivers/thunderbolt/property.c
> +++ b/drivers/thunderbolt/property.c
> @@ -548,11 +548,6 @@ int tb_property_add_data(struct tb_property_dir *parent, const char *key,
>
> property->length = size / 4;
> property->value.data = kzalloc(size, GFP_KERNEL);
> - if (!property->value.data) {
> - kfree(property);
> - return -ENOMEM;
> - }
> -
> memcpy(property->value.data, buf, buflen);
>
> list_add_tail(&property->list, &parent->properties);
> --
> 2.31.1
>
--
James Morris
<[email protected]>
On 21.04.2021 16:00, Greg Kroah-Hartman wrote:
> This reverts commit 0eb987c874dc93f9c9d85a6465dbde20fdd3884c.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Kirill Tkhai <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> net/core/net_namespace.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index 43b6ac4c4439..9ae0b275238e 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -1101,8 +1101,7 @@ static int __init net_ns_init(void)
> init_net_initialized = true;
> up_write(&pernet_ops_rwsem);
>
> - if (register_pernet_subsys(&net_ns_ops))
> - panic("Could not register network namespace subsystems");
> + register_pernet_subsys(&net_ns_ops);
Nacked-by: Kirill Tkhai <[email protected]>
This patch does not have any problem, since it has been already carefully reviewed.
Kernel panics here only, if we can't allocate ns_common::inum for init_net.
This can be only a result of a critical deficiency of memory during boot.
Hi Geert,
On Wed, Apr 21, 2021 at 08:58:22PM +0200, Geert Uytterhoeven wrote:
> On Wed, Apr 21, 2021 at 3:06 PM Greg Kroah-Hartman wrote:
> > This reverts commit d39083234c60519724c6ed59509a2129fd2aed41.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Geert Uytterhoeven <[email protected]>
> > Cc: Hans Verkuil <[email protected]>
> > Cc: Mauro Carvalho Chehab <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> Upon a second look, I still see nothing wrong with the original commit.
> However, as I'm no v4l expert, I'd like to defer to the experts for final
> judgement.
It seems fine to me, but it also seems unneeded, as the V4L2 core clears
the whole f->fmt union before calling this operation. The revert will
this improve performance very slightly.
> > --- a/drivers/media/platform/rcar_drif.c
> > +++ b/drivers/media/platform/rcar_drif.c
> > @@ -915,7 +915,6 @@ static int rcar_drif_g_fmt_sdr_cap(struct file *file, void *priv,
> > {
> > struct rcar_drif_sdr *sdr = video_drvdata(file);
> >
> > - memset(f->fmt.sdr.reserved, 0, sizeof(f->fmt.sdr.reserved));
> > f->fmt.sdr.pixelformat = sdr->fmt->pixelformat;
> > f->fmt.sdr.buffersize = sdr->fmt->buffersize;
> >
--
Regards,
Laurent Pinchart
On 4/21/2021 6:00 AM, Greg Kroah-Hartman wrote:
> This reverts commit e49505f7255be8ced695919c08a29bf2c3d79616.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
While this commit does not fix a known problem, the driver should have
arguably propagated the return values and it did not, so I would be
inclined to keep it.
--
Florian
On Wed, Apr 21, 2021 at 3:01 PM Greg Kroah-Hartman
<[email protected]> 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
On 2021-04-21 17:03:24, Al Viro wrote:
> On Wed, Apr 21, 2021 at 11:13:29AM -0500, Tyler Hicks wrote:
>
> > > It *is* functionally harmless, AFAICS, but only because the condition
> > > is really impossible. However,
> > > * it refers to vague (s)tool they'd produced, nevermind that
> > > all they really do is "find BUG_ON(), replace with returning an error".
> > > * unlike BUG_ON(), the replacement does *NOT* document the
> > > fact that condition should be impossible.
> > > IMO either should be sufficient for rejecting the patch.
> >
> > I agree that it was not a malicious change. There are other places
> > within the same function that return -EINVAL and the expectation is that
> > errors from this function should be handled safely.
>
> Umm... Assuming that failure exits in the callers will function properly
> if those conditions are true. Which is not obvious at all.
>
> > That said, I can find no real-world reports of this BUG_ON() ever being
> > a problem and I don't think that there's any actual need for this
> > change. So, I'm alright with it being reverted considering the
> > circumstances.
>
> AFAICS, at least some parts of that BUG_ON() are provably impossible
> (e.g. NULL crypt_stat would've oopsed well upstream of the only call
> of that function). ECRYPTFS_STRUCT_INITIALIZED is set after
> ecryptfs_alloc_inode() and never cleared, i.e. it should be present
> in ecryptfs_inode_to_private(ecryptfs_inode)->crypt_stat.flags for
> all inodes. And crypt_stat we are passing to that thing is
> calculated as &(ecryptfs_inode_to_private(ecryptfs_inode)->crypt_stat),
> which is another reason why it can't be NULL.
I agree.
>
> Incidentally, what's ecryptfs_setattr() doing with similar check?
> It had been introduced in e10f281bca03 "eCryptfs: initialize crypt_stat
> in setattr", which claims
> Recent changes in eCryptfs have made it possible to get to ecryptfs_setattr()
> with an uninitialized crypt_stat struct. This results in a wide and colorful
> variety of unpleasantries. This patch properly initializes the crypt_stat
> structure in ecryptfs_setattr() when it is necessary to do so.
> and AFAICS at that point the call of ecryptfs_init_crypt_stat() in
> ecryptfs_alloc_inode() had already been there and EXCRYPTFS_STRUCT_INITIALIZED
> had been (unconditionally) set by it. So how could that check trigger in
> ecryptfs_setattr()? No direct calls of that function (then as well as now),
> it's only reachable as ecryptfs_{symlink,dir,main}_iops.setattr. The first
> two could only end up set by ecryptfs_interpose(), for inode returned by
> iget5_locked() (i.e. one that had been returned by ->alloc_inode()),
> the last is set by ecryptfs_init_inode(), called by ecryptfs_inode_set(),
> passed as callback to iget5_locked() by the same ecryptfs_interpose().
> IOW, again, the inode must have been returned by ->alloc_inode().
>
> I realize that it had been a long time ago, but... could somebody
> recall what that patch had been about? Michael?
I looked through the commits that proceeded e10f281bca03 and the only
thing I can think of is the addition of "passthrough" mode where the
lower, encrypted data can be directly read from the eCryptfs mount. It
was introduced in commit e77a56ddceee ("[PATCH] eCryptfs: Encrypted
passthrough"), several months before e10f281bca03. However, I don't see
how it would have left us with an uninitialized crypt_stat in setattr.
Tyler
> Commit in question contains another (and much bigger) chunk; do
> the comments in commit message refer to it? Because it really
> looks like
> if (!(crypt_stat->flags & ECRYPTFS_STRUCT_INITIALIZED))
> ecryptfs_init_crypt_stat(crypt_stat);
> part in ecryptfs_setattr() is a confusing no-op...
On Wed, 21 Apr 2021 15:00:01 +0200
Greg Kroah-Hartman <[email protected]> wrote:
> This reverts commit 6f19893b644a9454d85e593b5e90914e7a72b7dd.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> net/openvswitch/datapath.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> index 9d6ef6cb9b26..99e63f4bbcaf 100644
> --- a/net/openvswitch/datapath.c
> +++ b/net/openvswitch/datapath.c
> @@ -443,10 +443,6 @@ static int queue_userspace_packet(struct
> datapath *dp, struct sk_buff *skb,
> upcall = genlmsg_put(user_skb, 0, 0, &dp_packet_genl_family,
> 0, upcall_info->cmd);
> - if (!upcall) {
> - err = -EINVAL;
> - goto out;
> - }
> upcall->dp_ifindex = dp_ifindex;
>
> err = ovs_nla_put_key(key, key, OVS_PACKET_ATTR_KEY, false,
> user_skb);
This patch seems good to me, but given the situation I'd like another
pair of eyes on it, at least.
Regards,
--
per aspera ad upstream
On Wed, Apr 21, 2021 at 03:14:29PM -0000, Tavis Ormandy wrote:
> On 2021-04-21, Greg Kroah-Hartman wrote:
> > This reverts commit bd23a7269834dc7c1f93e83535d16ebc44b75eba.
> >
> > - *((struct vbg_ioctl_hdr *)buf) = hdr;
> > - if (copy_from_user(buf + sizeof(hdr), (void *)arg + sizeof(hdr),
> > - hdr.size_in - sizeof(hdr))) {
> > + if (copy_from_user(buf, (void *)arg, hdr.size_in)) {
> > ret = -EFAULT;
> > goto out;
> > }
>
> This one seems like a real bugfix, otherwise there's a double-fetch from
> userspace, and a TOCTOU with the hdr fields that could cause a OOB read.
ACK, except that typecasts in there are messy as hell. But that's,
alas, consistent with the rest of the function...
Patch itself is correct, and AFAICS Wenwen Wang <[email protected]>
might be an innocent collateral damage from that mess - commits from that
source appear to be fairly well-written.
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
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/
--
Regards,
Laurent Pinchart
Hi,
On Wed, Apr 21, 2021 at 02:59:27PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 75cf4f5aa903604e1bd7bec2c0988d643c6fb946.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Sebastian Reichel <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
Doing another review:
create_freezable_workqueue can return NULL when allocations fails
and it is the first call in late init call, so it's fine to just
exit with -ENOMEM.
I suggest to drop the revert.
-- Sebastian
> drivers/power/supply/charger-manager.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/power/supply/charger-manager.c b/drivers/power/supply/charger-manager.c
> index 4dea8ecd70bc..f34c07ffcfe6 100644
> --- a/drivers/power/supply/charger-manager.c
> +++ b/drivers/power/supply/charger-manager.c
> @@ -1749,9 +1749,6 @@ static struct platform_driver charger_manager_driver = {
> static int __init charger_manager_init(void)
> {
> cm_wq = create_freezable_workqueue("charger_manager");
> - if (unlikely(!cm_wq))
> - return -ENOMEM;
> -
> INIT_DELAYED_WORK(&cm_monitor_work, cm_monitor_poller);
>
> return platform_driver_register(&charger_manager_driver);
> --
> 2.31.1
>
On Wed, Apr 21, 2021 at 02:59:41PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 1bbb1c318cd8a3a39e8c3e2e83d5e90542d6c3e3.
>
> 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.
I've reviewed the patch at the time and now again with fresh eyes, but
it's IMO a valid fix that would have to be done the same way after
revert.
On Wed, Apr 21, 2021 at 02:58:48PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 2c2a7552dd6465e8fde6bc9cccf8d66ed1c1eb72.
>
> 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.
FWIW, commit message on the original (
ecryptfs: replace BUG_ON with error handling code
In crypt_scatterlist, if the crypt_stat argument is not set up
correctly, the kernel crashes. Instead, by returning an error code
upstream, the error is handled safely.
The issue is detected via a static analysis tool written by us.
Fixes: 237fead619984 (ecryptfs: fs/Makefile and fs/Kconfig)
Signed-off-by: Aditya Pakki <[email protected]>
Signed-off-by: Tyler Hicks <[email protected]>
)
really stinks. First, the analysis: condition being tested is
(!crypt_stat || !crypt_stat->tfm
|| !(crypt_stat->flags & ECRYPTFS_STRUCT_INITIALIZED))
and their patch replaces BUG_ON() with return of -EINVAL. So the
only thing their tool had detected the presence of BUG_ON().
Was it grep, by any chance?
IOW, the commit message is "we'd found BUG_ON(); let's replace it
with returning some error value and hope everything works. Whaddya
mean, how do we know? Our tool [git grep BUG_ON, that is] says
it's there and look, it *is* there, so if it's ever reached there'll
be trouble. What, assertion that returning an error will be handled
safely? 'Cuz we saiz so, that's why"
It *is* functionally harmless, AFAICS, but only because the condition
is really impossible. However,
* it refers to vague (s)tool they'd produced, nevermind that
all they really do is "find BUG_ON(), replace with returning an error".
* unlike BUG_ON(), the replacement does *NOT* document the
fact that condition should be impossible.
IMO either should be sufficient for rejecting the patch.
On Wed, 21 Apr 2021 14:58:45 +0200 Greg Kroah-Hartman wrote:
> This reverts commit bd4af432cc71b5fbfe4833510359a6ad3ada250d.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: Jakub Kicinski <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ethernet/netronome/nfp/abm/main.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/netronome/nfp/abm/main.c b/drivers/net/ethernet/netronome/nfp/abm/main.c
> index bdbf0726145e..341773b43a4d 100644
> --- a/drivers/net/ethernet/netronome/nfp/abm/main.c
> +++ b/drivers/net/ethernet/netronome/nfp/abm/main.c
> @@ -283,7 +283,6 @@ nfp_abm_vnic_set_mac(struct nfp_pf *pf, struct nfp_abm *abm, struct nfp_net *nn,
> if (!nfp_nsp_has_hwinfo_lookup(nsp)) {
> nfp_warn(pf->cpp, "NSP doesn't support PF MAC generation\n");
> eth_hw_addr_random(nn->dp.netdev);
> - nfp_nsp_close(nsp);
> return;
> }
>
This one still looks correct to me :S
[AMD Public Use]
> -----Original Message-----
> From: Greg Kroah-Hartman <[email protected]>
> Sent: Wednesday, April 21, 2021 8:58 AM
> To: [email protected]
> Cc: Greg Kroah-Hartman <[email protected]>; Aditya Pakki
> <[email protected]>; Deucher, Alexander
> <[email protected]>
> Subject: [PATCH 023/190] Revert "drm/radeon: fix multiple reference count
> leak"
>
> This reverts commit 6f2e8acdb48ed166b65d47837c31b177460491ec.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Alex Deucher <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
AFAICT, this patch is correct or at least does no harm. Handling of pm_runtime_get_sync() errors in the kernel seems to be inconsistent at best.
Alex
> ---
> drivers/gpu/drm/radeon/radeon_connectors.c | 20 +++++---------------
> 1 file changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index 607ad5620bd9..ba8885676676 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -879,10 +879,8 @@ radeon_lvds_detect(struct drm_connector
> *connector, bool force)
>
> if (!drm_kms_helper_is_poll_worker()) {
> r = pm_runtime_get_sync(connector->dev->dev);
> - if (r < 0) {
> - pm_runtime_put_autosuspend(connector->dev-
> >dev);
> + if (r < 0)
> return connector_status_disconnected;
> - }
> }
>
> if (encoder) {
> @@ -1027,10 +1025,8 @@ radeon_vga_detect(struct drm_connector
> *connector, bool force)
>
> if (!drm_kms_helper_is_poll_worker()) {
> r = pm_runtime_get_sync(connector->dev->dev);
> - if (r < 0) {
> - pm_runtime_put_autosuspend(connector->dev-
> >dev);
> + if (r < 0)
> return connector_status_disconnected;
> - }
> }
>
> encoder = radeon_best_single_encoder(connector);
> @@ -1167,10 +1163,8 @@ radeon_tv_detect(struct drm_connector
> *connector, bool force)
>
> if (!drm_kms_helper_is_poll_worker()) {
> r = pm_runtime_get_sync(connector->dev->dev);
> - if (r < 0) {
> - pm_runtime_put_autosuspend(connector->dev-
> >dev);
> + if (r < 0)
> return connector_status_disconnected;
> - }
> }
>
> encoder = radeon_best_single_encoder(connector);
> @@ -1253,10 +1247,8 @@ radeon_dvi_detect(struct drm_connector
> *connector, bool force)
>
> if (!drm_kms_helper_is_poll_worker()) {
> r = pm_runtime_get_sync(connector->dev->dev);
> - if (r < 0) {
> - pm_runtime_put_autosuspend(connector->dev-
> >dev);
> + if (r < 0)
> return connector_status_disconnected;
> - }
> }
>
> if (radeon_connector->detected_hpd_without_ddc) { @@ -1665,10
> +1657,8 @@ radeon_dp_detect(struct drm_connector *connector, bool
> force)
>
> if (!drm_kms_helper_is_poll_worker()) {
> r = pm_runtime_get_sync(connector->dev->dev);
> - if (r < 0) {
> - pm_runtime_put_autosuspend(connector->dev-
> >dev);
> + if (r < 0)
> return connector_status_disconnected;
> - }
> }
>
> if (!force && radeon_check_hpd_status_unchanged(connector)) {
> --
> 2.31.1
On Wed, 21 Apr 2021 14:59:15 +0200,
Greg Kroah-Hartman wrote:
>
> This reverts commit cbb88db76a1536e02e93e5bd37ebbfbb6c4043a9.
>
> 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.
>
> Cc: Wenwen Wang <[email protected]>
> Cc: Takashi Iwai <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
I examined the change again, and confirmed that this code change
itself is correct, so it's not necessary to revert.
OTOH, it's just a tip of iceberg in this driver, and maybe it's better
to cover all in a better way. So it's fine to revert this, either.
thanks,
Takashi
> ---
> sound/usb/usx2y/usbusx2y.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/sound/usb/usx2y/usbusx2y.c b/sound/usb/usx2y/usbusx2y.c
> index 3cd28d24f0a7..bb188245b0e2 100644
> --- a/sound/usb/usx2y/usbusx2y.c
> +++ b/sound/usb/usx2y/usbusx2y.c
> @@ -279,8 +279,10 @@ int usX2Y_In04_init(struct usX2Ydev *usX2Y)
> if (! (usX2Y->In04urb = usb_alloc_urb(0, GFP_KERNEL)))
> return -ENOMEM;
>
> - if (! (usX2Y->In04Buf = kmalloc(21, GFP_KERNEL)))
> + if (! (usX2Y->In04Buf = kmalloc(21, GFP_KERNEL))) {
> + usb_free_urb(usX2Y->In04urb);
> return -ENOMEM;
> + }
>
> init_waitqueue_head(&usX2Y->In04WaitQueue);
> usb_fill_int_urb(usX2Y->In04urb, usX2Y->dev, usb_rcvintpipe(usX2Y->dev, 0x4),
> --
> 2.31.1
>
On 4/21/21 7:05 AM, Jason Gunthorpe wrote:
> On Wed, Apr 21, 2021 at 11:02:47AM -0300, Jason Gunthorpe wrote:
>> On Wed, Apr 21, 2021 at 02:58:54PM +0200, Greg Kroah-Hartman wrote:
>>> This reverts commit 9f48db0d4a08624bb9ba847ea40c8abad753b396.
>>>
>>> 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.
>>>
>>> Cc: https
>>> Cc: Aditya Pakki <[email protected]>
>>> Cc: Bart Van Assche <[email protected]>
>>> Cc: Jason Gunthorpe <[email protected]>
>>> Cc: Jason Gunthorpe <[email protected]>
>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>> drivers/infiniband/ulp/srpt/ib_srpt.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>
>> I think this one is fine
>
> Sorry, I realize that is unclear. I mean I don't see a reason to
> revert this patch.
Greg, I share Jason's opinion and would like to see this revert dropped.
The function srpt_queue_response() dereferences the 'ch' pointer before
the BUG_ON(ch) statement is reached. I think this makes the BUG_ON()
statement that would be reintroduced by this revert superfluous.
Thanks,
Bart.
On 2021-04-21 16:04:02, Al Viro wrote:
> On Wed, Apr 21, 2021 at 02:58:48PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 2c2a7552dd6465e8fde6bc9cccf8d66ed1c1eb72.
> >
> > 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.
>
> FWIW, commit message on the original (
> ecryptfs: replace BUG_ON with error handling code
>
> In crypt_scatterlist, if the crypt_stat argument is not set up
> correctly, the kernel crashes. Instead, by returning an error code
> upstream, the error is handled safely.
>
> The issue is detected via a static analysis tool written by us.
>
> Fixes: 237fead619984 (ecryptfs: fs/Makefile and fs/Kconfig)
> Signed-off-by: Aditya Pakki <[email protected]>
> Signed-off-by: Tyler Hicks <[email protected]>
> )
> really stinks. First, the analysis: condition being tested is
> (!crypt_stat || !crypt_stat->tfm
> || !(crypt_stat->flags & ECRYPTFS_STRUCT_INITIALIZED))
> and their patch replaces BUG_ON() with return of -EINVAL. So the
> only thing their tool had detected the presence of BUG_ON().
> Was it grep, by any chance?
>
> IOW, the commit message is "we'd found BUG_ON(); let's replace it
> with returning some error value and hope everything works. Whaddya
> mean, how do we know? Our tool [git grep BUG_ON, that is] says
> it's there and look, it *is* there, so if it's ever reached there'll
> be trouble. What, assertion that returning an error will be handled
> safely? 'Cuz we saiz so, that's why"
>
>
> It *is* functionally harmless, AFAICS, but only because the condition
> is really impossible. However,
> * it refers to vague (s)tool they'd produced, nevermind that
> all they really do is "find BUG_ON(), replace with returning an error".
> * unlike BUG_ON(), the replacement does *NOT* document the
> fact that condition should be impossible.
> IMO either should be sufficient for rejecting the patch.
I agree that it was not a malicious change. There are other places
within the same function that return -EINVAL and the expectation is that
errors from this function should be handled safely.
That said, I can find no real-world reports of this BUG_ON() ever being
a problem and I don't think that there's any actual need for this
change. So, I'm alright with it being reverted considering the
circumstances.
Acked-by: Tyler Hicks <[email protected]>
Tyler
[AMD Public Use]
> -----Original Message-----
> From: Greg Kroah-Hartman <[email protected]>
> Sent: Wednesday, April 21, 2021 8:58 AM
> To: [email protected]
> Cc: Greg Kroah-Hartman <[email protected]>; Quan, Evan
> <[email protected]>; Aditya Pakki <[email protected]>; Deucher,
> Alexander <[email protected]>
> Subject: [PATCH 022/190] Revert "drm/radeon: Fix reference count leaks
> caused by pm_runtime_get_sync"
>
> This reverts commit 9fb10671011143d15b6b40d6d5fa9c52c57e9d63.
>
> 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.
>
> Cc: Evan Quan <[email protected]>
> Cc: Aditya Pakki <[email protected]>
> Cc: Alex Deucher <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
AFAICT, this patch is correct or at least does no harm. Handling of pm_runtime_get_sync() errors in the kernel seems to be inconsistent at best.
Alex
> ---
> drivers/gpu/drm/radeon/radeon_display.c | 4 +---
> drivers/gpu/drm/radeon/radeon_drv.c | 4 +---
> drivers/gpu/drm/radeon/radeon_kms.c | 4 +---
> 3 files changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index 652af7a134bd..9f29ba6c2bed 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -627,10 +627,8 @@ radeon_crtc_set_config(struct drm_mode_set *set,
> dev = set->crtc->dev;
>
> ret = pm_runtime_get_sync(dev->dev);
> - if (ret < 0) {
> - pm_runtime_put_autosuspend(dev->dev);
> + if (ret < 0)
> return ret;
> - }
>
> ret = drm_crtc_helper_set_config(set, ctx);
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index efeb115ae70e..468b364c2dab 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -513,10 +513,8 @@ long radeon_drm_ioctl(struct file *filp,
> long ret;
> dev = file_priv->minor->dev;
> ret = pm_runtime_get_sync(dev->dev);
> - if (ret < 0) {
> - pm_runtime_put_autosuspend(dev->dev);
> + if (ret < 0)
> return ret;
> - }
>
> ret = drm_ioctl(filp, cmd, arg);
>
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 2479d6ab7a36..df644bb68c0f 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -644,10 +644,8 @@ int radeon_driver_open_kms(struct drm_device
> *dev, struct drm_file *file_priv)
> file_priv->driver_priv = NULL;
>
> r = pm_runtime_get_sync(dev->dev);
> - if (r < 0) {
> - pm_runtime_put_autosuspend(dev->dev);
> + if (r < 0)
> return r;
> - }
>
> /* new gpu have virtual address space support */
> if (rdev->family >= CHIP_CAYMAN) {
> --
> 2.31.1
On Wed, Apr 21, 2021 at 9:04 AM Greg Kroah-Hartman
<[email protected]> wrote:
>
> This reverts commit 70c4cf17e445264453bc5323db3e50aa0ac9e81f.
>
> 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.
>
> Cc: Wenwen Wang <[email protected]>
> Cc: Richard Guy Briggs <[email protected]>
> Cc: Paul Moore <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> kernel/auditfilter.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
NACK on this revert. I've looked at the original patch again this
morning, and the original patch still looks correct and doesn't appear
to introduce any new faults to the best of my understanding.
> diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
> index 333b3bcfc545..19f908b96000 100644
> --- a/kernel/auditfilter.c
> +++ b/kernel/auditfilter.c
> @@ -1125,24 +1125,22 @@ int audit_rule_change(int type, int seq, void *data, size_t datasz)
> int err = 0;
> struct audit_entry *entry;
>
> + entry = audit_data_to_entry(data, datasz);
> + if (IS_ERR(entry))
> + return PTR_ERR(entry);
> +
> switch (type) {
> case AUDIT_ADD_RULE:
> - entry = audit_data_to_entry(data, datasz);
> - if (IS_ERR(entry))
> - return PTR_ERR(entry);
> err = audit_add_rule(entry);
> audit_log_rule_change("add_rule", &entry->rule, !err);
> break;
> case AUDIT_DEL_RULE:
> - entry = audit_data_to_entry(data, datasz);
> - if (IS_ERR(entry))
> - return PTR_ERR(entry);
> err = audit_del_rule(entry);
> audit_log_rule_change("remove_rule", &entry->rule, !err);
> break;
> default:
> + err = -EINVAL;
> WARN_ON(1);
> - return -EINVAL;
> }
>
> if (err || type == AUDIT_DEL_RULE) {
> --
> 2.31.1
--
paul moore
http://www.paul-moore.com
Hi,
On Wed, Apr 21, 2021 at 03:00:18PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 6f12e46eebf1a7d4fdd66df5e815df96b8f8b1b5.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Sebastian Reichel <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
Doing another review:
twl4030 is an I2C connected PMIC, so any read operation can
result in -EIO. If this happens 's' will not be initialized,
so without handling the error is_charging will be set to an
arbitrary state in the following lines. Exiting early from
twl4030_bci_get_property is ok and other HW read operation
failures in the same function are exiting early with proper
error code (as the patch introduced for the only read missing
this).
TL;DR: original patch is ok, I suggest to drop the revert.
-- Sebastian
> drivers/power/supply/twl4030_charger.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/power/supply/twl4030_charger.c b/drivers/power/supply/twl4030_charger.c
> index 1bc49b2e12e8..dcbd9f03f31a 100644
> --- a/drivers/power/supply/twl4030_charger.c
> +++ b/drivers/power/supply/twl4030_charger.c
> @@ -805,9 +805,7 @@ static int twl4030_bci_get_property(struct power_supply *psy,
> is_charging = state & TWL4030_MSTATEC_AC;
> if (!is_charging) {
> u8 s;
> - ret = twl4030_bci_read(TWL4030_BCIMDEN, &s);
> - if (ret < 0)
> - return ret;
> + twl4030_bci_read(TWL4030_BCIMDEN, &s);
> if (psy->desc->type == POWER_SUPPLY_TYPE_USB)
> is_charging = s & 1;
> else
> --
> 2.31.1
>
On Wed, 21 Apr 2021 15:00:33 +0200,
Greg Kroah-Hartman wrote:
>
> This reverts commit beae77170c60aa786f3e4599c18ead2854d8694d.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Takashi Iwai <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
The original code change is fine, it's just adding an error return.
OTOH, it would be safe even if we ignore the error, too (the mixer
element is optional), and the driver is quite legacy.
That said, feel free to revert it.
thanks,
Takashi
> ---
> sound/isa/sb/sb16_main.c | 10 +++-------
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/sound/isa/sb/sb16_main.c b/sound/isa/sb/sb16_main.c
> index 38dc1fde25f3..aa4870531023 100644
> --- a/sound/isa/sb/sb16_main.c
> +++ b/sound/isa/sb/sb16_main.c
> @@ -846,14 +846,10 @@ int snd_sb16dsp_pcm(struct snd_sb *chip, int device)
> snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &snd_sb16_playback_ops);
> snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &snd_sb16_capture_ops);
>
> - if (chip->dma16 >= 0 && chip->dma8 != chip->dma16) {
> - err = snd_ctl_add(card, snd_ctl_new1(
> - &snd_sb16_dma_control, chip));
> - if (err)
> - return err;
> - } else {
> + if (chip->dma16 >= 0 && chip->dma8 != chip->dma16)
> + snd_ctl_add(card, snd_ctl_new1(&snd_sb16_dma_control, chip));
> + else
> pcm->info_flags = SNDRV_PCM_INFO_HALF_DUPLEX;
> - }
>
> snd_pcm_set_managed_buffer_all(pcm, SNDRV_DMA_TYPE_DEV,
> card->dev, 64*1024, 128*1024);
> --
> 2.31.1
>
On Wed, 21 Apr 2021 15:00:34 +0200,
Greg Kroah-Hartman wrote:
>
> This reverts commit 0f25e000cb4398081748e54f62a902098aa79ec1.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Takashi Iwai <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
This code change simply adds an error message print out, so it doesn't
actually fix anything, per se (although the code change itself is
fine). Feel free to revert.
thanks,
Takashi
> ---
> sound/isa/gus/gus_main.c | 13 ++-----------
> 1 file changed, 2 insertions(+), 11 deletions(-)
>
> diff --git a/sound/isa/gus/gus_main.c b/sound/isa/gus/gus_main.c
> index afc088f0377c..b7518122a10d 100644
> --- a/sound/isa/gus/gus_main.c
> +++ b/sound/isa/gus/gus_main.c
> @@ -77,17 +77,8 @@ static const struct snd_kcontrol_new snd_gus_joystick_control = {
>
> static void snd_gus_init_control(struct snd_gus_card *gus)
> {
> - int ret;
> -
> - if (!gus->ace_flag) {
> - ret =
> - snd_ctl_add(gus->card,
> - snd_ctl_new1(&snd_gus_joystick_control,
> - gus));
> - if (ret)
> - snd_printk(KERN_ERR "gus: snd_ctl_add failed: %d\n",
> - ret);
> - }
> + if (!gus->ace_flag)
> + snd_ctl_add(gus->card, snd_ctl_new1(&snd_gus_joystick_control, gus));
> }
>
> /*
> --
> 2.31.1
>
On Wed, 21 Apr 2021 15:00:05 +0200,
Greg Kroah-Hartman wrote:
>
> This reverts commit a2c6433ee5a35a8de6d563f6512a26f87835ea0f.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Takashi Iwai <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
This is same like the revert#80, the code change itself seems correct,
but it's a pretty minor error path, probably no one would hit.
So, feel free to revert if it's in doubt.
thanks,
Takashi
> ---
> sound/usb/usx2y/usb_stream.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/sound/usb/usx2y/usb_stream.c b/sound/usb/usx2y/usb_stream.c
> index 091c071b270a..6bba17bf689a 100644
> --- a/sound/usb/usx2y/usb_stream.c
> +++ b/sound/usb/usx2y/usb_stream.c
> @@ -91,12 +91,7 @@ static int init_urbs(struct usb_stream_kernel *sk, unsigned use_packsize,
>
> for (u = 0; u < USB_STREAM_NURBS; ++u) {
> sk->inurb[u] = usb_alloc_urb(sk->n_o_ps, GFP_KERNEL);
> - if (!sk->inurb[u])
> - return -ENOMEM;
> -
> sk->outurb[u] = usb_alloc_urb(sk->n_o_ps, GFP_KERNEL);
> - if (!sk->outurb[u])
> - return -ENOMEM;
> }
>
> if (init_pipe_urbs(sk, use_packsize, sk->inurb, indata, dev, in_pipe) ||
> --
> 2.31.1
>
On Wed, 21 Apr 2021 15:01:02 +0200,
Greg Kroah-Hartman wrote:
>
> This reverts commit 3f12888dfae2a48741c4caa9214885b3aaf350f9.
>
> 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.
>
> Cc: Wenwen Wang <[email protected]>
> Cc: <[email protected]>
> Cc: Takashi Iwai <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
This one is, unlike other patches I've been involved with, about the
ALSA core code, and this change is likely worth to keep.
The code change is correct, and even though it's really a minor issue,
an optimization is right.
thanks,
Takashi
> ---
> sound/core/control_compat.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/sound/core/control_compat.c b/sound/core/control_compat.c
> index 1d708aab9c98..857acf83ae47 100644
> --- a/sound/core/control_compat.c
> +++ b/sound/core/control_compat.c
> @@ -381,7 +381,8 @@ static int snd_ctl_elem_add_compat(struct snd_ctl_file *file,
> if (copy_from_user(&data->id, &data32->id, sizeof(data->id)) ||
> copy_from_user(&data->type, &data32->type, 3 * sizeof(u32)))
> goto error;
> - if (get_user(data->owner, &data32->owner))
> + if (get_user(data->owner, &data32->owner) ||
> + get_user(data->type, &data32->type))
> goto error;
> switch (data->type) {
> case SNDRV_CTL_ELEM_TYPE_BOOLEAN:
> --
> 2.31.1
>
On Wed, Apr 21, 2021 at 06:28:07PM +0200, Takashi Iwai wrote:
> On Wed, 21 Apr 2021 15:00:34 +0200,
> Greg Kroah-Hartman wrote:
> >
> > This reverts commit 0f25e000cb4398081748e54f62a902098aa79ec1.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Takashi Iwai <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> This code change simply adds an error message print out, so it doesn't
> actually fix anything, per se (although the code change itself is
> fine). Feel free to revert.
Many thanks for the reviews!
greg k-h
Greg Kroah-Hartman <[email protected]> wrote:
> This reverts commit f45d01f4f30b53c3a0a1c6c1c154acb7ff74ab9f.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: David Howells <[email protected]>
> Cc: Markus Elfring <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
This is actually a good patch, so please don't revert it.
David
On Wed, Apr 21, 2021 at 8:05 AM Greg Kroah-Hartman
<[email protected]> wrote:
>
> This reverts commit 1d84353d205a953e2381044953b7fa31c8c9702d.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Aditya Pakki <[email protected]>
> Cc: Finn Thain <[email protected]>
> Cc: Rob Herring <[email protected]>
Sigh, get_maintainers.pl likes to punish people for treewide clean-ups...
> Cc: Greg Kroah-Hartman <[email protected]>
> Cc: Bartlomiej Zolnierkiewicz <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/video/fbdev/imsttfb.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c
> index 3ac053b88495..e04411701ec8 100644
> --- a/drivers/video/fbdev/imsttfb.c
> +++ b/drivers/video/fbdev/imsttfb.c
> @@ -1512,11 +1512,6 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> info->fix.smem_start = addr;
> info->screen_base = (__u8 *)ioremap(addr, par->ramdac == IBM ?
> 0x400000 : 0x800000);
> - if (!info->screen_base) {
> - release_mem_region(addr, size);
> - framebuffer_release(info);
> - return -ENOMEM;
> - }
The original change appears to be valid, but incomplete...
> info->fix.mmio_start = addr + 0x800000;
> par->dc_regs = ioremap(addr + 0x800000, 0x1000);
...because what about cleanup when this ioremap fails.
> par->cmap_regs_phys = addr + 0x840000;
Then again, if anyone really cared about this driver and h/w (a
PowerMac era PCI display card), it would not still be using fbdev and
would use devm_* apis.
Rob
On Wed, Apr 21, 2021 at 5:01 PM Matteo Croce <[email protected]> wrote:
>
> On Wed, 21 Apr 2021 15:00:01 +0200
> Greg Kroah-Hartman <[email protected]> wrote:
>
> > This reverts commit 6f19893b644a9454d85e593b5e90914e7a72b7dd.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: David S. Miller <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > net/openvswitch/datapath.c | 4 ----
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> > index 9d6ef6cb9b26..99e63f4bbcaf 100644
> > --- a/net/openvswitch/datapath.c
> > +++ b/net/openvswitch/datapath.c
> > @@ -443,10 +443,6 @@ static int queue_userspace_packet(struct
> > datapath *dp, struct sk_buff *skb,
> > upcall = genlmsg_put(user_skb, 0, 0, &dp_packet_genl_family,
> > 0, upcall_info->cmd);
> > - if (!upcall) {
> > - err = -EINVAL;
> > - goto out;
> > - }
> > upcall->dp_ifindex = dp_ifindex;
> >
> > err = ovs_nla_put_key(key, key, OVS_PACKET_ATTR_KEY, false,
> > user_skb);
>
> This patch seems good to me, but given the situation I'd like another
> pair of eyes on it, at least.
The revert LGTM.
A few lines above:
len = upcall_msg_size(upcall_info, hlen - cutlen,
OVS_CB(skb)->acts_origlen);
user_skb = genlmsg_new(len, GFP_ATOMIC);
if (!user_skb) {
err = -ENOMEM;
goto out;
}
upcall_msg_size() calculates the expected size of the buffer,
including at the very least a nlmsg-aligned sizeof(struct ovs_header),
plus other constants and also potential (likely) variable lengths
based on the current flow context.
genlmsg_new() adds the (nlmsg-aligned) nlmsg header length to the
calculated length when allocating the buffer, and if the memory
allocation fails here then the error is already returned.
I don't then see a way for genlmsg_put() to fail per the hunk in the
commit here given that its buffer reservation is calculated based on:
nlh = nlmsg_put(skb, portid, seq, family->id, GENL_HDRLEN +
family->hdrsize, flags);
Where family->hdrsize would be sizeof(struct ovs_header) since
dp_packet_genl_family is the family passed into the genlmsg_put()
call:
static struct genl_family dp_packet_genl_family __ro_after_init = {
.hdrsize = sizeof(struct ovs_header),
Even if there were some allocation bug here to be fixed (due to
miscalculating the buffer size in the first place), I don't see how
the extra error path in the included patch could catch such an error.
The original patch doesn't seem necessarily problematic, but it
doesn't seem like it adds anything of value either (or at least,
nothing a comment couldn't clearly explain).
Cheers,
Joe
On 21. 04. 21, 17:59, David Sterba wrote:
> On Wed, Apr 21, 2021 at 02:59:41PM +0200, Greg Kroah-Hartman wrote:
>> This reverts commit 1bbb1c318cd8a3a39e8c3e2e83d5e90542d6c3e3.
>>
>> 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.
>
> I've reviewed the patch at the time and now again with fresh eyes, but
> it's IMO a valid fix that would have to be done the same way after
> revert.
ACK -- the same opinion here.
--
js
suse labs
On 21. 04. 21, 14:59, Greg Kroah-Hartman wrote:
> This reverts commit 6734330654dac550f12e932996b868c6d0dcb421.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: stable <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/tty/serial/mxs-auart.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> index f414d6acad69..edad6ebbdfd5 100644
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -1644,10 +1644,6 @@ static int mxs_auart_probe(struct platform_device *pdev)
>
> s->port.mapbase = r->start;
> s->port.membase = ioremap(r->start, resource_size(r));
> - if (!s->port.membase) {
> - ret = -ENOMEM;
> - goto out_disable_clks;
> - }
I don't think this needs to be reverted -- the original fix is correct.
> s->port.ops = &mxs_auart_ops;
> s->port.iotype = UPIO_MEM;
> s->port.fifosize = MXS_AUART_FIFO_SIZE;
>
--
js
suse labs
On Wed, Apr 21, 2021 at 02:59:21PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit ea094d53580f40c2124cef3d072b73b2425e7bfd.
>
> 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.
>
> Cc: Wenwen Wang <[email protected]>
> Cc: Bjorn Helgaas <[email protected]>
> Cc: Ingo Molnar <[email protected]>
> Cc: Thomas Gleixner <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
I would prefer that you not apply this revert.
Prior to ea094d53580f ("x86/PCI: Fix PCI IRQ routing table memory
leak"), we had essentially this:
pcibios_irq_init()
pirq_table = pcibios_get_irq_routing_table(); # kmallocs
if (pirq_table) {
if (io_apic_assign_pci_irqs)
pirq_table = NULL;
}
So if we called pcibios_get_irq_routing_table(), we kmalloced some
space and then (if io_apic_assign_pci_irqs) threw away the pointer,
which leaks the pointer as the commit log says.
After ea094d53580f, we have:
pcibios_irq_init()
rtable = NULL;
pirq_table = pcibios_get_irq_routing_table(); # kmallocs
rtable = pirq_table;
if (pirq_table) {
if (io_apic_assign_pci_irqs) {
kfree(rtable);
pirq_table = NULL;
}
}
which seems right to me.
Bjorn
> ---
> arch/x86/pci/irq.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
> index d3a73f9335e1..52e55108404e 100644
> --- a/arch/x86/pci/irq.c
> +++ b/arch/x86/pci/irq.c
> @@ -1119,8 +1119,6 @@ static const struct dmi_system_id pciirq_dmi_table[] __initconst = {
>
> void __init pcibios_irq_init(void)
> {
> - struct irq_routing_table *rtable = NULL;
> -
> DBG(KERN_DEBUG "PCI: IRQ init\n");
>
> if (raw_pci_ops == NULL)
> @@ -1131,10 +1129,8 @@ void __init pcibios_irq_init(void)
> pirq_table = pirq_find_routing_table();
>
> #ifdef CONFIG_PCI_BIOS
> - if (!pirq_table && (pci_probe & PCI_BIOS_IRQ_SCAN)) {
> + if (!pirq_table && (pci_probe & PCI_BIOS_IRQ_SCAN))
> pirq_table = pcibios_get_irq_routing_table();
> - rtable = pirq_table;
> - }
> #endif
> if (pirq_table) {
> pirq_peer_trick();
> @@ -1149,10 +1145,8 @@ void __init pcibios_irq_init(void)
> * If we're using the I/O APIC, avoid using the PCI IRQ
> * routing table
> */
> - if (io_apic_assign_pci_irqs) {
> - kfree(rtable);
> + if (io_apic_assign_pci_irqs)
> pirq_table = NULL;
> - }
> }
>
> x86_init.pci.fixup_irqs();
> --
> 2.31.1
>
On 21-04-21, 14:59, Greg Kroah-Hartman wrote:
> This reverts commit b5af36e3e5aa074605a4d90a89dd8f714b30909b.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Vaibhav Agarwal <[email protected]>
> Cc: Viresh Kumar <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/staging/greybus/audio_manager.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/staging/greybus/audio_manager.c b/drivers/staging/greybus/audio_manager.c
> index 9a3f7c034ab4..7c7ca671876d 100644
> --- a/drivers/staging/greybus/audio_manager.c
> +++ b/drivers/staging/greybus/audio_manager.c
> @@ -45,9 +45,6 @@ int gb_audio_manager_add(struct gb_audio_manager_module_descriptor *desc)
> int err;
>
> id = ida_simple_get(&module_id, 0, 0, GFP_KERNEL);
> - if (id < 0)
> - return id;
> -
> err = gb_audio_manager_module_create(&module, manager_kset,
> id, desc);
> if (err) {
FWIW, this patch was doing the right thing IMO. So we may not want to
revert it.
--
viresh
On 21. 04. 21, 14:59, Greg Kroah-Hartman wrote:
> This reverts commit c85be041065c0be8bc48eda4c45e0319caf1d0e5.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Richard Genoud <[email protected]>
> Cc: stable <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/tty/serial/atmel_serial.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> index a24e5c2b30bc..9786d8e5f04f 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -1256,10 +1256,6 @@ static int atmel_prepare_rx_dma(struct uart_port *port)
> sg_dma_len(&atmel_port->sg_rx)/2,
> DMA_DEV_TO_MEM,
> DMA_PREP_INTERRUPT);
> - if (!desc) {
> - dev_err(port->dev, "Preparing DMA cyclic failed\n");
> - goto chan_err;
> - }
I cannot find anything malicious in the original fix:
* port->dev is valid for dev_err
* dmaengine_prep_dma_cyclic returns NULL in case of error
* chan_err invokes atmel_release_rx_dma which undoes the previous
initialization code.
Hence a NACK from me for the revert.
> desc->callback = atmel_complete_rx_dma;
> desc->callback_param = port;
> atmel_port->desc_rx = desc;
>
--
js
suse labs
On 21. 04. 21, 14:59, Greg Kroah-Hartman wrote:
> This reverts commit 32f47179833b63de72427131169809065db6745e.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: stable <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/tty/serial/mvebu-uart.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c
> index e0c00a1b0763..51b0ecabf2ec 100644
> --- a/drivers/tty/serial/mvebu-uart.c
> +++ b/drivers/tty/serial/mvebu-uart.c
> @@ -818,9 +818,6 @@ static int mvebu_uart_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - if (!match)
> - return -ENODEV;
The original fix doesn't hurt, but is useless. ->probe is called when
of_match_device matched.
So the revert is OK.
> /* Assume that all UART ports have a DT alias or none has */
> id = of_alias_get_id(pdev->dev.of_node, "serial");
> if (!pdev->dev.of_node || id < 0)
>
--
js
suse labs
On 21. 04. 21, 15:00, Greg Kroah-Hartman wrote:
> This reverts commit 51f689cc11333944c7a457f25ec75fcb41e99410.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/tty/serial/max310x.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
> index 1b61d26bb7af..93f69b66b896 100644
> --- a/drivers/tty/serial/max310x.c
> +++ b/drivers/tty/serial/max310x.c
> @@ -1518,10 +1518,10 @@ static int __init max310x_uart_init(void)
> return ret;
>
> #ifdef CONFIG_SPI_MASTER
> - ret = spi_register_driver(&max310x_spi_driver);
> + spi_register_driver(&max310x_spi_driver);
> #endif
>
> - return ret;
> + return 0;
ACK, uart_unregister_driver() is missing in case of error at least.
> }
> module_init(max310x_uart_init);
>
>
--
js
suse labs
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.
Le 22/04/2021 à 07:18, Jiri Slaby a écrit :
> On 21. 04. 21, 14:59, Greg Kroah-Hartman wrote:
>> This reverts commit c85be041065c0be8bc48eda4c45e0319caf1d0e5.
>>
>> 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.
>>
>> Cc: Kangjie Lu <[email protected]>
>> Cc: Richard Genoud <[email protected]>
>> Cc: stable <[email protected]>
>> Cc: Greg Kroah-Hartman <[email protected]>
>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>> ---
>> drivers/tty/serial/atmel_serial.c | 4 ----
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
>> index a24e5c2b30bc..9786d8e5f04f 100644
>> --- a/drivers/tty/serial/atmel_serial.c
>> +++ b/drivers/tty/serial/atmel_serial.c
>> @@ -1256,10 +1256,6 @@ static int atmel_prepare_rx_dma(struct uart_port *port)
>> sg_dma_len(&atmel_port->sg_rx)/2,
>> DMA_DEV_TO_MEM,
>> DMA_PREP_INTERRUPT);
>> - if (!desc) {
>> - dev_err(port->dev, "Preparing DMA cyclic failed\n");
>> - goto chan_err;
>> - }
>
> I cannot find anything malicious in the original fix:
> * port->dev is valid for dev_err
> * dmaengine_prep_dma_cyclic returns NULL in case of error
> * chan_err invokes atmel_release_rx_dma which undoes the previous initialization code.
>
> Hence a NACK from me for the revert.
I agree with your NACK.
Back at the time (march 2019), I reviewed the changed and asked for a 2nd version and
I didn't found anything suspicious.
But the more eyes, the better.
cf http://lkml.iu.edu/hypermail/linux/kernel/1903.1/05858.html
>
>> desc->callback = atmel_complete_rx_dma;
>> desc->callback_param = port;
>> atmel_port->desc_rx = desc;
>>
>
>
Hi Laurent,
On Wed, Apr 21, 2021 at 11:22 PM Laurent Pinchart
<[email protected]> wrote:
> On Wed, Apr 21, 2021 at 08:58:22PM +0200, Geert Uytterhoeven wrote:
> > On Wed, Apr 21, 2021 at 3:06 PM Greg Kroah-Hartman wrote:
> > > This reverts commit d39083234c60519724c6ed59509a2129fd2aed41.
> > >
> > > 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.
> > >
> > > Cc: Kangjie Lu <[email protected]>
> > > Cc: Geert Uytterhoeven <[email protected]>
> > > Cc: Hans Verkuil <[email protected]>
> > > Cc: Mauro Carvalho Chehab <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >
> > Upon a second look, I still see nothing wrong with the original commit.
> > However, as I'm no v4l expert, I'd like to defer to the experts for final
> > judgement.
>
> It seems fine to me, but it also seems unneeded, as the V4L2 core clears
> the whole f->fmt union before calling this operation. The revert will
> this improve performance very slightly.
Hmm, that means very recent commit f12b81e47f48940a ("media: core
headers: fix kernel-doc warnings") is not fully correct, as it added
kerneldoc stating this is the responsibility of the driver:
+ * @reserved: drivers and applications must zero this array
Anyway, it doesn't look like this umn.edu patch introduced a bug.
> > > --- a/drivers/media/platform/rcar_drif.c
> > > +++ b/drivers/media/platform/rcar_drif.c
> > > @@ -915,7 +915,6 @@ static int rcar_drif_g_fmt_sdr_cap(struct file *file, void *priv,
> > > {
> > > struct rcar_drif_sdr *sdr = video_drvdata(file);
> > >
> > > - memset(f->fmt.sdr.reserved, 0, sizeof(f->fmt.sdr.reserved));
> > > f->fmt.sdr.pixelformat = sdr->fmt->pixelformat;
> > > f->fmt.sdr.buffersize = sdr->fmt->buffersize;
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 22/04/2021 08:57, Geert Uytterhoeven wrote:
> Hi Laurent,
>
> On Wed, Apr 21, 2021 at 11:22 PM Laurent Pinchart
> <[email protected]> wrote:
>> On Wed, Apr 21, 2021 at 08:58:22PM +0200, Geert Uytterhoeven wrote:
>>> On Wed, Apr 21, 2021 at 3:06 PM Greg Kroah-Hartman wrote:
>>>> This reverts commit d39083234c60519724c6ed59509a2129fd2aed41.
>>>>
>>>> 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.
>>>>
>>>> Cc: Kangjie Lu <[email protected]>
>>>> Cc: Geert Uytterhoeven <[email protected]>
>>>> Cc: Hans Verkuil <[email protected]>
>>>> Cc: Mauro Carvalho Chehab <[email protected]>
>>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>>
>>> Upon a second look, I still see nothing wrong with the original commit.
>>> However, as I'm no v4l expert, I'd like to defer to the experts for final
>>> judgement.
>>
>> It seems fine to me, but it also seems unneeded, as the V4L2 core clears
>> the whole f->fmt union before calling this operation. The revert will
>> this improve performance very slightly.
>
> Hmm, that means very recent commit f12b81e47f48940a ("media: core
> headers: fix kernel-doc warnings") is not fully correct, as it added
> kerneldoc stating this is the responsibility of the driver:
>
> + * @reserved: drivers and applications must zero this array
Actually, it is the V4L2 core used by the driver that zeroes this. So
drivers don't need to do this, it's done for them. It used to be the
responsibility of the driver itself, but this was all moved to the core
framework a long time ago since, duh!, drivers always forgot this :-)
>
> Anyway, it doesn't look like this umn.edu patch introduced a bug.
I haven't seen any bugs introduced by the media patches from umn.edu.
Regards,
Hans
>
>>>> --- a/drivers/media/platform/rcar_drif.c
>>>> +++ b/drivers/media/platform/rcar_drif.c
>>>> @@ -915,7 +915,6 @@ static int rcar_drif_g_fmt_sdr_cap(struct file *file, void *priv,
>>>> {
>>>> struct rcar_drif_sdr *sdr = video_drvdata(file);
>>>>
>>>> - memset(f->fmt.sdr.reserved, 0, sizeof(f->fmt.sdr.reserved));
>>>> f->fmt.sdr.pixelformat = sdr->fmt->pixelformat;
>>>> f->fmt.sdr.buffersize = sdr->fmt->buffersize;
>
> Gr{oetje,eeting}s,
>
> Geert
>
Hi Greg,
On Wed, Apr 21, 2021 at 02:58:34PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 7cc31613734c4870ae32f5265d576ef296621343.
I reviewed this fix again and it looks still valid and correct to me.
There is no need for a revert.
Thanks,
Joerg
Hi Greg,
I re-reviewed all the patches in this series where I was CCed.
These are all good and fix real bugs and should be re-reverted:
[PATCH 002/190] Revert "media: st-delta: Fix reference count leak in delta_run_work"
[PATCH 003/190] Revert "media: sti: Fix reference count leaks"
[PATCH 004/190] Revert "media: exynos4-is: Fix several reference count leaks due to pm_runtime_get_sync"
[PATCH 005/190] Revert "media: exynos4-is: Fix a reference count leak due to pm_runtime_get_sync"
[PATCH 006/190] Revert "media: exynos4-is: Fix a reference count leak"
[PATCH 008/190] Revert "media: stm32-dcmi: Fix a reference count leak"
[PATCH 009/190] Revert "media: s5p-mfc: Fix a reference count leak"
[PATCH 010/190] Revert "media: camss: Fix a reference count leak."
[PATCH 011/190] Revert "media: platform: fcp: Fix a reference count leak."
[PATCH 012/190] Revert "media: rockchip/rga: Fix a reference count leak."
[PATCH 013/190] Revert "media: rcar-vin: Fix a reference count leak."
[PATCH 014/190] Revert "media: rcar-vin: Fix a reference count leak."
[PATCH 052/190] Revert "media: media/saa7146: fix incorrect assertion in saa7146_buffer_finish"
[PATCH 056/190] Revert "media: davinci/vpfe_capture.c: Avoid BUG_ON for register failure"
[PATCH 057/190] Revert "media: saa7146: Avoid using BUG_ON as an assertion"
[PATCH 058/190] Revert "media: cx231xx: replace BUG_ON with recovery code"
[PATCH 102/190] Revert "media: video-mux: fix null pointer dereferences"
[PATCH 183/190] Revert "media: isif: fix a NULL pointer dereference bug"
This one can be dropped since it actually contains a bug, I'm fairly certain
that was unintentional:
[PATCH 007/190] Revert "media: ti-vpe: Fix a missing check and reference count leak"
I'll reply to that one separately.
This one can be dropped since it is not necessary:
[PATCH 073/190] Revert "media: rcar_drif: fix a memory disclosure"
The V4L2 core already zeroes this. Other drivers that use fmt.sdr also
memset this, but that should be dropped in those drivers as well. I'll
make a patch for that.
Regards,
Hans
On 21/04/2021 14:57, Greg Kroah-Hartman wrote:
> This reverts commit 57cc666d36adc7b45e37ba4cd7bc4e44ec4c43d7.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Hans Verkuil <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/media/platform/sti/delta/delta-v4l2.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/sti/delta/delta-v4l2.c b/drivers/media/platform/sti/delta/delta-v4l2.c
> index c691b3d81549..2503224eeee5 100644
> --- a/drivers/media/platform/sti/delta/delta-v4l2.c
> +++ b/drivers/media/platform/sti/delta/delta-v4l2.c
> @@ -954,10 +954,8 @@ static void delta_run_work(struct work_struct *work)
> /* enable the hardware */
> if (!dec->pm) {
> ret = delta_get_sync(ctx);
> - if (ret) {
> - delta_put_autosuspend(ctx);
> + if (ret)
> goto err;
> - }
> }
>
> /* decode this access unit */
>
On Wed, 21 Apr 2021 at 15:19, Laurent Pinchart
<[email protected]> wrote:
>
> Hi Greg,
>
> Thank you for the patch.
>
> On Wed, Apr 21, 2021 at 02:59:23PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 611025983b7976df0183390a63a2166411d177f1.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Laurent Pinchart <[email protected]>
> > Cc: Ulf Hansson <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> Acked-by: Laurent Pinchart <[email protected]>
>
> I don't spot an obvious issue with the original patch though.
>
> > ---
> > drivers/mmc/host/mmc_spi.c | 4 ----
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
> > index 02f4fd26e76a..cc40b050e302 100644
> > --- a/drivers/mmc/host/mmc_spi.c
> > +++ b/drivers/mmc/host/mmc_spi.c
> > @@ -800,10 +800,6 @@ mmc_spi_readblock(struct mmc_spi_host *host, struct spi_transfer *t,
> > }
> >
> > status = spi_sync_locked(spi, &host->m);
> > - if (status < 0) {
> > - dev_dbg(&spi->dev, "read error %d\n", status);
> > - return status;
> > - }
Returning here means we never give back the ownership of the buffer to
the CPU. Can that be considered as vulnerability?
If that is that a problem, I can point out that there is already one
more case in this file, where this pattern is repeated. See
mmc_spi_writeblock(). This code has been there since 2007.
> >
> > if (host->dma_dev) {
> > dma_sync_single_for_cpu(host->dma_dev,
>
> --
> Regards,
>
> Laurent Pinchart
Kind regards
Uffe
On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
> This reverts commit 7dae2aaaf432767ca7aa11fa84643a7c2600dbdd.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: Hans Verkuil <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/media/platform/ti-vpe/vpe.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c
> index 10251b787674..c7a0a7c19ca6 100644
> --- a/drivers/media/platform/ti-vpe/vpe.c
> +++ b/drivers/media/platform/ti-vpe/vpe.c
> @@ -2473,8 +2473,6 @@ static int vpe_runtime_get(struct platform_device *pdev)
>
> r = pm_runtime_get_sync(&pdev->dev);
> WARN_ON(r < 0);
> - if (r)
This should have been: if (r < 0)
I missed that as a reviewer, and I don't think it was intentional either
since I couldn't find any clear documentation in pm_runtime_get_sync()
that it can return 0 or 1 as success. After going through a few wrapper
functions you end up in rpm_resume() in drivers/base/power/runtime.c
which doesn't document the return code.
So keep this reverted and I'll make a new patch for this later.
I've CC-ed Rafael and Pavel: it would be really nice if someone can
document the return code from rpm_resume() in drivers/base/power/runtime.c.
I just discovered that it is documented in Documentation/power/runtime_pm.rst,
but if you just look at the code then you'll miss this.
Regards,
Hans
> - pm_runtime_put_noidle(&pdev->dev);
> return r < 0 ? r : 0;
> }
>
>
On Thu, Apr 22, 2021 at 09:52:28AM +0200, Joerg Roedel wrote:
> Hi Greg,
>
> On Wed, Apr 21, 2021 at 02:58:34PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 7cc31613734c4870ae32f5265d576ef296621343.
>
> I reviewed this fix again and it looks still valid and correct to me.
> There is no need for a revert.
Wonderful, thanks for the review, I appreciate it!
greg k-h
On Thu, Apr 22, 2021 at 10:02:32AM +0200, Hans Verkuil wrote:
> Hi Greg,
>
> I re-reviewed all the patches in this series where I was CCed.
>
> These are all good and fix real bugs and should be re-reverted:
>
> [PATCH 002/190] Revert "media: st-delta: Fix reference count leak in delta_run_work"
> [PATCH 003/190] Revert "media: sti: Fix reference count leaks"
> [PATCH 004/190] Revert "media: exynos4-is: Fix several reference count leaks due to pm_runtime_get_sync"
> [PATCH 005/190] Revert "media: exynos4-is: Fix a reference count leak due to pm_runtime_get_sync"
> [PATCH 006/190] Revert "media: exynos4-is: Fix a reference count leak"
> [PATCH 008/190] Revert "media: stm32-dcmi: Fix a reference count leak"
> [PATCH 009/190] Revert "media: s5p-mfc: Fix a reference count leak"
> [PATCH 010/190] Revert "media: camss: Fix a reference count leak."
> [PATCH 011/190] Revert "media: platform: fcp: Fix a reference count leak."
> [PATCH 012/190] Revert "media: rockchip/rga: Fix a reference count leak."
> [PATCH 013/190] Revert "media: rcar-vin: Fix a reference count leak."
> [PATCH 014/190] Revert "media: rcar-vin: Fix a reference count leak."
> [PATCH 052/190] Revert "media: media/saa7146: fix incorrect assertion in saa7146_buffer_finish"
> [PATCH 056/190] Revert "media: davinci/vpfe_capture.c: Avoid BUG_ON for register failure"
> [PATCH 057/190] Revert "media: saa7146: Avoid using BUG_ON as an assertion"
> [PATCH 058/190] Revert "media: cx231xx: replace BUG_ON with recovery code"
> [PATCH 102/190] Revert "media: video-mux: fix null pointer dereferences"
> [PATCH 183/190] Revert "media: isif: fix a NULL pointer dereference bug"
>
> This one can be dropped since it actually contains a bug, I'm fairly certain
> that was unintentional:
>
> [PATCH 007/190] Revert "media: ti-vpe: Fix a missing check and reference count leak"
>
> I'll reply to that one separately.
>
> This one can be dropped since it is not necessary:
>
> [PATCH 073/190] Revert "media: rcar_drif: fix a memory disclosure"
>
> The V4L2 core already zeroes this. Other drivers that use fmt.sdr also
> memset this, but that should be dropped in those drivers as well. I'll
> make a patch for that.
Wonderful, many thanks for doing this review, I'll be dropping these
from the series.
greg k-h
Hi Greg,
On 22/04/2021 10:13, Greg Kroah-Hartman wrote:
> On Thu, Apr 22, 2021 at 10:02:32AM +0200, Hans Verkuil wrote:
>> Hi Greg,
>>
>> I re-reviewed all the patches in this series where I was CCed.
>>
>> These are all good and fix real bugs and should be re-reverted:
>>
>> [PATCH 002/190] Revert "media: st-delta: Fix reference count leak in delta_run_work"
>> [PATCH 003/190] Revert "media: sti: Fix reference count leaks"
>> [PATCH 004/190] Revert "media: exynos4-is: Fix several reference count leaks due to pm_runtime_get_sync"
>> [PATCH 005/190] Revert "media: exynos4-is: Fix a reference count leak due to pm_runtime_get_sync"
>> [PATCH 006/190] Revert "media: exynos4-is: Fix a reference count leak"
>> [PATCH 008/190] Revert "media: stm32-dcmi: Fix a reference count leak"
>> [PATCH 009/190] Revert "media: s5p-mfc: Fix a reference count leak"
>> [PATCH 010/190] Revert "media: camss: Fix a reference count leak."
>> [PATCH 011/190] Revert "media: platform: fcp: Fix a reference count leak."
>> [PATCH 012/190] Revert "media: rockchip/rga: Fix a reference count leak."
>> [PATCH 013/190] Revert "media: rcar-vin: Fix a reference count leak."
>> [PATCH 014/190] Revert "media: rcar-vin: Fix a reference count leak."
>> [PATCH 052/190] Revert "media: media/saa7146: fix incorrect assertion in saa7146_buffer_finish"
>> [PATCH 056/190] Revert "media: davinci/vpfe_capture.c: Avoid BUG_ON for register failure"
>> [PATCH 057/190] Revert "media: saa7146: Avoid using BUG_ON as an assertion"
>> [PATCH 058/190] Revert "media: cx231xx: replace BUG_ON with recovery code"
>> [PATCH 102/190] Revert "media: video-mux: fix null pointer dereferences"
>> [PATCH 183/190] Revert "media: isif: fix a NULL pointer dereference bug"
>>
Just to clarify and avoid ambiguities:
>> This one can be dropped since it actually contains a bug, I'm fairly certain
with 'This can be dropped' I meant: this can remain reverted.
>> that was unintentional:
>>
>> [PATCH 007/190] Revert "media: ti-vpe: Fix a missing check and reference count leak"
>>
>> I'll reply to that one separately.
>>
>> This one can be dropped since it is not necessary:
Ditto.
You probably understood what I meant, but I realized it was not very clear.
Regards,
Hans
>>
>> [PATCH 073/190] Revert "media: rcar_drif: fix a memory disclosure"
>>
>> The V4L2 core already zeroes this. Other drivers that use fmt.sdr also
>> memset this, but that should be dropped in those drivers as well. I'll
>> make a patch for that.
>
> Wonderful, many thanks for doing this review, I'll be dropping these
> from the series.
>
> greg k-h
>
On Wed, 21 Apr 2021 14:59:28 +0200
Greg Kroah-Hartman <[email protected]> wrote:
> This reverts commit 536cc27deade8f1ec3c1beefa60d5fbe0f6fcb28.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Jonathan Cameron <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Hi Greg,
Checked this one. As far as I can tell it was a valid cleanup of
error handling. Far from critical though and unlikely to be seen in practice.
So either leave it in place, or we can bring it back later. I don't mind
which.
> ---
> drivers/iio/magnetometer/hmc5843_i2c.c | 7 +------
> drivers/iio/magnetometer/hmc5843_spi.c | 7 +------
> 2 files changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/iio/magnetometer/hmc5843_i2c.c b/drivers/iio/magnetometer/hmc5843_i2c.c
> index 67fe657fdb3e..9a4491233d08 100644
> --- a/drivers/iio/magnetometer/hmc5843_i2c.c
> +++ b/drivers/iio/magnetometer/hmc5843_i2c.c
> @@ -55,13 +55,8 @@ static const struct regmap_config hmc5843_i2c_regmap_config = {
> static int hmc5843_i2c_probe(struct i2c_client *cli,
> const struct i2c_device_id *id)
> {
> - struct regmap *regmap = devm_regmap_init_i2c(cli,
> - &hmc5843_i2c_regmap_config);
> - if (IS_ERR(regmap))
> - return PTR_ERR(regmap);
> -
> return hmc5843_common_probe(&cli->dev,
> - regmap,
> + devm_regmap_init_i2c(cli, &hmc5843_i2c_regmap_config),
> id->driver_data, id->name);
> }
>
> diff --git a/drivers/iio/magnetometer/hmc5843_spi.c b/drivers/iio/magnetometer/hmc5843_spi.c
> index d827554c346e..58bdbc7257ec 100644
> --- a/drivers/iio/magnetometer/hmc5843_spi.c
> +++ b/drivers/iio/magnetometer/hmc5843_spi.c
> @@ -55,7 +55,6 @@ static const struct regmap_config hmc5843_spi_regmap_config = {
> static int hmc5843_spi_probe(struct spi_device *spi)
> {
> int ret;
> - struct regmap *regmap;
> const struct spi_device_id *id = spi_get_device_id(spi);
>
> spi->mode = SPI_MODE_3;
> @@ -65,12 +64,8 @@ static int hmc5843_spi_probe(struct spi_device *spi)
> if (ret)
> return ret;
>
> - regmap = devm_regmap_init_spi(spi, &hmc5843_spi_regmap_config);
> - if (IS_ERR(regmap))
> - return PTR_ERR(regmap);
> -
> return hmc5843_common_probe(&spi->dev,
> - regmap,
> + devm_regmap_init_spi(spi, &hmc5843_spi_regmap_config),
> id->driver_data, id->name);
> }
>
On Wed, 21 Apr 2021 15:00:39 +0200
Greg Kroah-Hartman <[email protected]> wrote:
> This reverts commit ae0b3773721f08526c850e2d8dec85bdb870cd12.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Jonathan Cameron <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Checked. Original fix was correct. As with others I don't mind how we handle
this. Can either drop the revert, or bring it back later.
Thanks,
Jonathan
> ---
> drivers/iio/frequency/ad9523.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/iio/frequency/ad9523.c b/drivers/iio/frequency/ad9523.c
> index bdb0bc3b12dd..91eb47e27db0 100644
> --- a/drivers/iio/frequency/ad9523.c
> +++ b/drivers/iio/frequency/ad9523.c
> @@ -944,14 +944,11 @@ static int ad9523_setup(struct iio_dev *indio_dev)
> }
> }
>
> - for_each_clear_bit(i, &active_mask, AD9523_NUM_CHAN) {
> - ret = ad9523_write(indio_dev,
> + for_each_clear_bit(i, &active_mask, AD9523_NUM_CHAN)
> + ad9523_write(indio_dev,
> AD9523_CHANNEL_CLOCK_DIST(i),
> AD9523_CLK_DIST_DRIVER_MODE(TRISTATE) |
> AD9523_CLK_DIST_PWR_DOWN_EN);
> - if (ret < 0)
> - return ret;
> - }
>
> ret = ad9523_write(indio_dev, AD9523_POWER_DOWN_CTRL, 0);
> if (ret < 0)
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
--
http://www.livejournal.com/~pavelmachek
On Wed 2021-04-21 14:58:50, Greg Kroah-Hartman wrote:
> This reverts commit 67e2d2eb542338145a2e0b2336c1cdabd2424fd3.
>
> 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).
This patch is correct AFAICT.
Pavel
> index f105746063ed..f89dcf9b6217 100644
> --- a/fs/ocfs2/dlm/dlmmaster.c
> +++ b/fs/ocfs2/dlm/dlmmaster.c
> @@ -2554,6 +2554,8 @@ static int dlm_migrate_lockres(struct dlm_ctxt *dlm,
> if (!dlm_grab(dlm))
> return -EINVAL;
>
> + BUG_ON(target == O2NM_MAX_NODES);
> +
> name = res->lockname.name;
> namelen = res->lockname.len;
>
--
http://www.livejournal.com/~pavelmachek
Em Thu, 22 Apr 2021 09:29:36 +0200
Hans Verkuil <[email protected]> escreveu:
> On 22/04/2021 08:57, Geert Uytterhoeven wrote:
> > Hi Laurent,
> >
> > On Wed, Apr 21, 2021 at 11:22 PM Laurent Pinchart
> > <[email protected]> wrote:
> >> On Wed, Apr 21, 2021 at 08:58:22PM +0200, Geert Uytterhoeven wrote:
> >>> On Wed, Apr 21, 2021 at 3:06 PM Greg Kroah-Hartman wrote:
> >>>> This reverts commit d39083234c60519724c6ed59509a2129fd2aed41.
> >>>>
> >>>> 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.
> >>>>
> >>>> Cc: Kangjie Lu <[email protected]>
> >>>> Cc: Geert Uytterhoeven <[email protected]>
> >>>> Cc: Hans Verkuil <[email protected]>
> >>>> Cc: Mauro Carvalho Chehab <[email protected]>
> >>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >>>
> >>> Upon a second look, I still see nothing wrong with the original commit.
> >>> However, as I'm no v4l expert, I'd like to defer to the experts for final
> >>> judgement.
> >>
> >> It seems fine to me, but it also seems unneeded, as the V4L2 core clears
> >> the whole f->fmt union before calling this operation. The revert will
> >> this improve performance very slightly.
> >
> > Hmm, that means very recent commit f12b81e47f48940a ("media: core
> > headers: fix kernel-doc warnings") is not fully correct, as it added
> > kerneldoc stating this is the responsibility of the driver:
> >
> > + * @reserved: drivers and applications must zero this array
>
> Actually, it is the V4L2 core used by the driver that zeroes this. So
> drivers don't need to do this, it's done for them. It used to be the
> responsibility of the driver itself, but this was all moved to the core
> framework a long time ago since, duh!, drivers always forgot this :-)
>
> >
> > Anyway, it doesn't look like this umn.edu patch introduced a bug.
>
> I haven't seen any bugs introduced by the media patches from umn.edu.
Hi Greg,
I also double-checked all media revert patches from:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git umn.edu-reverts
currently on this patch:
6f4747a872ad Revert "ethtool: fix a potential missing-check bug"
That's a summary of what I found:
All of those should be dropped from your tree:
84fdb5856edd Revert "media: si2165: fix a missing check of return value"
867043f2206e Revert "media: video-mux: fix null pointer dereferences"
78ae4b621297 Revert "media: cx231xx: replace BUG_ON with recovery code"
5be328a55817 Revert "media: saa7146: Avoid using BUG_ON as an assertion"
81ce83158d22 Revert "media: davinci/vpfe_capture.c: Avoid BUG_ON for register failure"
3319b39504b8 Revert "media: media/saa7146: fix incorrect assertion in saa7146_buffer_finish"
b393f7cb29a2 Revert "media: rcar-vin: Fix a reference count leak."
197bc5d03682 Revert "media: rcar-vin: Fix a reference count leak."
2fd9cf68bbb6 Revert "media: rockchip/rga: Fix a reference count leak."
d1e4614eca24 Revert "media: platform: fcp: Fix a reference count leak."
416e8a6ae07f Revert "media: camss: Fix a reference count leak."
06b793ae497b Revert "media: s5p-mfc: Fix a reference count leak"
8f9fc14a7cc9 Revert "media: stm32-dcmi: Fix a reference count leak"
556e1f86ba24 Revert "media: ti-vpe: Fix a missing check and reference count leak"
5f5b1722ad0d Revert "media: exynos4-is: Fix a reference count leak"
f4c758c6c1cb Revert "media: exynos4-is: Fix a reference count leak due to pm_runtime_get_sync"
beb717878c73 Revert "media: exynos4-is: Fix several reference count leaks due to pm_runtime_get_sync
7066ec748bfd Revert "media: sti: Fix reference count leaks"
cdd117093b19 Revert "media: st-delta: Fix reference count leak in delta_run_work"
As, after my re-check, they all seem to be addressing real issues. So,
NACK on those.
This patch (073/190):
899ab4671bc0 Revert "media: rcar_drif: fix a memory disclosure"
While it doesn't hurt, it is useless, as the media core already
prevents memory disclosure. So, it should be reverted.
So, for patch 073/190:
Reviewed-by: Mauro Carvalho Chehab <[email protected]>
Thanks,
Mauro
Dear All,
> From: Mauro Carvalho Chehab <[email protected]>
> Sent: 22 April 2021 10:04
> Subject: Re: [PATCH 073/190] Revert "media: rcar_drif: fix a memory
> disclosure"
>
> Em Thu, 22 Apr 2021 09:29:36 +0200
> Hans Verkuil <[email protected]> escreveu:
>
> > On 22/04/2021 08:57, Geert Uytterhoeven wrote:
> > > Hi Laurent,
> > >
> > > On Wed, Apr 21, 2021 at 11:22 PM Laurent Pinchart
> > > <[email protected]> wrote:
> > >> On Wed, Apr 21, 2021 at 08:58:22PM +0200, Geert Uytterhoeven wrote:
> > >>> On Wed, Apr 21, 2021 at 3:06 PM Greg Kroah-Hartman wrote:
> > >>>> This reverts commit d39083234c60519724c6ed59509a2129fd2aed41.
> > >>>>
> > >>>> 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.
> > >>>>
> > >>>> Cc: Kangjie Lu <[email protected]>
> > >>>> Cc: Geert Uytterhoeven <[email protected]>
> > >>>> Cc: Hans Verkuil <[email protected]>
> > >>>> Cc: Mauro Carvalho Chehab <[email protected]>
> > >>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > >>>
> > >>> Upon a second look, I still see nothing wrong with the original
> commit.
> > >>> However, as I'm no v4l expert, I'd like to defer to the experts for
> final
> > >>> judgement.
> > >>
> > >> It seems fine to me, but it also seems unneeded, as the V4L2 core
> clears
> > >> the whole f->fmt union before calling this operation. The revert will
> > >> this improve performance very slightly.
> > >
> > > Hmm, that means very recent commit f12b81e47f48940a ("media: core
> > > headers: fix kernel-doc warnings") is not fully correct, as it added
> > > kerneldoc stating this is the responsibility of the driver:
> > >
> > > + * @reserved: drivers and applications must zero this array
> >
> > Actually, it is the V4L2 core used by the driver that zeroes this. So
> > drivers don't need to do this, it's done for them. It used to be the
> > responsibility of the driver itself, but this was all moved to the core
> > framework a long time ago since, duh!, drivers always forgot this :-)
> >
> > >
> > > Anyway, it doesn't look like this umn.edu patch introduced a bug.
> >
> > I haven't seen any bugs introduced by the media patches from umn.edu.
>
> Hi Greg,
>
> I also double-checked all media revert patches from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> umn.edu-reverts
>
> currently on this patch:
> 6f4747a872ad Revert "ethtool: fix a potential missing-check bug"
>
> That's a summary of what I found:
>
> All of those should be dropped from your tree:
>
> 84fdb5856edd Revert "media: si2165: fix a missing check of
> return value"
> 867043f2206e Revert "media: video-mux: fix null pointer
> dereferences"
> 78ae4b621297 Revert "media: cx231xx: replace BUG_ON with
> recovery code"
> 5be328a55817 Revert "media: saa7146: Avoid using BUG_ON as an
> assertion"
> 81ce83158d22 Revert "media: davinci/vpfe_capture.c: Avoid
> BUG_ON for register failure"
> 3319b39504b8 Revert "media: media/saa7146: fix incorrect
> assertion in saa7146_buffer_finish"
> b393f7cb29a2 Revert "media: rcar-vin: Fix a reference count
> leak."
> 197bc5d03682 Revert "media: rcar-vin: Fix a reference count
> leak."
> 2fd9cf68bbb6 Revert "media: rockchip/rga: Fix a reference count
> leak."
> d1e4614eca24 Revert "media: platform: fcp: Fix a reference
> count leak."
> 416e8a6ae07f Revert "media: camss: Fix a reference count leak."
> 06b793ae497b Revert "media: s5p-mfc: Fix a reference count
> leak"
> 8f9fc14a7cc9 Revert "media: stm32-dcmi: Fix a reference count
> leak"
> 556e1f86ba24 Revert "media: ti-vpe: Fix a missing check and
> reference count leak"
> 5f5b1722ad0d Revert "media: exynos4-is: Fix a reference count
> leak"
> f4c758c6c1cb Revert "media: exynos4-is: Fix a reference count
> leak due to pm_runtime_get_sync"
> beb717878c73 Revert "media: exynos4-is: Fix several reference
> count leaks due to pm_runtime_get_sync
> 7066ec748bfd Revert "media: sti: Fix reference count leaks"
> cdd117093b19 Revert "media: st-delta: Fix reference count leak
> in delta_run_work"
>
> As, after my re-check, they all seem to be addressing real issues. So,
> NACK on those.
>
> This patch (073/190):
>
> 899ab4671bc0 Revert "media: rcar_drif: fix a memory disclosure"
>
> While it doesn't hurt, it is useless, as the media core already
> prevents memory disclosure. So, it should be reverted.
>
> So, for patch 073/190:
>
> Reviewed-by: Mauro Carvalho Chehab <[email protected]>
I agree, this patch should be reverted.
Reviewed-by: Fabrizio Castro <[email protected]>
>
> Thanks,
> Mauro
On Thu, Apr 22, 2021 at 11:03:36AM +0200, Mauro Carvalho Chehab wrote:
> Em Thu, 22 Apr 2021 09:29:36 +0200
> Hans Verkuil <[email protected]> escreveu:
>
> > On 22/04/2021 08:57, Geert Uytterhoeven wrote:
> > > Hi Laurent,
> > >
> > > On Wed, Apr 21, 2021 at 11:22 PM Laurent Pinchart
> > > <[email protected]> wrote:
> > >> On Wed, Apr 21, 2021 at 08:58:22PM +0200, Geert Uytterhoeven wrote:
> > >>> On Wed, Apr 21, 2021 at 3:06 PM Greg Kroah-Hartman wrote:
> > >>>> This reverts commit d39083234c60519724c6ed59509a2129fd2aed41.
> > >>>>
> > >>>> 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.
> > >>>>
> > >>>> Cc: Kangjie Lu <[email protected]>
> > >>>> Cc: Geert Uytterhoeven <[email protected]>
> > >>>> Cc: Hans Verkuil <[email protected]>
> > >>>> Cc: Mauro Carvalho Chehab <[email protected]>
> > >>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > >>>
> > >>> Upon a second look, I still see nothing wrong with the original commit.
> > >>> However, as I'm no v4l expert, I'd like to defer to the experts for final
> > >>> judgement.
> > >>
> > >> It seems fine to me, but it also seems unneeded, as the V4L2 core clears
> > >> the whole f->fmt union before calling this operation. The revert will
> > >> this improve performance very slightly.
> > >
> > > Hmm, that means very recent commit f12b81e47f48940a ("media: core
> > > headers: fix kernel-doc warnings") is not fully correct, as it added
> > > kerneldoc stating this is the responsibility of the driver:
> > >
> > > + * @reserved: drivers and applications must zero this array
> >
> > Actually, it is the V4L2 core used by the driver that zeroes this. So
> > drivers don't need to do this, it's done for them. It used to be the
> > responsibility of the driver itself, but this was all moved to the core
> > framework a long time ago since, duh!, drivers always forgot this :-)
> >
> > >
> > > Anyway, it doesn't look like this umn.edu patch introduced a bug.
> >
> > I haven't seen any bugs introduced by the media patches from umn.edu.
>
> Hi Greg,
>
> I also double-checked all media revert patches from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git umn.edu-reverts
>
> currently on this patch:
> 6f4747a872ad Revert "ethtool: fix a potential missing-check bug"
>
> That's a summary of what I found:
>
> All of those should be dropped from your tree:
>
> 84fdb5856edd Revert "media: si2165: fix a missing check of return value"
> 867043f2206e Revert "media: video-mux: fix null pointer dereferences"
> 78ae4b621297 Revert "media: cx231xx: replace BUG_ON with recovery code"
> 5be328a55817 Revert "media: saa7146: Avoid using BUG_ON as an assertion"
> 81ce83158d22 Revert "media: davinci/vpfe_capture.c: Avoid BUG_ON for register failure"
> 3319b39504b8 Revert "media: media/saa7146: fix incorrect assertion in saa7146_buffer_finish"
> b393f7cb29a2 Revert "media: rcar-vin: Fix a reference count leak."
> 197bc5d03682 Revert "media: rcar-vin: Fix a reference count leak."
> 2fd9cf68bbb6 Revert "media: rockchip/rga: Fix a reference count leak."
> d1e4614eca24 Revert "media: platform: fcp: Fix a reference count leak."
> 416e8a6ae07f Revert "media: camss: Fix a reference count leak."
> 06b793ae497b Revert "media: s5p-mfc: Fix a reference count leak"
> 8f9fc14a7cc9 Revert "media: stm32-dcmi: Fix a reference count leak"
> 556e1f86ba24 Revert "media: ti-vpe: Fix a missing check and reference count leak"
> 5f5b1722ad0d Revert "media: exynos4-is: Fix a reference count leak"
> f4c758c6c1cb Revert "media: exynos4-is: Fix a reference count leak due to pm_runtime_get_sync"
> beb717878c73 Revert "media: exynos4-is: Fix several reference count leaks due to pm_runtime_get_sync
> 7066ec748bfd Revert "media: sti: Fix reference count leaks"
> cdd117093b19 Revert "media: st-delta: Fix reference count leak in delta_run_work"
>
> As, after my re-check, they all seem to be addressing real issues. So,
> NACK on those.
>
> This patch (073/190):
>
> 899ab4671bc0 Revert "media: rcar_drif: fix a memory disclosure"
>
> While it doesn't hurt, it is useless, as the media core already
> prevents memory disclosure. So, it should be reverted.
>
> So, for patch 073/190:
>
> Reviewed-by: Mauro Carvalho Chehab <[email protected]>
Wonderful, thank you so much for doing this review and letting me know.
I'll drop the ones you mention here.
greg k-h
On Wed, Apr 21, 2021 at 02:59:24PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 507b820009a457afa78202da337bcb56791fbb12.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: commit log and code update]
Hi Greg,
first off, thank you for doing this.
This Cc should be fixed up if we go ahead with the revert (I can
take the revert via the PCI tree and fix it up myself).
I totally understand your concern (and the nuisance it is causing), the
commit we are reverting looked and looks legit - just let me know
how it is best to handle this please.
Thanks,
Lorenzo
> Cc: Lorenzo Pieralisi <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/pci/endpoint/functions/pci-epf-test.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> index c0ac4e9cbe72..39dd394284a5 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -915,11 +915,6 @@ static int __init pci_epf_test_init(void)
>
> kpcitest_workqueue = alloc_workqueue("kpcitest",
> WQ_MEM_RECLAIM | WQ_HIGHPRI, 0);
> - if (!kpcitest_workqueue) {
> - pr_err("Failed to allocate the kpcitest work queue\n");
> - return -ENOMEM;
> - }
> -
> ret = pci_epf_register_driver(&test_driver);
> if (ret) {
> pr_err("Failed to register pci epf test driver --> %d\n", ret);
> --
> 2.31.1
>
On Thu, Apr 22, 2021 at 10:31:11AM +0100, Lorenzo Pieralisi wrote:
> On Wed, Apr 21, 2021 at 02:59:24PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 507b820009a457afa78202da337bcb56791fbb12.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: commit log and code update]
>
> Hi Greg,
>
> first off, thank you for doing this.
>
> This Cc should be fixed up if we go ahead with the revert (I can
> take the revert via the PCI tree and fix it up myself).
>
> I totally understand your concern (and the nuisance it is causing), the
> commit we are reverting looked and looks legit - just let me know
> how it is best to handle this please.
I'll fix up all improper Cc: lines, that was my dumb script trying to
catch who was on the reverted patch, when I apply these.
I can take this through my tree, but as you said, if the original commit
here really is fine, that's great, I'll drop this.
Thanks for the review!
greg k-h
On Wed, Apr 21, 2021 at 02:59:36PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 699ca30162686bf305cdf94861be02eb0cf9bda2.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Lorenzo Pieralisi <[email protected]>
> Cc: Steven Price <[email protected]>
> Cc: Mukesh Ojha <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/pci/controller/pcie-xilinx.c | 12 ++----------
> 1 file changed, 2 insertions(+), 10 deletions(-)
Hi Greg,
For this revert - the commit we are reverting looked and looks OK
to me even though honestly I'd revert it just on principle given
the nuisance it is causing.
Actually, we have code in -next that is removing the reverted content
anyway (but not because it is bogus, code in -next is a nice clean-up
for all PCI drivers from Marc):
https://git.kernel.org/lpieralisi/pci/c/161260e7f7bc
Again, happy to go ahead with the revert and rework the queued code
on top of it, just let me know please.
Thanks,
Lorenzo
> diff --git a/drivers/pci/controller/pcie-xilinx.c b/drivers/pci/controller/pcie-xilinx.c
> index fa5baeb82653..942c25bf7980 100644
> --- a/drivers/pci/controller/pcie-xilinx.c
> +++ b/drivers/pci/controller/pcie-xilinx.c
> @@ -326,19 +326,14 @@ static const struct irq_domain_ops msi_domain_ops = {
> * xilinx_pcie_enable_msi - Enable MSI support
> * @port: PCIe port information
> */
> -static int xilinx_pcie_enable_msi(struct xilinx_pcie_port *port)
> +static void xilinx_pcie_enable_msi(struct xilinx_pcie_port *port)
> {
> phys_addr_t msg_addr;
>
> port->msi_pages = __get_free_pages(GFP_KERNEL, 0);
> - if (!port->msi_pages)
> - return -ENOMEM;
> -
> msg_addr = virt_to_phys((void *)port->msi_pages);
> pcie_write(port, 0x0, XILINX_PCIE_REG_MSIBASE1);
> pcie_write(port, msg_addr, XILINX_PCIE_REG_MSIBASE2);
> -
> - return 0;
> }
>
> /* INTx Functions */
> @@ -493,7 +488,6 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)
> struct device *dev = port->dev;
> struct device_node *node = dev->of_node;
> struct device_node *pcie_intc_node;
> - int ret;
>
> /* Setup INTx */
> pcie_intc_node = of_get_next_child(node, NULL);
> @@ -522,9 +516,7 @@ static int xilinx_pcie_init_irq_domain(struct xilinx_pcie_port *port)
> return -ENODEV;
> }
>
> - ret = xilinx_pcie_enable_msi(port);
> - if (ret)
> - return ret;
> + xilinx_pcie_enable_msi(port);
> }
>
> return 0;
> --
> 2.31.1
>
On Wed, Apr 21, 2021 at 02:59:50PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit e4dfdd5804cce1255f99c5dd033526a18135a616.
>
> 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 one too is valid.
> Cc: Kangjie Lu <[email protected]>
> Cc: Mika Westerberg <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/thunderbolt/property.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/thunderbolt/property.c b/drivers/thunderbolt/property.c
> index 841314deb446..ee76449524a3 100644
> --- a/drivers/thunderbolt/property.c
> +++ b/drivers/thunderbolt/property.c
> @@ -176,10 +176,6 @@ static struct tb_property_dir *__tb_property_parse_dir(const u32 *block,
> } else {
> dir->uuid = kmemdup(&block[dir_offset], sizeof(*dir->uuid),
> GFP_KERNEL);
> - if (!dir->uuid) {
> - tb_property_free_dir(dir);
> - return NULL;
> - }
> content_offset = dir_offset + 4;
> content_len = dir_len - 4; /* Length includes UUID */
> }
> --
> 2.31.1
Hi,
Greg Kroah-Hartman <[email protected]> writes:
> This reverts commit 2655971ad4b34e97dd921df16bb0b08db9449df7.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Felipe Balbi <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/usb/dwc3/dwc3-pci.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
> index 4c5c6972124a..0c0619f7b1a7 100644
> --- a/drivers/usb/dwc3/dwc3-pci.c
> +++ b/drivers/usb/dwc3/dwc3-pci.c
> @@ -226,10 +226,8 @@ static void dwc3_pci_resume_work(struct work_struct *work)
> int ret;
>
> ret = pm_runtime_get_sync(&dwc3->dev);
> - if (ret) {
> - pm_runtime_put_sync_autosuspend(&dwc3->dev);
> + if (ret)
> return;
> - }
this was a valid fix. pm_runtime_get_sync() leaves an unbalanced get on
the runtime usage counter.
It's okay if you prefer to revert it and have a new review cycle for
this, though.
--
balbi
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.
--
Doug Ledford <[email protected]>
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
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.
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
Hi Greg,
On Wed, Apr 21, 2021 at 02:59:58PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 6d65561f3d5ec933151939c543d006b79044e7a6.
>
> 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 patch looks correct, no need to revert.
If you still prefer to revert it, no problem, I'll recover this fix
via the netfilter tree later on.
Thanks.
> This reverts commit 093c48213ee37c3c3ff1cf5ac1aa2a9d8bc66017.
The reverted patch looks fishy.
gc.cd_info is kzalloc:ed on probe. In case probe fails after this allocation, the
memory is kfree:d but the variable is NOT zeroed out.
AFAICT, the above leads to a double-free on exit by the added line.
I believe gd.cd_info should be kfree:d on remove instead.
However, might not gc.toc also be kfree:d twice for similar reasons?
I could easily be mistaken.
Cheers,
Peter
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/
--
Kees Cook
On Wed, Apr 21 2021 at 12:49, Kees Cook wrote:
> On Wed, Apr 21, 2021 at 02:59:48PM +0200, Greg Kroah-Hartman wrote:
>> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
>> index 08651a4e6aa0..0515a97bf6f5 100644
>> --- a/arch/x86/kernel/hpet.c
>> +++ b/arch/x86/kernel/hpet.c
>> @@ -930,8 +930,6 @@ int __init hpet_enable(void)
>> return 0;
>>
>> hpet_set_mapping();
>> - if (!hpet_virt_address)
>> - return 0;
>>
>> /* Validate that the config register is working */
>> if (!hpet_cfg_working())
>
> FWIW, this patch looks harmless. It is checking for a failure in
> hpet_set_mapping(), and avoids the following code from performing
> 0-offset reads. hpet_set_mapping() is likely to never fail in real-world
> situations. *shrug*
'likely never to fail' is clearly a receipe for disaster and you should
know that.
> I think it would make more sense for the check to live in
> hpet_cfg_working(), though.
No. That does not make any sense at all.
The proper change would have been to make hpet_set_mapping() return
an error/success code and act on that.
But that does _NOT_ make the patch invalid.
I'm pretty sure that I looked at it and thought about the proper
solution (see above) and then shrugged it off because of overload...
Thanks,
tglx
On Thu, Apr 22, 2021 at 11:26:15PM +0200, Pablo Neira Ayuso wrote:
> Hi Greg,
>
> On Wed, Apr 21, 2021 at 02:59:58PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 6d65561f3d5ec933151939c543d006b79044e7a6.
> >
> > 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 patch looks correct, no need to revert.
Wonderful, thanks for the review.
> If you still prefer to revert it, no problem, I'll recover this fix
> via the netfilter tree later on.
Nah, I'm dropping anything that reviewers point out is "ok" from this
patch series.
thanks again,
greg k-h
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
On 21/04/2021 14:57, Greg Kroah-Hartman wrote:
> This reverts commit 7ef64ceea0008c17e94a8a2c60c5d6d46f481996.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: Hans Verkuil <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/media/platform/exynos4-is/fimc-isp.c | 4 +---
> drivers/media/platform/exynos4-is/fimc-lite.c | 2 +-
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
This looks like a good commit but should be done now in a different way
- using pm_runtime_resume_and_get(). Therefore I am fine with revert
and I can submit later better fix.
Best regards,
Krzysztof
On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
> This reverts commit 64157b2cb1940449e7df2670e85781c690266588.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: Hans Verkuil <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/media/platform/exynos4-is/mipi-csis.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
This looks like a good commit but should be done now in a different way
- using pm_runtime_resume_and_get(). Therefore I am fine with revert
and I can submit later better fix.
Best regards,
Krzysztof
Best regards,
Krzysztof
On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
> This reverts commit 78741ce98c2e36188e2343434406b0e0bc50b0e7.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: Hans Verkuil <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
This looks like a good commit but should be done now in a different way
- using pm_runtime_resume_and_get(). Therefore I am fine with revert
and I can submit later better fix.
Best regards,
Krzysztof
Best regards,
Krzysztof
On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
> This reverts commit 8d7a577d04e8ce24b1b81ee44ec8cd1dda2a9cd9.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: https
> Cc: Chanwoo Choi <[email protected]>
> Cc: Stephen Boyd <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/clk/samsung/clk.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
> index 1949ae7851b2..dad31308c071 100644
> --- a/drivers/clk/samsung/clk.c
> +++ b/drivers/clk/samsung/clk.c
> @@ -356,6 +356,10 @@ struct samsung_clk_provider * __init samsung_cmu_register_one(
> }
>
> ctx = samsung_clk_init(np, reg_base, cmu->nr_clk_ids);
> + if (!ctx) {
> + panic("%s: unable to allocate ctx\n", __func__);
> + return ctx;
> + }
Hi Greg,
The commit was fine here, so please keep it. NAK for the revert.
Best regards,
Krzysztof
On Fri, Apr 23, 2021 at 09:04:27AM +0200, Krzysztof Kozlowski wrote:
> On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
> > This reverts commit 78741ce98c2e36188e2343434406b0e0bc50b0e7.
> >
> > 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.
> >
> > Cc: Qiushi Wu <[email protected]>
> > Cc: Hans Verkuil <[email protected]>
> > Cc: Mauro Carvalho Chehab <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
>
> This looks like a good commit but should be done now in a different way
> - using pm_runtime_resume_and_get(). Therefore I am fine with revert
> and I can submit later better fix.
Great, thanks for letting me know, I can have someone work on the
"better fix" at the same time.
greg k-h
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 :)
On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
> This reverts commit 615f22f58029aa747b12768985e7f91cd053daa2.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/nfc/s3fwrn5/firmware.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/nfc/s3fwrn5/firmware.c b/drivers/nfc/s3fwrn5/firmware.c
> index eb5d7a5beac7..f77f183c9bd0 100644
> --- a/drivers/nfc/s3fwrn5/firmware.c
> +++ b/drivers/nfc/s3fwrn5/firmware.c
> @@ -492,10 +492,7 @@ int s3fwrn5_fw_recv_frame(struct nci_dev *ndev, struct sk_buff *skb)
> struct s3fwrn5_info *info = nci_get_drvdata(ndev);
> struct s3fwrn5_fw_info *fw_info = &info->fw_info;
>
> - if (WARN_ON(fw_info->rsp)) {
> - kfree_skb(skb);
> - return -EINVAL;
> - }
> + BUG_ON(fw_info->rsp);
It took me some time to understand this but the original commit looks
correct. The recv_frame functions s3fwrn5_recv_frame() or
nci_recv_frame() should free the skb buffer on errors. Here, the
s3fwrn5_fw_recv_frame() should be called only after sending a FW msg and
is expected to have fw_info->rsp=NULL. Otherwise it could mean that
frame came twice or it came when we did not ask for it.
Original code looks good, please drop the revert.
Best regards,
Krzysztof
Em Fri, 23 Apr 2021 09:10:32 +0200
Greg Kroah-Hartman <[email protected]> escreveu:
> On Fri, Apr 23, 2021 at 09:04:27AM +0200, Krzysztof Kozlowski wrote:
> > On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
> > > This reverts commit 78741ce98c2e36188e2343434406b0e0bc50b0e7.
> > >
> > > 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.
> > >
> > > Cc: Qiushi Wu <[email protected]>
> > > Cc: Hans Verkuil <[email protected]>
> > > Cc: Mauro Carvalho Chehab <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > ---
> > > drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 4 +---
> > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> >
> > This looks like a good commit but should be done now in a different way
> > - using pm_runtime_resume_and_get(). Therefore I am fine with revert
> > and I can submit later better fix.
>
> Great, thanks for letting me know, I can have someone work on the
> "better fix" at the same time.
IMO, it is better to keep the fix. I mean, there's no reason to
revert a fix that it is known to be good.
The "better fix" patch can be produced anytime. A simple coccinelle
ruleset can replace patterns like:
ret = pm_runtime_get_sync(pm->device);
if (ret < 0) {
pm_runtime_put_noidle(pm->device);
return ret;
}
and the broken pattern:
ret = pm_runtime_get_sync(pm->device);
if (ret < 0)
return ret;
to:
ret = pm_runtime_resume_and_get(pm->device);
if (ret < 0)
return ret;
Regards,
Mauro
On 23/04/2021 10:07, Mauro Carvalho Chehab wrote:
> Em Fri, 23 Apr 2021 09:10:32 +0200
> Greg Kroah-Hartman <[email protected]> escreveu:
>
>> On Fri, Apr 23, 2021 at 09:04:27AM +0200, Krzysztof Kozlowski wrote:
>>> On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
>>>> This reverts commit 78741ce98c2e36188e2343434406b0e0bc50b0e7.
>>>>
>>>> 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.
>>>>
>>>> Cc: Qiushi Wu <[email protected]>
>>>> Cc: Hans Verkuil <[email protected]>
>>>> Cc: Mauro Carvalho Chehab <[email protected]>
>>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>>> ---
>>>> drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 4 +---
>>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>>
>>>
>>> This looks like a good commit but should be done now in a different way
>>> - using pm_runtime_resume_and_get(). Therefore I am fine with revert
>>> and I can submit later better fix.
>>
>> Great, thanks for letting me know, I can have someone work on the
>> "better fix" at the same time.
>
> IMO, it is better to keep the fix. I mean, there's no reason to
> revert a fix that it is known to be good.
>
> The "better fix" patch can be produced anytime. A simple coccinelle
> ruleset can replace patterns like:
>
> ret = pm_runtime_get_sync(pm->device);
> if (ret < 0) {
> pm_runtime_put_noidle(pm->device);
> return ret;
> }
>
> and the broken pattern:
>
> ret = pm_runtime_get_sync(pm->device);
> if (ret < 0)
> return ret;
>
> to:
>
> ret = pm_runtime_resume_and_get(pm->device);
> if (ret < 0)
> return ret;
That's my preference as well.
Hans
>
> Regards,
> Mauro
>
On 23/04/2021 10:10, Hans Verkuil wrote:
> On 23/04/2021 10:07, Mauro Carvalho Chehab wrote:
>> Em Fri, 23 Apr 2021 09:10:32 +0200
>> Greg Kroah-Hartman <[email protected]> escreveu:
>>
>>> On Fri, Apr 23, 2021 at 09:04:27AM +0200, Krzysztof Kozlowski wrote:
>>>> On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
>>>>> This reverts commit 78741ce98c2e36188e2343434406b0e0bc50b0e7.
>>>>>
>>>>> 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.
>>>>>
>>>>> Cc: Qiushi Wu <[email protected]>
>>>>> Cc: Hans Verkuil <[email protected]>
>>>>> Cc: Mauro Carvalho Chehab <[email protected]>
>>>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>>>> ---
>>>>> drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 4 +---
>>>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>>>
>>>>
>>>> This looks like a good commit but should be done now in a different way
>>>> - using pm_runtime_resume_and_get(). Therefore I am fine with revert
>>>> and I can submit later better fix.
>>>
>>> Great, thanks for letting me know, I can have someone work on the
>>> "better fix" at the same time.
>>
>> IMO, it is better to keep the fix. I mean, there's no reason to
>> revert a fix that it is known to be good.
>>
>> The "better fix" patch can be produced anytime. A simple coccinelle
>> ruleset can replace patterns like:
>>
>> ret = pm_runtime_get_sync(pm->device);
>> if (ret < 0) {
>> pm_runtime_put_noidle(pm->device);
>> return ret;
>> }
>>
>> and the broken pattern:
>>
>> ret = pm_runtime_get_sync(pm->device);
>> if (ret < 0)
>> return ret;
>>
>> to:
>>
>> ret = pm_runtime_resume_and_get(pm->device);
>> if (ret < 0)
>> return ret;
>
> That's my preference as well.
It won't be that easy because sometimes the error handling is via goto
(like in other patches here) but anyway I don't mind keeping the
original commits.
Best regards,
Krzysztof
On Fri, 23 Apr 2021, Krzysztof Kozlowski wrote:
> On 23/04/2021 10:10, Hans Verkuil wrote:
> > On 23/04/2021 10:07, Mauro Carvalho Chehab wrote:
> >> Em Fri, 23 Apr 2021 09:10:32 +0200
> >> Greg Kroah-Hartman <[email protected]> escreveu:
> >>
> >>> On Fri, Apr 23, 2021 at 09:04:27AM +0200, Krzysztof Kozlowski wrote:
> >>>> On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
> >>>>> This reverts commit 78741ce98c2e36188e2343434406b0e0bc50b0e7.
> >>>>>
> >>>>> 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.
> >>>>>
> >>>>> Cc: Qiushi Wu <[email protected]>
> >>>>> Cc: Hans Verkuil <[email protected]>
> >>>>> Cc: Mauro Carvalho Chehab <[email protected]>
> >>>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >>>>> ---
> >>>>> drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 4 +---
> >>>>> 1 file changed, 1 insertion(+), 3 deletions(-)
> >>>>>
> >>>>
> >>>> This looks like a good commit but should be done now in a different way
> >>>> - using pm_runtime_resume_and_get(). Therefore I am fine with revert
> >>>> and I can submit later better fix.
> >>>
> >>> Great, thanks for letting me know, I can have someone work on the
> >>> "better fix" at the same time.
> >>
> >> IMO, it is better to keep the fix. I mean, there's no reason to
> >> revert a fix that it is known to be good.
> >>
> >> The "better fix" patch can be produced anytime. A simple coccinelle
> >> ruleset can replace patterns like:
> >>
> >> ret = pm_runtime_get_sync(pm->device);
> >> if (ret < 0) {
> >> pm_runtime_put_noidle(pm->device);
> >> return ret;
> >> }
> >>
> >> and the broken pattern:
> >>
> >> ret = pm_runtime_get_sync(pm->device);
> >> if (ret < 0)
> >> return ret;
> >>
> >> to:
> >>
> >> ret = pm_runtime_resume_and_get(pm->device);
> >> if (ret < 0)
> >> return ret;
> >
> > That's my preference as well.
>
> It won't be that easy because sometimes the error handling is via goto
> (like in other patches here) but anyway I don't mind keeping the
> original commits.
I tried the following semantic patch:
@@
expression ret,e;
@@
- ret = pm_runtime_get_sync(e);
+ ret = pm_resume_and_get(e);
if (ret < 0) {
...
?- pm_runtime_put_noidle(e);
...
return ret;
}
It has the following features:
* The ? means that if pm_runtime_put_noidle is absent, the transformation
will happen anyway.
* The ... before the return means that the matching will jump over a goto.
It makes a lot of changes (in a kernel I had handy from March). This is a
complicated API, however, and I don't know if there are any other issues
to take into account, especially in the case where the call to
pm_runtime_put_noidle is not present.
julia
On Fri, Apr 23, 2021 at 01:33:07AM +0200, Thomas Gleixner wrote:
> On Wed, Apr 21 2021 at 12:49, Kees Cook wrote:
> > On Wed, Apr 21, 2021 at 02:59:48PM +0200, Greg Kroah-Hartman wrote:
> >> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> >> index 08651a4e6aa0..0515a97bf6f5 100644
> >> --- a/arch/x86/kernel/hpet.c
> >> +++ b/arch/x86/kernel/hpet.c
> >> @@ -930,8 +930,6 @@ int __init hpet_enable(void)
> >> return 0;
> >>
> >> hpet_set_mapping();
> >> - if (!hpet_virt_address)
> >> - return 0;
> >>
> >> /* Validate that the config register is working */
> >> if (!hpet_cfg_working())
> >
> > FWIW, this patch looks harmless. It is checking for a failure in
> > hpet_set_mapping(), and avoids the following code from performing
> > 0-offset reads. hpet_set_mapping() is likely to never fail in real-world
> > situations. *shrug*
>
> 'likely never to fail' is clearly a receipe for disaster and you should
> know that.
Of course -- I prefer to keep the sanity check. It just wasn't as good
as it could have been: it's not clear just by looking at the patch how
hpet_virt_address and hpet_set_mapping() are related.
>
> > I think it would make more sense for the check to live in
> > hpet_cfg_working(), though.
>
> No. That does not make any sense at all.
>
> The proper change would have been to make hpet_set_mapping() return
> an error/success code and act on that.
>
> But that does _NOT_ make the patch invalid.
>
> I'm pretty sure that I looked at it and thought about the proper
> solution (see above) and then shrugged it off because of overload...
Right, no, I was saying the original patch should stay. It shouldn't be
reverted.
Greg, please drop this patch from the revert list.
--
Kees Cook
On 23/04/2021 10:41, Julia Lawall wrote:
>
>
> On Fri, 23 Apr 2021, Krzysztof Kozlowski wrote:
>
>> On 23/04/2021 10:10, Hans Verkuil wrote:
>>> On 23/04/2021 10:07, Mauro Carvalho Chehab wrote:
>>>> Em Fri, 23 Apr 2021 09:10:32 +0200
>>>> Greg Kroah-Hartman <[email protected]> escreveu:
>>>>
>>>>> On Fri, Apr 23, 2021 at 09:04:27AM +0200, Krzysztof Kozlowski wrote:
>>>>>> On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
>>>>>>> This reverts commit 78741ce98c2e36188e2343434406b0e0bc50b0e7.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> Cc: Qiushi Wu <[email protected]>
>>>>>>> Cc: Hans Verkuil <[email protected]>
>>>>>>> Cc: Mauro Carvalho Chehab <[email protected]>
>>>>>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>>>>>> ---
>>>>>>> drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 4 +---
>>>>>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>>>>>
>>>>>>
>>>>>> This looks like a good commit but should be done now in a different way
>>>>>> - using pm_runtime_resume_and_get(). Therefore I am fine with revert
>>>>>> and I can submit later better fix.
>>>>>
>>>>> Great, thanks for letting me know, I can have someone work on the
>>>>> "better fix" at the same time.
>>>>
>>>> IMO, it is better to keep the fix. I mean, there's no reason to
>>>> revert a fix that it is known to be good.
>>>>
>>>> The "better fix" patch can be produced anytime. A simple coccinelle
>>>> ruleset can replace patterns like:
>>>>
>>>> ret = pm_runtime_get_sync(pm->device);
>>>> if (ret < 0) {
>>>> pm_runtime_put_noidle(pm->device);
>>>> return ret;
>>>> }
>>>>
>>>> and the broken pattern:
>>>>
>>>> ret = pm_runtime_get_sync(pm->device);
>>>> if (ret < 0)
>>>> return ret;
>>>>
>>>> to:
>>>>
>>>> ret = pm_runtime_resume_and_get(pm->device);
>>>> if (ret < 0)
>>>> return ret;
>>>
>>> That's my preference as well.
>>
>> It won't be that easy because sometimes the error handling is via goto
>> (like in other patches here) but anyway I don't mind keeping the
>> original commits.
>
> I tried the following semantic patch:
>
> @@
> expression ret,e;
> @@
>
> - ret = pm_runtime_get_sync(e);
> + ret = pm_resume_and_get(e);
> if (ret < 0) {
> ...
> ?- pm_runtime_put_noidle(e);
> ...
> return ret;
> }
>
> It has the following features:
>
> * The ? means that if pm_runtime_put_noidle is absent, the transformation
> will happen anyway.
>
> * The ... before the return means that the matching will jump over a goto.
>
> It makes a lot of changes (in a kernel I had handy from March). This is a
> complicated API, however, and I don't know if there are any other issues
> to take into account, especially in the case where the call to
> pm_runtime_put_noidle is not present.
Thanks Julia, looks good.
Minor notice, the drivers could cleanup also with pm_runtime_put(). This
would not be the best code, but still would work and should be correct
(decrements runtime PM usage counter and tries to suspend the device if
it is resumed/active).
Such pattern could be in entire probe like:
device_probe() {
if (pm_runtime_get_sync())
return -EINVAL;
// PM runtime usage counter inbalance on errors
...
// suspend device
pm_runtime_put();
return 0;
}
I think this should still work fine with your pattern, so overall risk
of errors from coccicheck is small.
Best regards,
Krzysztof
On Wed, 21 Apr 2021, Greg Kroah-Hartman wrote:
> This reverts commit 9e28989d41c0eab57ec0bb156617a8757406ff8a.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Lee Jones <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/mfd/mc13xxx-core.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
> index 1abe7432aad8..b2beb7c39cc5 100644
> --- a/drivers/mfd/mc13xxx-core.c
> +++ b/drivers/mfd/mc13xxx-core.c
> @@ -271,9 +271,7 @@ int mc13xxx_adc_do_conversion(struct mc13xxx *mc13xxx, unsigned int mode,
>
> mc13xxx->adcflags |= MC13XXX_ADC_WORKING;
>
> - ret = mc13xxx_reg_read(mc13xxx, MC13XXX_ADC0, &old_adc0);
> - if (ret)
> - goto out;
> + mc13xxx_reg_read(mc13xxx, MC13XXX_ADC0, &old_adc0);
>
> adc0 = MC13XXX_ADC0_ADINC1 | MC13XXX_ADC0_ADINC2 |
> MC13XXX_ADC0_CHRGRAWDIV;
Thanks for bringing this commit to my attention.
The associated LWN article was an interesting read and I have to say,
I was very disappointed to hear about the actions of these so called
researchers.
Upon re-review of the original commit, this one does appear valid.
Do I need to conduct anymore due diligence or can I drop this patch?
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
(adding c/c to Rafael)
Em Fri, 23 Apr 2021 10:41:32 +0200 (CEST)
Julia Lawall <[email protected]> escreveu:
> On Fri, 23 Apr 2021, Krzysztof Kozlowski wrote:
>
> > On 23/04/2021 10:10, Hans Verkuil wrote:
> > > On 23/04/2021 10:07, Mauro Carvalho Chehab wrote:
> > >> Em Fri, 23 Apr 2021 09:10:32 +0200
> > >> Greg Kroah-Hartman <[email protected]> escreveu:
> > >>
> > >>> On Fri, Apr 23, 2021 at 09:04:27AM +0200, Krzysztof Kozlowski wrote:
> > >>>> On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
> > >>>>> This reverts commit 78741ce98c2e36188e2343434406b0e0bc50b0e7.
> > >>>>>
> > >>>>> 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.
> > >>>>>
> > >>>>> Cc: Qiushi Wu <[email protected]>
> > >>>>> Cc: Hans Verkuil <[email protected]>
> > >>>>> Cc: Mauro Carvalho Chehab <[email protected]>
> > >>>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > >>>>> ---
> > >>>>> drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 4 +---
> > >>>>> 1 file changed, 1 insertion(+), 3 deletions(-)
> > >>>>>
> > >>>>
> > >>>> This looks like a good commit but should be done now in a different way
> > >>>> - using pm_runtime_resume_and_get(). Therefore I am fine with revert
> > >>>> and I can submit later better fix.
> > >>>
> > >>> Great, thanks for letting me know, I can have someone work on the
> > >>> "better fix" at the same time.
> > >>
> > >> IMO, it is better to keep the fix. I mean, there's no reason to
> > >> revert a fix that it is known to be good.
> > >>
> > >> The "better fix" patch can be produced anytime. A simple coccinelle
> > >> ruleset can replace patterns like:
> > >>
> > >> ret = pm_runtime_get_sync(pm->device);
> > >> if (ret < 0) {
> > >> pm_runtime_put_noidle(pm->device);
> > >> return ret;
> > >> }
> > >>
> > >> and the broken pattern:
> > >>
> > >> ret = pm_runtime_get_sync(pm->device);
> > >> if (ret < 0)
> > >> return ret;
> > >>
> > >> to:
> > >>
> > >> ret = pm_runtime_resume_and_get(pm->device);
> > >> if (ret < 0)
> > >> return ret;
> > >
> > > That's my preference as well.
> >
> > It won't be that easy because sometimes the error handling is via goto
> > (like in other patches here) but anyway I don't mind keeping the
> > original commits.
>
> I tried the following semantic patch:
>
> @@
> expression ret,e;
> @@
>
> - ret = pm_runtime_get_sync(e);
> + ret = pm_resume_and_get(e);
> if (ret < 0) {
> ...
> ?- pm_runtime_put_noidle(e);
> ...
> return ret;
> }
>
> It has the following features:
>
> * The ? means that if pm_runtime_put_noidle is absent, the transformation
> will happen anyway.
>
> * The ... before the return means that the matching will jump over a goto.
>
> It makes a lot of changes (in a kernel I had handy from March).
I would expect lots of changes, as the pm_runtime_resume_and_get() was only
recently introduced on this changeset:
commit dd8088d5a8969dc2b42f71d7bc01c25c61a78066
Author: Zhang Qilong <[email protected]>
Date: Tue Nov 10 17:29:32 2020 +0800
PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter
In many case, we need to check return value of pm_runtime_get_sync, but
it brings a trouble to the usage counter processing. Many callers forget
to decrease the usage counter when it failed, which could resulted in
reference leak. It has been discussed a lot[0][1]. So we add a function
to deal with the usage counter for better coding.
[0]https://lkml.org/lkml/2020/6/14/88
[1]https://patchwork.ozlabs.org/project/linux-tegra/list/?series=178139
Signed-off-by: Zhang Qilong <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
> This is a
> complicated API, however, and I don't know if there are any other issues
> to take into account, especially in the case where the call to
> pm_runtime_put_noidle is not present.
I double-checked the code, despite its name, pm_runtime_put_noidle() just
changes the refcount. See, the relevant code is here:
static inline void pm_runtime_put_noidle(struct device *dev)
{
atomic_add_unless(&dev->power.usage_count, -1, 0);
}
static inline int pm_runtime_get_sync(struct device *dev)
{
return __pm_runtime_resume(dev, RPM_GET_PUT);
}
int __pm_runtime_resume(struct device *dev, int rpmflags)
{
unsigned long flags;
int retval;
might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe &&
dev->power.runtime_status != RPM_ACTIVE);
if (rpmflags & RPM_GET_PUT)
atomic_inc(&dev->power.usage_count);
spin_lock_irqsave(&dev->power.lock, flags);
retval = rpm_resume(dev, rpmflags);
spin_unlock_irqrestore(&dev->power.lock, flags);
return retval;
}
Not being an expert at the PM runtime API, at least on my eyes,
replacing pm_runtime_get_sync() by pm_runtime_resume_and_get()
seems to be the right thing to do, but Rafael should know more.
Thanks,
Mauro
On Fri, Apr 23, 2021 at 10:30:42AM +0100, Lee Jones wrote:
> On Wed, 21 Apr 2021, Greg Kroah-Hartman wrote:
>
> > This reverts commit 9e28989d41c0eab57ec0bb156617a8757406ff8a.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Lee Jones <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/mfd/mc13xxx-core.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
> > index 1abe7432aad8..b2beb7c39cc5 100644
> > --- a/drivers/mfd/mc13xxx-core.c
> > +++ b/drivers/mfd/mc13xxx-core.c
> > @@ -271,9 +271,7 @@ int mc13xxx_adc_do_conversion(struct mc13xxx *mc13xxx, unsigned int mode,
> >
> > mc13xxx->adcflags |= MC13XXX_ADC_WORKING;
> >
> > - ret = mc13xxx_reg_read(mc13xxx, MC13XXX_ADC0, &old_adc0);
> > - if (ret)
> > - goto out;
> > + mc13xxx_reg_read(mc13xxx, MC13XXX_ADC0, &old_adc0);
> >
> > adc0 = MC13XXX_ADC0_ADINC1 | MC13XXX_ADC0_ADINC2 |
> > MC13XXX_ADC0_CHRGRAWDIV;
>
> Thanks for bringing this commit to my attention.
>
> The associated LWN article was an interesting read and I have to say,
> I was very disappointed to hear about the actions of these so called
> researchers.
>
> Upon re-review of the original commit, this one does appear valid.
>
> Do I need to conduct anymore due diligence or can I drop this patch?
Nope, that's it, I'll drop this from my series, thanks for the review!
greg k-h
On Thu, Apr 22 2021 at 00:09, Bjorn Helgaas wrote:
> On Wed, Apr 21, 2021 at 02:59:21PM +0200, Greg Kroah-Hartman wrote:
> I would prefer that you not apply this revert.
>
> Prior to ea094d53580f ("x86/PCI: Fix PCI IRQ routing table memory
> leak"), we had essentially this:
>
> pcibios_irq_init()
> pirq_table = pcibios_get_irq_routing_table(); # kmallocs
> if (pirq_table) {
> if (io_apic_assign_pci_irqs)
> pirq_table = NULL;
> }
>
> So if we called pcibios_get_irq_routing_table(), we kmalloced some
> space and then (if io_apic_assign_pci_irqs) threw away the pointer,
> which leaks the pointer as the commit log says.
>
> After ea094d53580f, we have:
>
> pcibios_irq_init()
> rtable = NULL;
> pirq_table = pcibios_get_irq_routing_table(); # kmallocs
> rtable = pirq_table;
> if (pirq_table) {
> if (io_apic_assign_pci_irqs) {
> kfree(rtable);
> pirq_table = NULL;
> }
> }
>
> which seems right to me.
It is correct.
Though looking at it again, the question is why this invokes
pcibios_get_irq_routing_table() at all if io_apic_assign_pci_irqs is
true?
Thanks,
tglx
Em Fri, 23 Apr 2021 11:42:55 +0200
Mauro Carvalho Chehab <[email protected]> escreveu:
> (adding c/c to Rafael)
>
> Em Fri, 23 Apr 2021 10:41:32 +0200 (CEST)
> Julia Lawall <[email protected]> escreveu:
>
> > On Fri, 23 Apr 2021, Krzysztof Kozlowski wrote:
> >
> > > On 23/04/2021 10:10, Hans Verkuil wrote:
> > > > On 23/04/2021 10:07, Mauro Carvalho Chehab wrote:
> > > >> Em Fri, 23 Apr 2021 09:10:32 +0200
> > > >> Greg Kroah-Hartman <[email protected]> escreveu:
> > > >>
> > > >>> On Fri, Apr 23, 2021 at 09:04:27AM +0200, Krzysztof Kozlowski wrote:
> > > >>>> On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
> > > >>>>> This reverts commit 78741ce98c2e36188e2343434406b0e0bc50b0e7.
> > > >>>>>
> > > >>>>> 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.
> > > >>>>>
> > > >>>>> Cc: Qiushi Wu <[email protected]>
> > > >>>>> Cc: Hans Verkuil <[email protected]>
> > > >>>>> Cc: Mauro Carvalho Chehab <[email protected]>
> > > >>>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > >>>>> ---
> > > >>>>> drivers/media/platform/s5p-mfc/s5p_mfc_pm.c | 4 +---
> > > >>>>> 1 file changed, 1 insertion(+), 3 deletions(-)
> > > >>>>>
> > > >>>>
> > > >>>> This looks like a good commit but should be done now in a different way
> > > >>>> - using pm_runtime_resume_and_get(). Therefore I am fine with revert
> > > >>>> and I can submit later better fix.
> > > >>>
> > > >>> Great, thanks for letting me know, I can have someone work on the
> > > >>> "better fix" at the same time.
> > > >>
> > > >> IMO, it is better to keep the fix. I mean, there's no reason to
> > > >> revert a fix that it is known to be good.
> > > >>
> > > >> The "better fix" patch can be produced anytime. A simple coccinelle
> > > >> ruleset can replace patterns like:
> > > >>
> > > >> ret = pm_runtime_get_sync(pm->device);
> > > >> if (ret < 0) {
> > > >> pm_runtime_put_noidle(pm->device);
> > > >> return ret;
> > > >> }
> > > >>
> > > >> and the broken pattern:
> > > >>
> > > >> ret = pm_runtime_get_sync(pm->device);
> > > >> if (ret < 0)
> > > >> return ret;
> > > >>
> > > >> to:
> > > >>
> > > >> ret = pm_runtime_resume_and_get(pm->device);
> > > >> if (ret < 0)
> > > >> return ret;
> > > >
> > > > That's my preference as well.
> > >
> > > It won't be that easy because sometimes the error handling is via goto
> > > (like in other patches here) but anyway I don't mind keeping the
> > > original commits.
> >
> > I tried the following semantic patch:
> >
> > @@
> > expression ret,e;
> > @@
> >
> > - ret = pm_runtime_get_sync(e);
> > + ret = pm_resume_and_get(e);
> > if (ret < 0) {
> > ...
> > ?- pm_runtime_put_noidle(e);
> > ...
> > return ret;
> > }
> >
> > It has the following features:
> >
> > * The ? means that if pm_runtime_put_noidle is absent, the transformation
> > will happen anyway.
> >
> > * The ... before the return means that the matching will jump over a goto.
> >
> > It makes a lot of changes (in a kernel I had handy from March).
>
> I would expect lots of changes, as the pm_runtime_resume_and_get() was only
> recently introduced on this changeset:
>
> commit dd8088d5a8969dc2b42f71d7bc01c25c61a78066
> Author: Zhang Qilong <[email protected]>
> Date: Tue Nov 10 17:29:32 2020 +0800
>
> PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter
>
> In many case, we need to check return value of pm_runtime_get_sync, but
> it brings a trouble to the usage counter processing. Many callers forget
> to decrease the usage counter when it failed, which could resulted in
> reference leak. It has been discussed a lot[0][1]. So we add a function
> to deal with the usage counter for better coding.
>
> [0]https://lkml.org/lkml/2020/6/14/88
> [1]https://patchwork.ozlabs.org/project/linux-tegra/list/?series=178139
> Signed-off-by: Zhang Qilong <[email protected]>
> Acked-by: Rafael J. Wysocki <[email protected]>
> Signed-off-by: Jakub Kicinski <[email protected]>
>
> > This is a
> > complicated API, however, and I don't know if there are any other issues
> > to take into account, especially in the case where the call to
> > pm_runtime_put_noidle is not present.
>
> I double-checked the code, despite its name, pm_runtime_put_noidle() just
> changes the refcount. See, the relevant code is here:
>
> static inline void pm_runtime_put_noidle(struct device *dev)
> {
> atomic_add_unless(&dev->power.usage_count, -1, 0);
> }
>
> static inline int pm_runtime_get_sync(struct device *dev)
> {
> return __pm_runtime_resume(dev, RPM_GET_PUT);
> }
>
> int __pm_runtime_resume(struct device *dev, int rpmflags)
> {
> unsigned long flags;
> int retval;
>
> might_sleep_if(!(rpmflags & RPM_ASYNC) && !dev->power.irq_safe &&
> dev->power.runtime_status != RPM_ACTIVE);
>
> if (rpmflags & RPM_GET_PUT)
> atomic_inc(&dev->power.usage_count);
>
> spin_lock_irqsave(&dev->power.lock, flags);
> retval = rpm_resume(dev, rpmflags);
> spin_unlock_irqrestore(&dev->power.lock, flags);
>
> return retval;
> }
>
> Not being an expert at the PM runtime API, at least on my eyes,
> replacing pm_runtime_get_sync() by pm_runtime_resume_and_get()
> seems to be the right thing to do, but Rafael should know more.
The cocci recipe made some wrong error check logic on some drivers,
like, for instance: drivers/media/i2c/mt9m001.c.
On such drivers, the logic is like:
ret = pm_runtime_resume_get_sync(&client->dev);
if (ret < 0)
goto put_unlock;
ret = mt9m001_apply_selection(sd);
if (ret)
goto put_unlock;
...
put_unlock:
pm_runtime_put(&client->dev);
mutex_unlock(&mt9m001->mutex);
On those cases where there are gotos to a logic with either
pm_runtime_put() or pm_runtime_put_no_idle(), the coccinelle
receipt should probably ignore it.
Thanks,
Mauro
Hi Greg,
Many thanks for the patchset and notice us to take attention about these patches.
On 21/4/21 14:58, Greg Kroah-Hartman wrote:
> This reverts commit aaa3cbbac326c95308e315f1ab964a3369c4d07d.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: Mathew King <[email protected]>
> Cc: Enric Balletbo i Serra <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
I've reviewed the patch again (also double checked with people involved in this
driver) and I don't spot an obvious issue with the original patch. Without it,
on error path, the read-write sempahore used, will be released without having
held it before.
So it's IMO a valid fix that would have to be done the same way after
revert.
Please don't revert it.
Thanks,
Enric
> ---
> drivers/platform/chrome/cros_ec_ishtp.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/platform/chrome/cros_ec_ishtp.c b/drivers/platform/chrome/cros_ec_ishtp.c
> index f00107017318..d4f41d68232c 100644
> --- a/drivers/platform/chrome/cros_ec_ishtp.c
> +++ b/drivers/platform/chrome/cros_ec_ishtp.c
> @@ -677,10 +677,8 @@ static int cros_ec_ishtp_probe(struct ishtp_cl_device *cl_device)
>
> /* Register croc_ec_dev mfd */
> rv = cros_ec_dev_init(client_data);
> - if (rv) {
> - down_write(&init_lock);
> + if (rv)
> goto end_cros_ec_dev_init_error;
> - }
>
> return 0;
>
>
On Wed, Apr 21, 2021 at 03:00:11PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 0b31d98d90f09868dce71319615e19cd1f146fb6.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
+Cc: Sunil Goutham <[email protected]>
The original patch looks correct to me.
> ---
> drivers/net/ethernet/cavium/thunder/nicvf_main.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> index c33b4e837515..b10608c55db0 100644
> --- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> +++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
> @@ -2246,12 +2246,6 @@ static int nicvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> nic->nicvf_rx_mode_wq = alloc_ordered_workqueue("nicvf_rx_mode_wq_VF%d",
> WQ_MEM_RECLAIM,
> nic->vf_id);
> - if (!nic->nicvf_rx_mode_wq) {
> - err = -ENOMEM;
> - dev_err(dev, "Failed to allocate work queue\n");
> - goto err_unregister_interrupts;
> - }
> -
> INIT_WORK(&nic->rx_mode_work.work, nicvf_set_rx_mode_task);
> spin_lock_init(&nic->rx_mode_wq_lock);
>
> --
> 2.31.1
>
--
Josh
On 4/22/21 3:29 PM, Peter Rosin wrote:
>> This reverts commit 093c48213ee37c3c3ff1cf5ac1aa2a9d8bc66017.
>
> The reverted patch looks fishy.
>
> gc.cd_info is kzalloc:ed on probe. In case probe fails after this allocation, the
> memory is kfree:d but the variable is NOT zeroed out.
>
> AFAICT, the above leads to a double-free on exit by the added line.
>
> I believe gd.cd_info should be kfree:d on remove instead.
>
> However, might not gc.toc also be kfree:d twice for similar reasons?
>
> I could easily be mistaken.
From taking a quick look the other day, that's my conclusion too. I
don't think the patch is correct, but I don't think the surrounding code
is correct right now either.
--
Jens Axboe
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
On Wed, Apr 21, 2021 at 6:08 AM Greg Kroah-Hartman
<[email protected]> wrote:
>
> This reverts commit 486fa92df4707b5df58d6508728bdb9321a59766.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Dan Williams <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Upon re-review, this fix still looks good to me, revert is not necessary.
> ---
> drivers/nvdimm/btt_devs.c | 18 +++++-------------
> 1 file changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/nvdimm/btt_devs.c b/drivers/nvdimm/btt_devs.c
> index 05feb97e11ce..995573905dfb 100644
> --- a/drivers/nvdimm/btt_devs.c
> +++ b/drivers/nvdimm/btt_devs.c
> @@ -191,15 +191,14 @@ static struct device *__nd_btt_create(struct nd_region *nd_region,
> return NULL;
>
> nd_btt->id = ida_simple_get(&nd_region->btt_ida, 0, 0, GFP_KERNEL);
> - if (nd_btt->id < 0)
> - goto out_nd_btt;
> + if (nd_btt->id < 0) {
> + kfree(nd_btt);
> + return NULL;
> + }
>
> nd_btt->lbasize = lbasize;
> - if (uuid) {
> + if (uuid)
> uuid = kmemdup(uuid, 16, GFP_KERNEL);
> - if (!uuid)
> - goto out_put_id;
> - }
> nd_btt->uuid = uuid;
> dev = &nd_btt->dev;
> dev_set_name(dev, "btt%d.%d", nd_region->id, nd_btt->id);
> @@ -213,13 +212,6 @@ static struct device *__nd_btt_create(struct nd_region *nd_region,
> return NULL;
> }
> return dev;
> -
> -out_put_id:
> - ida_simple_remove(&nd_region->btt_ida, nd_btt->id);
> -
> -out_nd_btt:
> - kfree(nd_btt);
> - return NULL;
> }
>
> struct device *nd_btt_create(struct nd_region *nd_region)
> --
> 2.31.1
>
On Wed, Apr 21, 2021 at 6:08 AM Greg Kroah-Hartman
<[email protected]> wrote:
>
> This reverts commit 55c1fc0af29a6c1b92f217b7eb7581a882e0c07c.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Dan Williams <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Upon re-review this change still looks correct, no need for a revert.
> ---
> drivers/nvdimm/namespace_devs.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/nvdimm/namespace_devs.c b/drivers/nvdimm/namespace_devs.c
> index 2403b71b601e..04f7cb7a23b7 100644
> --- a/drivers/nvdimm/namespace_devs.c
> +++ b/drivers/nvdimm/namespace_devs.c
> @@ -2297,12 +2297,9 @@ static struct device *create_namespace_blk(struct nd_region *nd_region,
> if (!nsblk->uuid)
> goto blk_err;
> memcpy(name, nd_label->name, NSLABEL_NAME_LEN);
> - if (name[0]) {
> + if (name[0])
> nsblk->alt_name = kmemdup(name, NSLABEL_NAME_LEN,
> GFP_KERNEL);
> - if (!nsblk->alt_name)
> - goto blk_err;
> - }
> res = nsblk_add_resource(nd_region, ndd, nsblk,
> __le64_to_cpu(nd_label->dpa));
> if (!res)
> --
> 2.31.1
>
On Fri, Apr 23, 2021 at 08:00:06AM -0500, Josh Poimboeuf wrote:
> On Wed, Apr 21, 2021 at 03:00:11PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 0b31d98d90f09868dce71319615e19cd1f146fb6.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: David S. Miller <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> +Cc: Sunil Goutham <[email protected]>
>
> The original patch looks correct to me.
Now dropped, thanks for the review.
greg k-h
On Fri, Apr 23, 2021 at 12:48:01PM +0200, Enric Balletbo i Serra wrote:
> Hi Greg,
>
> Many thanks for the patchset and notice us to take attention about these patches.
>
> On 21/4/21 14:58, Greg Kroah-Hartman wrote:
> > This reverts commit aaa3cbbac326c95308e315f1ab964a3369c4d07d.
> >
> > 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.
> >
> > Cc: Qiushi Wu <[email protected]>
> > Cc: Mathew King <[email protected]>
> > Cc: Enric Balletbo i Serra <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> I've reviewed the patch again (also double checked with people involved in this
> driver) and I don't spot an obvious issue with the original patch. Without it,
> on error path, the read-write sempahore used, will be released without having
> held it before.
>
> So it's IMO a valid fix that would have to be done the same way after
> revert.
>
> Please don't revert it.
Dropped from my patch series, thanks for the review.
greg k-h
On Fri, Apr 23, 2021 at 01:57:00PM -0700, Dan Williams wrote:
> On Wed, Apr 21, 2021 at 6:08 AM Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This reverts commit 55c1fc0af29a6c1b92f217b7eb7581a882e0c07c.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Dan Williams <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> Upon re-review this change still looks correct, no need for a revert.
Revert is dropped, thanks for the review.
greg k-h
On Fri, Apr 23, 2021 at 01:49:39PM -0700, Dan Williams wrote:
> On Wed, Apr 21, 2021 at 6:08 AM Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This reverts commit 486fa92df4707b5df58d6508728bdb9321a59766.
> >
> > 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.
> >
> > Cc: Aditya Pakki <[email protected]>
> > Cc: Dan Williams <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> Upon re-review, this fix still looks good to me, revert is not necessary.
Thanks for the review, I'll drop the revert.
greg k-h
On Fri, Apr 23, 2021 at 11:53:31AM +0200, Thomas Gleixner wrote:
> On Thu, Apr 22 2021 at 00:09, Bjorn Helgaas wrote:
> > On Wed, Apr 21, 2021 at 02:59:21PM +0200, Greg Kroah-Hartman wrote:
> > I would prefer that you not apply this revert.
> >
> > Prior to ea094d53580f ("x86/PCI: Fix PCI IRQ routing table memory
> > leak"), we had essentially this:
> >
> > pcibios_irq_init()
> > pirq_table = pcibios_get_irq_routing_table(); # kmallocs
> > if (pirq_table) {
> > if (io_apic_assign_pci_irqs)
> > pirq_table = NULL;
> > }
> >
> > So if we called pcibios_get_irq_routing_table(), we kmalloced some
> > space and then (if io_apic_assign_pci_irqs) threw away the pointer,
> > which leaks the pointer as the commit log says.
> >
> > After ea094d53580f, we have:
> >
> > pcibios_irq_init()
> > rtable = NULL;
> > pirq_table = pcibios_get_irq_routing_table(); # kmallocs
> > rtable = pirq_table;
> > if (pirq_table) {
> > if (io_apic_assign_pci_irqs) {
> > kfree(rtable);
> > pirq_table = NULL;
> > }
> > }
> >
> > which seems right to me.
>
> It is correct.
Thanks for the review, I'll go drop this revert.
greg k-h
On Fri, Apr 23, 2021 at 02:03:50AM -0700, Kees Cook wrote:
> On Fri, Apr 23, 2021 at 01:33:07AM +0200, Thomas Gleixner wrote:
> > On Wed, Apr 21 2021 at 12:49, Kees Cook wrote:
> > > On Wed, Apr 21, 2021 at 02:59:48PM +0200, Greg Kroah-Hartman wrote:
> > >> diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
> > >> index 08651a4e6aa0..0515a97bf6f5 100644
> > >> --- a/arch/x86/kernel/hpet.c
> > >> +++ b/arch/x86/kernel/hpet.c
> > >> @@ -930,8 +930,6 @@ int __init hpet_enable(void)
> > >> return 0;
> > >>
> > >> hpet_set_mapping();
> > >> - if (!hpet_virt_address)
> > >> - return 0;
> > >>
> > >> /* Validate that the config register is working */
> > >> if (!hpet_cfg_working())
> > >
> > > FWIW, this patch looks harmless. It is checking for a failure in
> > > hpet_set_mapping(), and avoids the following code from performing
> > > 0-offset reads. hpet_set_mapping() is likely to never fail in real-world
> > > situations. *shrug*
> >
> > 'likely never to fail' is clearly a receipe for disaster and you should
> > know that.
>
> Of course -- I prefer to keep the sanity check. It just wasn't as good
> as it could have been: it's not clear just by looking at the patch how
> hpet_virt_address and hpet_set_mapping() are related.
>
> >
> > > I think it would make more sense for the check to live in
> > > hpet_cfg_working(), though.
> >
> > No. That does not make any sense at all.
> >
> > The proper change would have been to make hpet_set_mapping() return
> > an error/success code and act on that.
> >
> > But that does _NOT_ make the patch invalid.
> >
> > I'm pretty sure that I looked at it and thought about the proper
> > solution (see above) and then shrugged it off because of overload...
>
> Right, no, I was saying the original patch should stay. It shouldn't be
> reverted.
>
> Greg, please drop this patch from the revert list.
Now dropped, thanks for the review.
greg k-h
On Fri, Apr 23, 2021 at 10:30:42AM +0100, Lee Jones wrote:
> On Wed, 21 Apr 2021, Greg Kroah-Hartman wrote:
>
> > This reverts commit 9e28989d41c0eab57ec0bb156617a8757406ff8a.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Lee Jones <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/mfd/mc13xxx-core.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
> > index 1abe7432aad8..b2beb7c39cc5 100644
> > --- a/drivers/mfd/mc13xxx-core.c
> > +++ b/drivers/mfd/mc13xxx-core.c
> > @@ -271,9 +271,7 @@ int mc13xxx_adc_do_conversion(struct mc13xxx *mc13xxx, unsigned int mode,
> >
> > mc13xxx->adcflags |= MC13XXX_ADC_WORKING;
> >
> > - ret = mc13xxx_reg_read(mc13xxx, MC13XXX_ADC0, &old_adc0);
> > - if (ret)
> > - goto out;
> > + mc13xxx_reg_read(mc13xxx, MC13XXX_ADC0, &old_adc0);
> >
> > adc0 = MC13XXX_ADC0_ADINC1 | MC13XXX_ADC0_ADINC2 |
> > MC13XXX_ADC0_CHRGRAWDIV;
>
> Thanks for bringing this commit to my attention.
>
> The associated LWN article was an interesting read and I have to say,
> I was very disappointed to hear about the actions of these so called
> researchers.
>
> Upon re-review of the original commit, this one does appear valid.
>
> Do I need to conduct anymore due diligence or can I drop this patch?
I've dropped this revert from my tree now, thanks.
greg k-h
On Thu, Apr 22, 2021 at 11:26:15PM +0200, Pablo Neira Ayuso wrote:
> Hi Greg,
>
> On Wed, Apr 21, 2021 at 02:59:58PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 6d65561f3d5ec933151939c543d006b79044e7a6.
> >
> > 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 patch looks correct, no need to revert.
>
> If you still prefer to revert it, no problem, I'll recover this fix
> via the netfilter tree later on.
Now dropped from my tree, thanks.
greg k-h
On Fri, Apr 23, 2021 at 09:09:21AM +0200, Krzysztof Kozlowski wrote:
> On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
> > This reverts commit 8d7a577d04e8ce24b1b81ee44ec8cd1dda2a9cd9.
> >
> > 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.
> >
> > Cc: Aditya Pakki <[email protected]>
> > Cc: https
> > Cc: Chanwoo Choi <[email protected]>
> > Cc: Stephen Boyd <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/clk/samsung/clk.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
> > index 1949ae7851b2..dad31308c071 100644
> > --- a/drivers/clk/samsung/clk.c
> > +++ b/drivers/clk/samsung/clk.c
> > @@ -356,6 +356,10 @@ struct samsung_clk_provider * __init samsung_cmu_register_one(
> > }
> >
> > ctx = samsung_clk_init(np, reg_base, cmu->nr_clk_ids);
> > + if (!ctx) {
> > + panic("%s: unable to allocate ctx\n", __func__);
> > + return ctx;
> > + }
>
> Hi Greg,
>
> The commit was fine here, so please keep it. NAK for the revert.
Now dropped, thanks!
greg k-h
On Thu, Apr 22, 2021 at 02:30:12PM +0300, Mika Westerberg wrote:
> On Wed, Apr 21, 2021 at 02:59:50PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit e4dfdd5804cce1255f99c5dd033526a18135a616.
> >
> > 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 one too is valid.
Now dropped, thanks.
greg k-h
On Fri, Apr 23, 2021 at 09:29:57AM +0200, Krzysztof Kozlowski wrote:
> On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
> > This reverts commit 615f22f58029aa747b12768985e7f91cd053daa2.
> >
> > 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.
> >
> > Cc: Aditya Pakki <[email protected]>
> > Cc: David S. Miller <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/nfc/s3fwrn5/firmware.c | 5 +----
> > 1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/drivers/nfc/s3fwrn5/firmware.c b/drivers/nfc/s3fwrn5/firmware.c
> > index eb5d7a5beac7..f77f183c9bd0 100644
> > --- a/drivers/nfc/s3fwrn5/firmware.c
> > +++ b/drivers/nfc/s3fwrn5/firmware.c
> > @@ -492,10 +492,7 @@ int s3fwrn5_fw_recv_frame(struct nci_dev *ndev, struct sk_buff *skb)
> > struct s3fwrn5_info *info = nci_get_drvdata(ndev);
> > struct s3fwrn5_fw_info *fw_info = &info->fw_info;
> >
> > - if (WARN_ON(fw_info->rsp)) {
> > - kfree_skb(skb);
> > - return -EINVAL;
> > - }
> > + BUG_ON(fw_info->rsp);
>
> It took me some time to understand this but the original commit looks
> correct. The recv_frame functions s3fwrn5_recv_frame() or
> nci_recv_frame() should free the skb buffer on errors. Here, the
> s3fwrn5_fw_recv_frame() should be called only after sending a FW msg and
> is expected to have fw_info->rsp=NULL. Otherwise it could mean that
> frame came twice or it came when we did not ask for it.
>
> Original code looks good, please drop the revert.
Thanks for the review, I've dropped the revert now.
greg k-h
On Thu, Apr 22, 2021 at 02:42:01PM +0300, Felipe Balbi wrote:
>
> Hi,
>
> Greg Kroah-Hartman <[email protected]> writes:
>
> > This reverts commit 2655971ad4b34e97dd921df16bb0b08db9449df7.
> >
> > 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.
> >
> > Cc: Aditya Pakki <[email protected]>
> > Cc: Felipe Balbi <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/usb/dwc3/dwc3-pci.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
> > index 4c5c6972124a..0c0619f7b1a7 100644
> > --- a/drivers/usb/dwc3/dwc3-pci.c
> > +++ b/drivers/usb/dwc3/dwc3-pci.c
> > @@ -226,10 +226,8 @@ static void dwc3_pci_resume_work(struct work_struct *work)
> > int ret;
> >
> > ret = pm_runtime_get_sync(&dwc3->dev);
> > - if (ret) {
> > - pm_runtime_put_sync_autosuspend(&dwc3->dev);
> > + if (ret)
> > return;
> > - }
>
> this was a valid fix. pm_runtime_get_sync() leaves an unbalanced get on
> the runtime usage counter.
>
> It's okay if you prefer to revert it and have a new review cycle for
> this, though.
I'll drop this revert now, thanks for the review.
greg k-h
On Thu, Apr 22, 2021 at 11:42:24AM +0100, Lorenzo Pieralisi wrote:
> On Wed, Apr 21, 2021 at 02:59:36PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 699ca30162686bf305cdf94861be02eb0cf9bda2.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Lorenzo Pieralisi <[email protected]>
> > Cc: Steven Price <[email protected]>
> > Cc: Mukesh Ojha <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/pci/controller/pcie-xilinx.c | 12 ++----------
> > 1 file changed, 2 insertions(+), 10 deletions(-)
>
> Hi Greg,
>
> For this revert - the commit we are reverting looked and looks OK
> to me even though honestly I'd revert it just on principle given
> the nuisance it is causing.
>
> Actually, we have code in -next that is removing the reverted content
> anyway (but not because it is bogus, code in -next is a nice clean-up
> for all PCI drivers from Marc):
>
> https://git.kernel.org/lpieralisi/pci/c/161260e7f7bc
>
> Again, happy to go ahead with the revert and rework the queued code
> on top of it, just let me know please.
I'll just drop this revert from my tree so as to not mess up your
follow-up cleanups, thanks for the review!
greg k-h
On Thu, Apr 22, 2021 at 11:40:21AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Apr 22, 2021 at 10:31:11AM +0100, Lorenzo Pieralisi wrote:
> > On Wed, Apr 21, 2021 at 02:59:24PM +0200, Greg Kroah-Hartman wrote:
> > > This reverts commit 507b820009a457afa78202da337bcb56791fbb12.
> > >
> > > 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.
> > >
> > > Cc: Kangjie Lu <[email protected]>
> > > Cc: commit log and code update]
> >
> > Hi Greg,
> >
> > first off, thank you for doing this.
> >
> > This Cc should be fixed up if we go ahead with the revert (I can
> > take the revert via the PCI tree and fix it up myself).
> >
> > I totally understand your concern (and the nuisance it is causing), the
> > commit we are reverting looked and looks legit - just let me know
> > how it is best to handle this please.
>
> I'll fix up all improper Cc: lines, that was my dumb script trying to
> catch who was on the reverted patch, when I apply these.
>
> I can take this through my tree, but as you said, if the original commit
> here really is fine, that's great, I'll drop this.
Now dropped from my tree.
greg k-
On Thu, Apr 22, 2021 at 10:42:08AM +0200, Pavel Machek wrote:
> On Wed 2021-04-21 14:58:50, Greg Kroah-Hartman wrote:
> > This reverts commit 67e2d2eb542338145a2e0b2336c1cdabd2424fd3.
> >
> > 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).
>
> This patch is correct AFAICT.
Now dropped, thanks.
greg k-h
On Thu, Apr 22, 2021 at 09:26:25AM +0100, Jonathan Cameron wrote:
> On Wed, 21 Apr 2021 14:59:28 +0200
> Greg Kroah-Hartman <[email protected]> wrote:
>
> > This reverts commit 536cc27deade8f1ec3c1beefa60d5fbe0f6fcb28.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Jonathan Cameron <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> Hi Greg,
>
> Checked this one. As far as I can tell it was a valid cleanup of
> error handling. Far from critical though and unlikely to be seen in practice.
>
> So either leave it in place, or we can bring it back later. I don't mind
> which.
Now dropped, thanks.
greg k-h
On Thu, Apr 22, 2021 at 09:35:05AM +0100, Jonathan Cameron wrote:
> On Wed, 21 Apr 2021 15:00:39 +0200
> Greg Kroah-Hartman <[email protected]> wrote:
>
> > This reverts commit ae0b3773721f08526c850e2d8dec85bdb870cd12.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Jonathan Cameron <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> Checked. Original fix was correct. As with others I don't mind how we handle
> this. Can either drop the revert, or bring it back later.
I'll drop the revert now, thanks for the review!
greg k-h
On Thu, Apr 22, 2021 at 06:47:20AM +0000, Richard Genoud wrote:
>
>
> Le 22/04/2021 ? 07:18, Jiri Slaby a ?crit?:
> > On 21. 04. 21, 14:59, Greg Kroah-Hartman wrote:
> > > This reverts commit c85be041065c0be8bc48eda4c45e0319caf1d0e5.
> > >
> > > 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.
> > >
> > > Cc: Kangjie Lu <[email protected]>
> > > Cc: Richard Genoud <[email protected]>
> > > Cc: stable <[email protected]>
> > > Cc: Greg Kroah-Hartman <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > ---
> > > ? drivers/tty/serial/atmel_serial.c | 4 ----
> > > ? 1 file changed, 4 deletions(-)
> > >
> > > diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
> > > index a24e5c2b30bc..9786d8e5f04f 100644
> > > --- a/drivers/tty/serial/atmel_serial.c
> > > +++ b/drivers/tty/serial/atmel_serial.c
> > > @@ -1256,10 +1256,6 @@ static int atmel_prepare_rx_dma(struct uart_port *port)
> > > ?????????????????????? sg_dma_len(&atmel_port->sg_rx)/2,
> > > ?????????????????????? DMA_DEV_TO_MEM,
> > > ?????????????????????? DMA_PREP_INTERRUPT);
> > > -??? if (!desc) {
> > > -??????? dev_err(port->dev, "Preparing DMA cyclic failed\n");
> > > -??????? goto chan_err;
> > > -??? }
> >
> > I cannot find anything malicious in the original fix:
> > * port->dev is valid for dev_err
> > * dmaengine_prep_dma_cyclic returns NULL in case of error
> > * chan_err invokes atmel_release_rx_dma which undoes the previous initialization code.
> >
> > Hence a NACK from me for the revert.
>
> I agree with your NACK.
> Back at the time (march 2019), I reviewed the changed and asked for a 2nd version and
> I didn't found anything suspicious.
> But the more eyes, the better.
>
> cf http://lkml.iu.edu/hypermail/linux/kernel/1903.1/05858.html
Thanks for the review, now dropped.
greg k-h
On Thu, Apr 22, 2021 at 10:43:45AM +0530, Viresh Kumar wrote:
> On 21-04-21, 14:59, Greg Kroah-Hartman wrote:
> > This reverts commit b5af36e3e5aa074605a4d90a89dd8f714b30909b.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Vaibhav Agarwal <[email protected]>
> > Cc: Viresh Kumar <[email protected]>
> > Cc: Greg Kroah-Hartman <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/staging/greybus/audio_manager.c | 3 ---
> > 1 file changed, 3 deletions(-)
> >
> > diff --git a/drivers/staging/greybus/audio_manager.c b/drivers/staging/greybus/audio_manager.c
> > index 9a3f7c034ab4..7c7ca671876d 100644
> > --- a/drivers/staging/greybus/audio_manager.c
> > +++ b/drivers/staging/greybus/audio_manager.c
> > @@ -45,9 +45,6 @@ int gb_audio_manager_add(struct gb_audio_manager_module_descriptor *desc)
> > int err;
> >
> > id = ida_simple_get(&module_id, 0, 0, GFP_KERNEL);
> > - if (id < 0)
> > - return id;
> > -
> > err = gb_audio_manager_module_create(&module, manager_kset,
> > id, desc);
> > if (err) {
>
> FWIW, this patch was doing the right thing IMO. So we may not want to
> revert it.
Thanks for the review, I'll drop this revert.
greg k-h
On Thu, Apr 22, 2021 at 06:57:19AM +0200, Jiri Slaby wrote:
> On 21. 04. 21, 17:59, David Sterba wrote:
> > On Wed, Apr 21, 2021 at 02:59:41PM +0200, Greg Kroah-Hartman wrote:
> > > This reverts commit 1bbb1c318cd8a3a39e8c3e2e83d5e90542d6c3e3.
> > >
> > > 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.
> >
> > I've reviewed the patch at the time and now again with fresh eyes, but
> > it's IMO a valid fix that would have to be done the same way after
> > revert.
>
> ACK -- the same opinion here.
Thanks for the review from both of you, now dropped.
greg k-h
On Thu, Apr 22, 2021 at 07:03:55AM +0200, Jiri Slaby wrote:
> On 21. 04. 21, 14:59, Greg Kroah-Hartman wrote:
> > This reverts commit 6734330654dac550f12e932996b868c6d0dcb421.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: stable <[email protected]>
> > Cc: Greg Kroah-Hartman <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/tty/serial/mxs-auart.c | 4 ----
> > 1 file changed, 4 deletions(-)
> >
> > diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> > index f414d6acad69..edad6ebbdfd5 100644
> > --- a/drivers/tty/serial/mxs-auart.c
> > +++ b/drivers/tty/serial/mxs-auart.c
> > @@ -1644,10 +1644,6 @@ static int mxs_auart_probe(struct platform_device *pdev)
> > s->port.mapbase = r->start;
> > s->port.membase = ioremap(r->start, resource_size(r));
> > - if (!s->port.membase) {
> > - ret = -ENOMEM;
> > - goto out_disable_clks;
> > - }
>
> I don't think this needs to be reverted -- the original fix is correct.
>
Now dropped, thanks for the review!
greg k-h
On Wed, Apr 21, 2021 at 06:59:58PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 21, 2021 at 06:51:24PM +0200, Hans de Goede wrote:
> > Hi Greg,
> >
> > On 4/21/21 3:01 PM, Greg Kroah-Hartman wrote:
> > > This reverts commit bd23a7269834dc7c1f93e83535d16ebc44b75eba.
> > >
> > > 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.
> > >
> > > Cc: Wenwen Wang <[email protected]>
> > > Cc: Hans de Goede <[email protected]>
> > > Cc: Greg Kroah-Hartman <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >
> > Ugh what a mess (the whole umn.edu thing).
> >
> > I still remember reviewing this patch during its original submission
> > and I've reviewed it again this morning when you just send it out.
> >
> > And now after letting it sit for a bit I've reviewed it a third time
> > and it seems to do what it says on the label / in the original commit
> > msg; and if fixes a real, potentially security, issue.
> >
> > I'm not sure what the process is for "good" patches in the set
> > which you are reverting. I would prefer for this patch to be dropped
> > from the set of reveert. But I can also submit a revert of the revert(?)
> > once this set of reverts has been merged.
>
> If you have reviewed it, and think it should stay, I will drop the
> revert from my patch series. Other maintainers/reviewers have asked the
> same thing for their patches, which is fine.
>
> Anything that I do end up reverting, that was not reviewed, will be
> again reviewed by me and others to determine if it is "safe" to come
> back in at a later point in time.
>
> So thanks for the review, I'll drop this one.
Now dropped, thanks for the review.
greg k-h
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
> <[email protected]> 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
On Thu, Apr 22, 2021 at 01:16:01AM +0000, Al Viro wrote:
> On Wed, Apr 21, 2021 at 03:14:29PM -0000, Tavis Ormandy wrote:
> > On 2021-04-21, Greg Kroah-Hartman wrote:
> > > This reverts commit bd23a7269834dc7c1f93e83535d16ebc44b75eba.
> > >
> > > - *((struct vbg_ioctl_hdr *)buf) = hdr;
> > > - if (copy_from_user(buf + sizeof(hdr), (void *)arg + sizeof(hdr),
> > > - hdr.size_in - sizeof(hdr))) {
> > > + if (copy_from_user(buf, (void *)arg, hdr.size_in)) {
> > > ret = -EFAULT;
> > > goto out;
> > > }
> >
> > This one seems like a real bugfix, otherwise there's a double-fetch from
> > userspace, and a TOCTOU with the hdr fields that could cause a OOB read.
>
> ACK, except that typecasts in there are messy as hell. But that's,
> alas, consistent with the rest of the function...
>
> Patch itself is correct, and AFAICS Wenwen Wang <[email protected]>
> might be an innocent collateral damage from that mess - commits from that
> source appear to be fairly well-written.
I've dropped it from my tree now, thanks for the review.
greg k-h
On Wed, Apr 21, 2021 at 03:43:31PM +0200, Johannes Berg wrote:
> On Wed, 2021-04-21 at 12:59 +0000, Greg Kroah-Hartman wrote:
> > This reverts commit 6fc232db9e8cd50b9b83534de9cd91ace711b2d7.
>
> This commit was fine, though the commit log is misleading since there's
> no dereference yet, just a pointer calculation. I may not have seen that
> at the time, or have decided that the slight commit log inaccuracy
> didn't matter.
>
> I'm inclined towards keeping it, since it removed a BUG_ON(), but
> there's no reasonable scenario where somebody could end up calling this
> function with a NULL pointer.
I've dropped this revert from my tree now, thanks.
greg k-h
Hi,
On 4/26/21 7:08 PM, Greg Kroah-Hartman wrote:
> On Wed, Apr 21, 2021 at 06:59:58PM +0200, Greg Kroah-Hartman wrote:
>> On Wed, Apr 21, 2021 at 06:51:24PM +0200, Hans de Goede wrote:
>>> Hi Greg,
>>>
>>> On 4/21/21 3:01 PM, Greg Kroah-Hartman wrote:
>>>> This reverts commit bd23a7269834dc7c1f93e83535d16ebc44b75eba.
>>>>
>>>> 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.
>>>>
>>>> Cc: Wenwen Wang <[email protected]>
>>>> Cc: Hans de Goede <[email protected]>
>>>> Cc: Greg Kroah-Hartman <[email protected]>
>>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>>
>>> Ugh what a mess (the whole umn.edu thing).
>>>
>>> I still remember reviewing this patch during its original submission
>>> and I've reviewed it again this morning when you just send it out.
>>>
>>> And now after letting it sit for a bit I've reviewed it a third time
>>> and it seems to do what it says on the label / in the original commit
>>> msg; and if fixes a real, potentially security, issue.
>>>
>>> I'm not sure what the process is for "good" patches in the set
>>> which you are reverting. I would prefer for this patch to be dropped
>>> from the set of reveert. But I can also submit a revert of the revert(?)
>>> once this set of reverts has been merged.
>>
>> If you have reviewed it, and think it should stay, I will drop the
>> revert from my patch series. Other maintainers/reviewers have asked the
>> same thing for their patches, which is fine.
>>
>> Anything that I do end up reverting, that was not reviewed, will be
>> again reviewed by me and others to determine if it is "safe" to come
>> back in at a later point in time.
>>
>> So thanks for the review, I'll drop this one.
>
> Now dropped, thanks for the review.
Great, thank you.
Regards,
Hans
On Wed, Apr 21, 2021 at 02:59:30PM +0200, Greg Kroah-Hartman wrote:
>
>This reverts commit 765976285a8c8db3f0eb7f033829a899d0c2786e.
>
>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.
>
>Cc: Kangjie Lu <[email protected]>
>Cc: Kalle Valo <[email protected]>
>Signed-off-by: Greg Kroah-Hartman <[email protected]>
>---
> drivers/net/wireless/realtek/rtlwifi/base.c | 5 -----
> 1 file changed, 5 deletions(-)
>
>diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c b/drivers/net/wireless/realtek/rtlwifi/base.c
>index 6e8bd99e8911..1d067536889e 100644
>--- a/drivers/net/wireless/realtek/rtlwifi/base.c
>+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
>@@ -452,11 +452,6 @@ static void _rtl_init_deferred_work(struct ieee80211_hw *hw)
> /* <2> work queue */
> rtlpriv->works.hw = hw;
> rtlpriv->works.rtl_wq = alloc_workqueue("%s", 0, 0, rtlpriv->cfg->name);
>- if (unlikely(!rtlpriv->works.rtl_wq)) {
>- pr_err("Failed to allocate work queue\n");
>- return;
>- }
>-
>
Hey Greg!
If you're still working on this series, this patch looks to be a
legitimate fix for the potential NULL pointer.
However we should probably inform 'rtw_init_core()' of this failure in
addition to printing about it.
Do you want to apply this revert and I send a fix after this has made
its way through?
--
~Bryan
>
> INIT_DELAYED_WORK(&rtlpriv->works.watchdog_wq,
> rtl_watchdog_wq_callback);
> INIT_DELAYED_WORK(&rtlpriv->works.ips_nic_off_wq,
>--
>2.31.1
>
On Wed, Apr 21, 2021 at 02:58:55PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit d7a336d67ab5443a0ef14b8335d139e855e8a682.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: https
> Cc: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/staging/kpc2000/kpc_dma/fileops.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/staging/kpc2000/kpc_dma/fileops.c b/drivers/staging/kpc2000/kpc_dma/fileops.c
> index 10dcd6646b01..7fdad86044ca 100644
> --- a/drivers/staging/kpc2000/kpc_dma/fileops.c
> +++ b/drivers/staging/kpc2000/kpc_dma/fileops.c
> @@ -49,7 +49,9 @@ static int kpc_dma_transfer(struct dev_private_data *priv,
> u64 dma_addr;
> u64 user_ctl;
>
> + BUG_ON(priv == NULL);
> ldev = priv->ldev;
> + BUG_ON(ldev == NULL);
>
> acd = kzalloc(sizeof(*acd), GFP_KERNEL);
> if (!acd) {
> --
> 2.31.1
This one looks fine, I'm dropping it.
greg k-h
On Wed, Apr 21, 2021 at 03:00:36PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 73b69c01cc925d9c48e5b4f78e3d8b88c4e5b924.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Dan Carpenter <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/staging/rts5208/ms.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/staging/rts5208/ms.c b/drivers/staging/rts5208/ms.c
> index 9001570a8c94..37b60ba1bdfe 100644
> --- a/drivers/staging/rts5208/ms.c
> +++ b/drivers/staging/rts5208/ms.c
> @@ -1665,10 +1665,7 @@ static int ms_copy_page(struct rtsx_chip *chip, u16 old_blk, u16 new_blk,
> return STATUS_FAIL;
> }
>
> - retval = ms_read_extra_data(chip, old_blk, i, extra,
> - MS_EXTRA_SIZE);
> - if (retval != STATUS_SUCCESS)
> - return STATUS_FAIL;
> + ms_read_extra_data(chip, old_blk, i, extra, MS_EXTRA_SIZE);
>
> retval = ms_set_rw_reg_addr(chip, OVERWRITE_FLAG,
> MS_EXTRA_SIZE, SYSTEM_PARAM, 6);
> --
> 2.31.1
>
This one looks fine, I'm dropping it.
greg k-h
On Thu, Apr 22, 2021 at 06:03:53AM +1000, James Morris wrote:
> On Wed, 21 Apr 2021, Greg Kroah-Hartman wrote:
>
> > This reverts commit 2bb3207dbbd4d30e96dd0e1c8e013104193bd59c.
> >
> > 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.
> >
> > Cc: Wenwen Wang <[email protected]>
> > Cc: David S. Miller <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > net/ethtool/ioctl.c | 3 ---
> > 1 file changed, 3 deletions(-)
>
> The original patch looks valid and fixes a race.
Thanks for reviewing, now dropped.
greg k-h
On Thu, Apr 22, 2021 at 05:55:33AM +1000, James Morris wrote:
> On Wed, 21 Apr 2021, Greg Kroah-Hartman wrote:
>
> > This reverts commit c9318a3e0218bc9dacc25be46b9eec363259536f.
> >
> > 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.
> >
> > Cc: Wenwen Wang <[email protected]>
> > Cc: Adam Radford <[email protected]>
> > Cc: Martin K. Petersen <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> The original patch here looks valid and necessary.
>
> Please un-revert.
Now dropped, thanks for the review.
greg k-h
On Thu, Apr 22, 2021 at 06:06:59AM +1000, James Morris wrote:
> On Wed, 21 Apr 2021, Greg Kroah-Hartman wrote:
>
> > This reverts commit d656fe49e33df48ee6bc19e871f5862f49895c9e.
> >
> > 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.
> >
> > Cc: Wenwen Wang <[email protected]>
> > Cc: David S. Miller <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> The original patch looks valid and fixes a race.
Thanks for reviewing, now dropped.
greg k-h
On Wed, Apr 21, 2021 at 09:08:20PM +0300, Kalle Valo wrote:
> Greg Kroah-Hartman <[email protected]> writes:
>
> > This reverts commit 25bf943e4e7b47282bd86ae7d39e039217ebb007.
> >
> > 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.
> >
> > Cc: Qiushi Wu <[email protected]>
> > Cc: https
>
> Cc https looks wrong.
My script sucks, sorry about that, will fix up...
thanks,
greg k-h
On Wed, Apr 21, 2021 at 03:51:59PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 21, 2021 at 09:33:43AM -0400, Steven Rostedt wrote:
> > On Wed, 21 Apr 2021 09:29:19 -0400
> > Steven Rostedt <[email protected]> wrote:
> >
> > > Reviewed-by: Steven Rostedt (VMware) <[email protected]>
> >
> > Just to clear up any confusion about my tag above. It was a second review
> > of the original patch, not for the revert.
>
> Fair enough, I'll handle it, thanks!
Revert is now dropped from my tree, thanks for the review.
greg k-h
On Tue, Apr 27, 2021 at 01:21:49AM +0000, Bryan Brattlof wrote:
> On Wed, Apr 21, 2021 at 02:59:30PM +0200, Greg Kroah-Hartman wrote:
> >
> >This reverts commit 765976285a8c8db3f0eb7f033829a899d0c2786e.
> >
> >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.
> >
> >Cc: Kangjie Lu <[email protected]>
> >Cc: Kalle Valo <[email protected]>
> >Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >---
> > drivers/net/wireless/realtek/rtlwifi/base.c | 5 -----
> > 1 file changed, 5 deletions(-)
> >
> >diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c b/drivers/net/wireless/realtek/rtlwifi/base.c
> >index 6e8bd99e8911..1d067536889e 100644
> >--- a/drivers/net/wireless/realtek/rtlwifi/base.c
> >+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
> >@@ -452,11 +452,6 @@ static void _rtl_init_deferred_work(struct ieee80211_hw *hw)
> > /* <2> work queue */
> > rtlpriv->works.hw = hw;
> > rtlpriv->works.rtl_wq = alloc_workqueue("%s", 0, 0, rtlpriv->cfg->name);
> >- if (unlikely(!rtlpriv->works.rtl_wq)) {
> >- pr_err("Failed to allocate work queue\n");
> >- return;
> >- }
> >-
> >
>
> Hey Greg!
>
> If you're still working on this series, this patch looks to be a
> legitimate fix for the potential NULL pointer.
>
> However we should probably inform 'rtw_init_core()' of this failure in
> addition to printing about it.
>
> Do you want to apply this revert and I send a fix after this has made
> its way through?
I'll keep this revert as the "unlikely()" should never be used for
something trivial like this (the compiler and CPU does a better job),
and printing an error message also doesn't help much.
I'll fix this up with a "simpler" version that does this properly by
propagating the error backwards...
thanks,
greg k-h
On Fri, Apr 23, 2021 at 08:20:30AM -0600, Jens Axboe wrote:
> On 4/22/21 3:29 PM, Peter Rosin wrote:
> >> This reverts commit 093c48213ee37c3c3ff1cf5ac1aa2a9d8bc66017.
> >
> > The reverted patch looks fishy.
> >
> > gc.cd_info is kzalloc:ed on probe. In case probe fails after this allocation, the
> > memory is kfree:d but the variable is NOT zeroed out.
> >
> > AFAICT, the above leads to a double-free on exit by the added line.
> >
> > I believe gd.cd_info should be kfree:d on remove instead.
> >
> > However, might not gc.toc also be kfree:d twice for similar reasons?
> >
> > I could easily be mistaken.
>
> >From taking a quick look the other day, that's my conclusion too. I
> don't think the patch is correct, but I don't think the surrounding code
> is correct right now either.
Thanks for the review from both of you, I'll keep this commit in the
tree.
greg k-h
On Fri, Apr 23, 2021 at 09:04:09AM +0200, Krzysztof Kozlowski wrote:
> On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
> > This reverts commit 64157b2cb1940449e7df2670e85781c690266588.
> >
> > 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.
> >
> > Cc: Qiushi Wu <[email protected]>
> > Cc: Hans Verkuil <[email protected]>
> > Cc: Mauro Carvalho Chehab <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/media/platform/exynos4-is/mipi-csis.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
>
>
> This looks like a good commit but should be done now in a different way
> - using pm_runtime_resume_and_get(). Therefore I am fine with revert
> and I can submit later better fix.
Thanks for the review, I'll drop all 3 exynos4-is patches from this
series.
greg k-h
On Wed, Apr 21, 2021 at 05:43:45PM +0200, Robert Foss wrote:
> Hi Greg,
>
> Thanks for taking for preventing this type of abuse.
>
> On Wed, 21 Apr 2021 at 15:03, Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This reverts commit d0675b67b42eb4f1a840d1513b5b00f78312f833.
> >
> > 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.
> >
> > Cc: Qiushi Wu <[email protected]>
> > Cc: Hans Verkuil <[email protected]>
> > Cc: Mauro Carvalho Chehab <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
>
> I think this patch is good, NAK.
I'll drop this from the series, thank you for the review.
greg k-h
On Thu, Apr 22, 2021 at 09:21:13AM +0000, Fabrizio Castro wrote:
> Dear All,
>
> > From: Mauro Carvalho Chehab <[email protected]>
> > Sent: 22 April 2021 10:04
> > Subject: Re: [PATCH 073/190] Revert "media: rcar_drif: fix a memory
> > disclosure"
> >
> > Em Thu, 22 Apr 2021 09:29:36 +0200
> > Hans Verkuil <[email protected]> escreveu:
> >
> > > On 22/04/2021 08:57, Geert Uytterhoeven wrote:
> > > > Hi Laurent,
> > > >
> > > > On Wed, Apr 21, 2021 at 11:22 PM Laurent Pinchart
> > > > <[email protected]> wrote:
> > > >> On Wed, Apr 21, 2021 at 08:58:22PM +0200, Geert Uytterhoeven wrote:
> > > >>> On Wed, Apr 21, 2021 at 3:06 PM Greg Kroah-Hartman wrote:
> > > >>>> This reverts commit d39083234c60519724c6ed59509a2129fd2aed41.
> > > >>>>
> > > >>>> 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.
> > > >>>>
> > > >>>> Cc: Kangjie Lu <[email protected]>
> > > >>>> Cc: Geert Uytterhoeven <[email protected]>
> > > >>>> Cc: Hans Verkuil <[email protected]>
> > > >>>> Cc: Mauro Carvalho Chehab <[email protected]>
> > > >>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > >>>
> > > >>> Upon a second look, I still see nothing wrong with the original
> > commit.
> > > >>> However, as I'm no v4l expert, I'd like to defer to the experts for
> > final
> > > >>> judgement.
> > > >>
> > > >> It seems fine to me, but it also seems unneeded, as the V4L2 core
> > clears
> > > >> the whole f->fmt union before calling this operation. The revert will
> > > >> this improve performance very slightly.
> > > >
> > > > Hmm, that means very recent commit f12b81e47f48940a ("media: core
> > > > headers: fix kernel-doc warnings") is not fully correct, as it added
> > > > kerneldoc stating this is the responsibility of the driver:
> > > >
> > > > + * @reserved: drivers and applications must zero this array
> > >
> > > Actually, it is the V4L2 core used by the driver that zeroes this. So
> > > drivers don't need to do this, it's done for them. It used to be the
> > > responsibility of the driver itself, but this was all moved to the core
> > > framework a long time ago since, duh!, drivers always forgot this :-)
> > >
> > > >
> > > > Anyway, it doesn't look like this umn.edu patch introduced a bug.
> > >
> > > I haven't seen any bugs introduced by the media patches from umn.edu.
> >
> > Hi Greg,
> >
> > I also double-checked all media revert patches from:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
> > umn.edu-reverts
> >
> > currently on this patch:
> > 6f4747a872ad Revert "ethtool: fix a potential missing-check bug"
> >
> > That's a summary of what I found:
> >
> > All of those should be dropped from your tree:
> >
> > 84fdb5856edd Revert "media: si2165: fix a missing check of
> > return value"
> > 867043f2206e Revert "media: video-mux: fix null pointer
> > dereferences"
> > 78ae4b621297 Revert "media: cx231xx: replace BUG_ON with
> > recovery code"
> > 5be328a55817 Revert "media: saa7146: Avoid using BUG_ON as an
> > assertion"
> > 81ce83158d22 Revert "media: davinci/vpfe_capture.c: Avoid
> > BUG_ON for register failure"
> > 3319b39504b8 Revert "media: media/saa7146: fix incorrect
> > assertion in saa7146_buffer_finish"
> > b393f7cb29a2 Revert "media: rcar-vin: Fix a reference count
> > leak."
> > 197bc5d03682 Revert "media: rcar-vin: Fix a reference count
> > leak."
> > 2fd9cf68bbb6 Revert "media: rockchip/rga: Fix a reference count
> > leak."
> > d1e4614eca24 Revert "media: platform: fcp: Fix a reference
> > count leak."
> > 416e8a6ae07f Revert "media: camss: Fix a reference count leak."
> > 06b793ae497b Revert "media: s5p-mfc: Fix a reference count
> > leak"
> > 8f9fc14a7cc9 Revert "media: stm32-dcmi: Fix a reference count
> > leak"
> > 556e1f86ba24 Revert "media: ti-vpe: Fix a missing check and
> > reference count leak"
> > 5f5b1722ad0d Revert "media: exynos4-is: Fix a reference count
> > leak"
> > f4c758c6c1cb Revert "media: exynos4-is: Fix a reference count
> > leak due to pm_runtime_get_sync"
> > beb717878c73 Revert "media: exynos4-is: Fix several reference
> > count leaks due to pm_runtime_get_sync
> > 7066ec748bfd Revert "media: sti: Fix reference count leaks"
> > cdd117093b19 Revert "media: st-delta: Fix reference count leak
> > in delta_run_work"
> >
> > As, after my re-check, they all seem to be addressing real issues. So,
> > NACK on those.
> >
> > This patch (073/190):
> >
> > 899ab4671bc0 Revert "media: rcar_drif: fix a memory disclosure"
> >
> > While it doesn't hurt, it is useless, as the media core already
> > prevents memory disclosure. So, it should be reverted.
> >
> > So, for patch 073/190:
> >
> > Reviewed-by: Mauro Carvalho Chehab <[email protected]>
>
> I agree, this patch should be reverted.
>
> Reviewed-by: Fabrizio Castro <[email protected]>
Thanks for the review, I've now dropped the media patches listed above,
and kept this one and added both of your r-b to it.
greg k-h
On Thu, Apr 22, 2021 at 10:10:50AM +0200, Hans Verkuil wrote:
> On 21/04/2021 14:58, Greg Kroah-Hartman wrote:
> > This reverts commit 7dae2aaaf432767ca7aa11fa84643a7c2600dbdd.
> >
> > 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.
> >
> > Cc: Qiushi Wu <[email protected]>
> > Cc: Hans Verkuil <[email protected]>
> > Cc: Mauro Carvalho Chehab <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/media/platform/ti-vpe/vpe.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/media/platform/ti-vpe/vpe.c b/drivers/media/platform/ti-vpe/vpe.c
> > index 10251b787674..c7a0a7c19ca6 100644
> > --- a/drivers/media/platform/ti-vpe/vpe.c
> > +++ b/drivers/media/platform/ti-vpe/vpe.c
> > @@ -2473,8 +2473,6 @@ static int vpe_runtime_get(struct platform_device *pdev)
> >
> > r = pm_runtime_get_sync(&pdev->dev);
> > WARN_ON(r < 0);
> > - if (r)
>
> This should have been: if (r < 0)
>
> I missed that as a reviewer, and I don't think it was intentional either
> since I couldn't find any clear documentation in pm_runtime_get_sync()
> that it can return 0 or 1 as success. After going through a few wrapper
> functions you end up in rpm_resume() in drivers/base/power/runtime.c
> which doesn't document the return code.
>
> So keep this reverted and I'll make a new patch for this later.
>
> I've CC-ed Rafael and Pavel: it would be really nice if someone can
> document the return code from rpm_resume() in drivers/base/power/runtime.c.
>
> I just discovered that it is documented in Documentation/power/runtime_pm.rst,
> but if you just look at the code then you'll miss this.
Mauro asked for me to drop this one, as he's fixing them all up in a
"better" way with a follow-on patch series.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 03:00:58PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit a26ac6c1bed951b2066cc4b2257facd919e35c0b.
>
> 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.
>
> Cc: Wenwen Wang <[email protected]>
> Cc: Hans Verkuil <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/media/platform/davinci/isif.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/isif.c b/drivers/media/platform/davinci/isif.c
> index c53cecd072b1..5355a14c090b 100644
> --- a/drivers/media/platform/davinci/isif.c
> +++ b/drivers/media/platform/davinci/isif.c
> @@ -1086,8 +1086,7 @@ static int isif_probe(struct platform_device *pdev)
>
> while (i >= 0) {
> res = platform_get_resource(pdev, IORESOURCE_MEM, i);
> - if (res)
> - release_mem_region(res->start, resource_size(res));
> + release_mem_region(res->start, resource_size(res));
> i--;
> }
> vpfe_unregister_ccdc_device(&isif_hw_dev);
> --
> 2.31.1
>
This looks correct, dropping it.
greg k-h
On Wed, Apr 21, 2021 at 03:00:27PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 5b711870bec4dc9a6d705d41e127e73944fa3650.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/media/usb/gspca/cpia1.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/media/usb/gspca/cpia1.c b/drivers/media/usb/gspca/cpia1.c
> index a4f7431486f3..d93d384286c1 100644
> --- a/drivers/media/usb/gspca/cpia1.c
> +++ b/drivers/media/usb/gspca/cpia1.c
> @@ -1424,7 +1424,6 @@ static int sd_config(struct gspca_dev *gspca_dev,
> {
> struct sd *sd = (struct sd *) gspca_dev;
> struct cam *cam;
> - int ret;
>
> sd->mainsFreq = FREQ_DEF == V4L2_CID_POWER_LINE_FREQUENCY_60HZ;
> reset_camera_params(gspca_dev);
> @@ -1436,10 +1435,7 @@ static int sd_config(struct gspca_dev *gspca_dev,
> cam->cam_mode = mode;
> cam->nmodes = ARRAY_SIZE(mode);
>
> - ret = goto_low_power(gspca_dev);
> - if (ret)
> - gspca_err(gspca_dev, "Cannot go to low power mode: %d\n",
> - ret);
> + goto_low_power(gspca_dev);
> /* Check the firmware version. */
> sd->params.version.firmwareVersion = 0;
> get_version_information(gspca_dev);
> --
> 2.31.1
>
The original commit here did nothing useful, so I am going to keep this
revert.
greg k-h
On Wed, Apr 21, 2021 at 03:00:25PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 656025850074f5c1ba2e05be37bda57ba2b8d491.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/media/usb/gspca/m5602/m5602_mt9m111.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/usb/gspca/m5602/m5602_mt9m111.c b/drivers/media/usb/gspca/m5602/m5602_mt9m111.c
> index bfa3b381d8a2..50481dc928d0 100644
> --- a/drivers/media/usb/gspca/m5602/m5602_mt9m111.c
> +++ b/drivers/media/usb/gspca/m5602/m5602_mt9m111.c
> @@ -195,7 +195,7 @@ static const struct v4l2_ctrl_config mt9m111_greenbal_cfg = {
> int mt9m111_probe(struct sd *sd)
> {
> u8 data[2] = {0x00, 0x00};
> - int i, rc = 0;
> + int i;
> struct gspca_dev *gspca_dev = (struct gspca_dev *)sd;
>
> if (force_sensor) {
> @@ -213,18 +213,16 @@ int mt9m111_probe(struct sd *sd)
> /* Do the preinit */
> for (i = 0; i < ARRAY_SIZE(preinit_mt9m111); i++) {
> if (preinit_mt9m111[i][0] == BRIDGE) {
> - rc |= m5602_write_bridge(sd,
> + m5602_write_bridge(sd,
> preinit_mt9m111[i][1],
> preinit_mt9m111[i][2]);
> } else {
> data[0] = preinit_mt9m111[i][2];
> data[1] = preinit_mt9m111[i][3];
> - rc |= m5602_write_sensor(sd,
> + m5602_write_sensor(sd,
> preinit_mt9m111[i][1], data, 2);
> }
> }
> - if (rc < 0)
> - return rc;
>
> if (m5602_read_sensor(sd, MT9M111_SC_CHIPVER, data, 2))
> return -ENODEV;
> --
> 2.31.1
>
Same here, OR error values together is not ok, keeping this revert.
greg k-h
On Wed, Apr 21, 2021 at 03:00:28PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 5ceaf5452c1b2a452dadaf377f9f07af7bda9cc3.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/media/usb/gspca/cpia1.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/usb/gspca/cpia1.c b/drivers/media/usb/gspca/cpia1.c
> index d93d384286c1..99e594559a0c 100644
> --- a/drivers/media/usb/gspca/cpia1.c
> +++ b/drivers/media/usb/gspca/cpia1.c
> @@ -537,14 +537,10 @@ static int do_command(struct gspca_dev *gspca_dev, u16 command,
> }
> if (sd->params.qx3.button) {
> /* button pressed - unlock the latch */
> - ret = do_command(gspca_dev, CPIA_COMMAND_WriteMCPort,
> + do_command(gspca_dev, CPIA_COMMAND_WriteMCPort,
> 3, 0xdf, 0xdf, 0);
> - if (ret)
> - return ret;
> - ret = do_command(gspca_dev, CPIA_COMMAND_WriteMCPort,
> + do_command(gspca_dev, CPIA_COMMAND_WriteMCPort,
> 3, 0xff, 0xff, 0);
> - if (ret)
> - return ret;
> }
>
> /* test whether microscope is cradled */
> --
> 2.31.1
>
This looks correct, I'll drop the revert.
But ick, recursion? What could go wrong....
greg k-h
On Wed, Apr 21, 2021 at 03:00:23PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 9502cdf0807058a10029488052b064cecceb7fc9.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Matthias Schwarzott <[email protected]>
> Cc: Sean Young <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/media/dvb-frontends/mt312.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/mt312.c b/drivers/media/dvb-frontends/mt312.c
> index d43a67045dbe..1dc6adefb8fe 100644
> --- a/drivers/media/dvb-frontends/mt312.c
> +++ b/drivers/media/dvb-frontends/mt312.c
> @@ -627,9 +627,7 @@ static int mt312_set_frontend(struct dvb_frontend *fe)
> if (ret < 0)
> return ret;
>
> - ret = mt312_reset(state, 0);
> - if (ret < 0)
> - return ret;
> + mt312_reset(state, 0);
>
> return 0;
> }
> --
> 2.31.1
>
This could have been made much simpler:
return mt312_reset(state, 0);
but as-is, is fine, I'll drop this revert.
greg k-h
On Wed, Apr 21, 2021 at 03:00:24PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit c9b7d8f252a5a6f8ca6e948151367cbc7bc4b776.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Sean Young <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/media/dvb-frontends/lgdt3306a.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/lgdt3306a.c b/drivers/media/dvb-frontends/lgdt3306a.c
> index 722576f1732a..f34263a33ede 100644
> --- a/drivers/media/dvb-frontends/lgdt3306a.c
> +++ b/drivers/media/dvb-frontends/lgdt3306a.c
> @@ -1690,10 +1690,7 @@ static int lgdt3306a_read_signal_strength(struct dvb_frontend *fe,
> case QAM_256:
> case QAM_AUTO:
> /* need to know actual modulation to set proper SNR baseline */
> - ret = lgdt3306a_read_reg(state, 0x00a6, &val);
> - if (lg_chkerr(ret))
> - goto fail;
> -
> + lgdt3306a_read_reg(state, 0x00a6, &val);
> if(val & 0x04)
> ref_snr = 2800; /* QAM-256 28dB */
> else
> --
> 2.31.1
>
Odd that this was the only fixup for this file, for this specific issue,
there are other places in this driver that this same change is needed.
That shows someone is not actually using a sane tool to create these :(
But it's ok as-is, I'll drop the revert.
greg k-h
On Wed, Apr 21, 2021 at 03:00:21PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 467a37fba93f2b4fe3ab597ff6a517b22b566882.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Sean Young <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/media/dvb-frontends/sp8870.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/sp8870.c b/drivers/media/dvb-frontends/sp8870.c
> index 655db8272268..ee893a2f2261 100644
> --- a/drivers/media/dvb-frontends/sp8870.c
> +++ b/drivers/media/dvb-frontends/sp8870.c
> @@ -280,9 +280,7 @@ static int sp8870_set_frontend_parameters(struct dvb_frontend *fe)
> sp8870_writereg(state, 0xc05, reg0xc05);
>
> // read status reg in order to clear pending irqs
> - err = sp8870_readreg(state, 0x200);
> - if (err)
> - return err;
> + sp8870_readreg(state, 0x200);
>
> // system controller start
> sp8870_microcontroller_start(state);
> --
> 2.31.1
>
This change looks to break the driver entirely, I guess no one uses it
anymore. It should have checked for < 0 if it actually cared about the
result.
I'll keep this as it is not correct.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 03:00:53PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit d134e486e831defd26130770181f01dfc6195f7d.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
> index 08f9477d2ee8..32b9e28dda16 100644
> --- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
> +++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
> @@ -1107,8 +1107,7 @@ netxen_validate_firmware(struct netxen_adapter *adapter)
> return -EINVAL;
> }
> val = nx_get_bios_version(adapter);
> - if (netxen_rom_fast_read(adapter, NX_BIOS_VERSION_OFFSET, (int *)&bios))
> - return -EIO;
> + netxen_rom_fast_read(adapter, NX_BIOS_VERSION_OFFSET, (int *)&bios);
> if ((__force u32)val != bios) {
> dev_err(&pdev->dev, "%s: firmware bios is incompatible\n",
> fw_name[fw_type]);
> --
> 2.31.1
>
This change, while messy and could be better, is semi-sane so I'll drop
it from my series.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 03:23:06PM +0200, Stefan Schmidt wrote:
> Hello.
>
> On 21.04.21 14:59, Greg Kroah-Hartman wrote:
> > This reverts commit 22e8860cf8f777fbf6a83f2fb7127f682a8e9de4.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Mukesh Ojha <[email protected]>
> > Cc: Stefan Schmidt <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/net/ieee802154/mcr20a.c | 6 ------
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
> > index 8dc04e2590b1..2ce5b41983f8 100644
> > --- a/drivers/net/ieee802154/mcr20a.c
> > +++ b/drivers/net/ieee802154/mcr20a.c
> > @@ -524,8 +524,6 @@ mcr20a_start(struct ieee802154_hw *hw)
> > dev_dbg(printdev(lp), "no slotted operation\n");
> > ret = regmap_update_bits(lp->regmap_dar, DAR_PHY_CTRL1,
> > DAR_PHY_CTRL1_SLOTTED, 0x0);
> > - if (ret < 0)
> > - return ret;
> > /* enable irq */
> > enable_irq(lp->spi->irq);
> > @@ -533,15 +531,11 @@ mcr20a_start(struct ieee802154_hw *hw)
> > /* Unmask SEQ interrupt */
> > ret = regmap_update_bits(lp->regmap_dar, DAR_PHY_CTRL2,
> > DAR_PHY_CTRL2_SEQMSK, 0x0);
> > - if (ret < 0)
> > - return ret;
> > /* Start the RX sequence */
> > dev_dbg(printdev(lp), "start the RX sequence\n");
> > ret = regmap_update_bits(lp->regmap_dar, DAR_PHY_CTRL1,
> > DAR_PHY_CTRL1_XCVSEQ_MASK, MCR20A_XCVSEQ_RX);
> > - if (ret < 0)
> > - return ret;
> > return 0;
> > }
> >
>
>
> Acked-by: Stefan Schmidt <[email protected]>
Thanks for the review, but in re-reviewing this, I'll drop the revert as
it looks correct to me.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 04:08:05PM +0000, Deucher, Alexander wrote:
> [AMD Public Use]
>
> > -----Original Message-----
> > From: Greg Kroah-Hartman <[email protected]>
> > Sent: Wednesday, April 21, 2021 8:58 AM
> > To: [email protected]
> > Cc: Greg Kroah-Hartman <[email protected]>; Quan, Evan
> > <[email protected]>; Aditya Pakki <[email protected]>; Deucher,
> > Alexander <[email protected]>
> > Subject: [PATCH 022/190] Revert "drm/radeon: Fix reference count leaks
> > caused by pm_runtime_get_sync"
> >
> > This reverts commit 9fb10671011143d15b6b40d6d5fa9c52c57e9d63.
> >
> > 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.
> >
> > Cc: Evan Quan <[email protected]>
> > Cc: Aditya Pakki <[email protected]>
> > Cc: Alex Deucher <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> AFAICT, this patch is correct or at least does no harm. Handling of pm_runtime_get_sync() errors in the kernel seems to be inconsistent at best.
Thanks for the review, I'll drop this revert from the tree.
greg k-h
On Wed, Apr 21, 2021 at 04:07:14PM +0000, Deucher, Alexander wrote:
> [AMD Public Use]
>
> > -----Original Message-----
> > From: Greg Kroah-Hartman <[email protected]>
> > Sent: Wednesday, April 21, 2021 8:58 AM
> > To: [email protected]
> > Cc: Greg Kroah-Hartman <[email protected]>; Aditya Pakki
> > <[email protected]>; Deucher, Alexander
> > <[email protected]>
> > Subject: [PATCH 023/190] Revert "drm/radeon: fix multiple reference count
> > leak"
> >
> > This reverts commit 6f2e8acdb48ed166b65d47837c31b177460491ec.
> >
> > 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.
> >
> > Cc: Aditya Pakki <[email protected]>
> > Cc: Alex Deucher <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> AFAICT, this patch is correct or at least does no harm. Handling of pm_runtime_get_sync() errors in the kernel seems to be inconsistent at best.
Thanks for the review, now dropped.
greg k-h
On Wed, Apr 21, 2021 at 11:14:11AM -0400, Felix Kuehling wrote:
> On 2021-04-21 8:58 a.m., Greg Kroah-Hartman wrote:
> > This reverts commit 20eca0123a35305e38b344d571cf32768854168c.
> >
> > 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.
> >
> > Cc: Qiushi Wu <[email protected]>
> > Cc: Felix Kuehling <[email protected]>
> > Cc: Felix Kuehling <[email protected]>
> > Cc: Alex Deucher <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> As far as I can tell, this patch was correct and should not be reverted.
Thanks for the review, now dropped.
greg k-h
Hello Greg.
On 27.04.21 15:39, Greg Kroah-Hartman wrote:
> On Wed, Apr 21, 2021 at 03:23:06PM +0200, Stefan Schmidt wrote:
>> Hello.
>>
>> On 21.04.21 14:59, Greg Kroah-Hartman wrote:
>>> This reverts commit 22e8860cf8f777fbf6a83f2fb7127f682a8e9de4.
>>>
>>> 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.
>>>
>>> Cc: Kangjie Lu <[email protected]>
>>> Cc: Mukesh Ojha <[email protected]>
>>> Cc: Stefan Schmidt <[email protected]>
>>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>>> ---
>>> drivers/net/ieee802154/mcr20a.c | 6 ------
>>> 1 file changed, 6 deletions(-)
>>>
>>> diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
>>> index 8dc04e2590b1..2ce5b41983f8 100644
>>> --- a/drivers/net/ieee802154/mcr20a.c
>>> +++ b/drivers/net/ieee802154/mcr20a.c
>>> @@ -524,8 +524,6 @@ mcr20a_start(struct ieee802154_hw *hw)
>>> dev_dbg(printdev(lp), "no slotted operation\n");
>>> ret = regmap_update_bits(lp->regmap_dar, DAR_PHY_CTRL1,
>>> DAR_PHY_CTRL1_SLOTTED, 0x0);
>>> - if (ret < 0)
>>> - return ret;
>>> /* enable irq */
>>> enable_irq(lp->spi->irq);
>>> @@ -533,15 +531,11 @@ mcr20a_start(struct ieee802154_hw *hw)
>>> /* Unmask SEQ interrupt */
>>> ret = regmap_update_bits(lp->regmap_dar, DAR_PHY_CTRL2,
>>> DAR_PHY_CTRL2_SEQMSK, 0x0);
>>> - if (ret < 0)
>>> - return ret;
>>> /* Start the RX sequence */
>>> dev_dbg(printdev(lp), "start the RX sequence\n");
>>> ret = regmap_update_bits(lp->regmap_dar, DAR_PHY_CTRL1,
>>> DAR_PHY_CTRL1_XCVSEQ_MASK, MCR20A_XCVSEQ_RX);
>>> - if (ret < 0)
>>> - return ret;
>>> return 0;
>>> }
>>>
>>
>>
>> Acked-by: Stefan Schmidt <[email protected]>
>
> Thanks for the review, but in re-reviewing this, I'll drop the revert as
> it looks correct to me.
It is correct. We missed the return checking when the driver came in
initially.
My Acked-by was really not about if the reverted patch was a security
risk, but about the fact that you wanted to sort them out individually
due to the Hypocrite Commits paper before getting them back in.
If you are happy to change the approach to only revert patches you are
in doubt (this one is really not one of them) I am happy to keep this
patch in.
regards
Stefan Schmidt
On Thu, Apr 22, 2021 at 07:28:51AM +0200, Jiri Slaby wrote:
> On 21. 04. 21, 15:00, Greg Kroah-Hartman wrote:
> > This reverts commit 51f689cc11333944c7a457f25ec75fcb41e99410.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Greg Kroah-Hartman <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/tty/serial/max310x.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
> > index 1b61d26bb7af..93f69b66b896 100644
> > --- a/drivers/tty/serial/max310x.c
> > +++ b/drivers/tty/serial/max310x.c
> > @@ -1518,10 +1518,10 @@ static int __init max310x_uart_init(void)
> > return ret;
> > #ifdef CONFIG_SPI_MASTER
> > - ret = spi_register_driver(&max310x_spi_driver);
> > + spi_register_driver(&max310x_spi_driver);
> > #endif
> > - return ret;
> > + return 0;
>
> ACK, uart_unregister_driver() is missing in case of error at least.
Many thanks for the review of the two serial driver changes in this
series, I've updated the changelog with the information and added your
acks.
greg k-h
On Wed, Apr 21, 2021 at 06:13:27PM +0200, Takashi Iwai wrote:
> On Wed, 21 Apr 2021 14:59:15 +0200,
> Greg Kroah-Hartman wrote:
> >
> > This reverts commit cbb88db76a1536e02e93e5bd37ebbfbb6c4043a9.
> >
> > 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.
> >
> > Cc: Wenwen Wang <[email protected]>
> > Cc: Takashi Iwai <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> I examined the change again, and confirmed that this code change
> itself is correct, so it's not necessary to revert.
>
> OTOH, it's just a tip of iceberg in this driver, and maybe it's better
> to cover all in a better way. So it's fine to revert this, either.
I'll drop the revert, many thanks for the review.
greg k-h
On Wed, Apr 21, 2021 at 05:30:23PM +0100, David Howells wrote:
> Greg Kroah-Hartman <[email protected]> wrote:
>
> > This reverts commit f45d01f4f30b53c3a0a1c6c1c154acb7ff74ab9f.
> >
> > 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.
> >
> > Cc: Qiushi Wu <[email protected]>
> > Cc: David Howells <[email protected]>
> > Cc: Markus Elfring <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> This is actually a good patch, so please don't revert it.
Now dropped from my series, thanks!
greg k-h
On Wed, Apr 21, 2021 at 06:23:19PM +0200, Takashi Iwai wrote:
> On Wed, 21 Apr 2021 15:00:05 +0200,
> Greg Kroah-Hartman wrote:
> >
> > This reverts commit a2c6433ee5a35a8de6d563f6512a26f87835ea0f.
> >
> > 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.
> >
> > Cc: Aditya Pakki <[email protected]>
> > Cc: Takashi Iwai <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> This is same like the revert#80, the code change itself seems correct,
> but it's a pretty minor error path, probably no one would hit.
> So, feel free to revert if it's in doubt.
>
>
> thanks,
>
> Takashi
>
> > ---
> > sound/usb/usx2y/usb_stream.c | 5 -----
> > 1 file changed, 5 deletions(-)
> >
> > diff --git a/sound/usb/usx2y/usb_stream.c b/sound/usb/usx2y/usb_stream.c
> > index 091c071b270a..6bba17bf689a 100644
> > --- a/sound/usb/usx2y/usb_stream.c
> > +++ b/sound/usb/usx2y/usb_stream.c
> > @@ -91,12 +91,7 @@ static int init_urbs(struct usb_stream_kernel *sk, unsigned use_packsize,
> >
> > for (u = 0; u < USB_STREAM_NURBS; ++u) {
> > sk->inurb[u] = usb_alloc_urb(sk->n_o_ps, GFP_KERNEL);
> > - if (!sk->inurb[u])
> > - return -ENOMEM;
> > -
> > sk->outurb[u] = usb_alloc_urb(sk->n_o_ps, GFP_KERNEL);
> > - if (!sk->outurb[u])
> > - return -ENOMEM;
This leaks memory if the error path is hit, so I'm going to keep this
revert as it it needs to be handled properly. And really, this code
path is impossible to hit...
thanks,
greg k-h
On Wed, Apr 21, 2021 at 06:21:26PM +0200, Takashi Iwai wrote:
> On Wed, 21 Apr 2021 15:00:02 +0200,
> Greg Kroah-Hartman wrote:
> >
> > This reverts commit dcd0feac9bab901d5739de51b3f69840851f8919.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Takashi Iwai <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> This code change itself looks OK, OTOH, the original commit message is
> slightly wrong: the code path can never result in NULL deference in
> this case, as it's just an optional resource reservation. So, it's
> safe to revert this.
Thanks for the review!
greg k-h
On Wed, Apr 21, 2021 at 06:26:24PM +0200, Takashi Iwai wrote:
> On Wed, 21 Apr 2021 15:00:33 +0200,
> Greg Kroah-Hartman wrote:
> >
> > This reverts commit beae77170c60aa786f3e4599c18ead2854d8694d.
> >
> > 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.
> >
> > Cc: Aditya Pakki <[email protected]>
> > Cc: Takashi Iwai <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> The original code change is fine, it's just adding an error return.
> OTOH, it would be safe even if we ignore the error, too (the mixer
> element is optional), and the driver is quite legacy.
> That said, feel free to revert it.
Thanks for the review, I'll keep it.
greg k-h
On Wed, Apr 21, 2021 at 06:30:07PM +0200, Takashi Iwai wrote:
> On Wed, 21 Apr 2021 15:01:02 +0200,
> Greg Kroah-Hartman wrote:
> >
> > This reverts commit 3f12888dfae2a48741c4caa9214885b3aaf350f9.
> >
> > 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.
> >
> > Cc: Wenwen Wang <[email protected]>
> > Cc: <[email protected]>
> > Cc: Takashi Iwai <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> This one is, unlike other patches I've been involved with, about the
> ALSA core code, and this change is likely worth to keep.
>
> The code change is correct, and even though it's really a minor issue,
> an optimization is right.
Thanks for the review, now dropped.
greg k-h
On 2021-04-27 15:01, Greg KH wrote:
> On Fri, Apr 23, 2021 at 08:20:30AM -0600, Jens Axboe wrote:
>> On 4/22/21 3:29 PM, Peter Rosin wrote:
>>>> This reverts commit 093c48213ee37c3c3ff1cf5ac1aa2a9d8bc66017.
>>>
>>> The reverted patch looks fishy.
>>>
>>> gc.cd_info is kzalloc:ed on probe. In case probe fails after this allocation, the
>>> memory is kfree:d but the variable is NOT zeroed out.
>>>
>>> AFAICT, the above leads to a double-free on exit by the added line.
>>>
>>> I believe gd.cd_info should be kfree:d on remove instead.
>>>
>>> However, might not gc.toc also be kfree:d twice for similar reasons?
>>>
>>> I could easily be mistaken.
>>
>> >From taking a quick look the other day, that's my conclusion too. I
>> don't think the patch is correct, but I don't think the surrounding code
>> is correct right now either.
>
> Thanks for the review from both of you, I'll keep this commit in the
> tree.
Err, which commit is "this" and what tree are you keeping it in? I
think you mean that you are keeping the revert in your tree with
reverts, and not that you mean that we should keep the original
commit in Linus' tree.
In any case, I'd think that the original memory leak is somewhat
better than the introduced double-free and therefore the revert
should be done.
Cheers,
Peter
On Tue, Apr 27, 2021 at 03:46:27PM +0200, Stefan Schmidt wrote:
> Hello Greg.
>
> On 27.04.21 15:39, Greg Kroah-Hartman wrote:
> > On Wed, Apr 21, 2021 at 03:23:06PM +0200, Stefan Schmidt wrote:
> > > Hello.
> > >
> > > On 21.04.21 14:59, Greg Kroah-Hartman wrote:
> > > > This reverts commit 22e8860cf8f777fbf6a83f2fb7127f682a8e9de4.
> > > >
> > > > 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.
> > > >
> > > > Cc: Kangjie Lu <[email protected]>
> > > > Cc: Mukesh Ojha <[email protected]>
> > > > Cc: Stefan Schmidt <[email protected]>
> > > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > > ---
> > > > drivers/net/ieee802154/mcr20a.c | 6 ------
> > > > 1 file changed, 6 deletions(-)
> > > >
> > > > diff --git a/drivers/net/ieee802154/mcr20a.c b/drivers/net/ieee802154/mcr20a.c
> > > > index 8dc04e2590b1..2ce5b41983f8 100644
> > > > --- a/drivers/net/ieee802154/mcr20a.c
> > > > +++ b/drivers/net/ieee802154/mcr20a.c
> > > > @@ -524,8 +524,6 @@ mcr20a_start(struct ieee802154_hw *hw)
> > > > dev_dbg(printdev(lp), "no slotted operation\n");
> > > > ret = regmap_update_bits(lp->regmap_dar, DAR_PHY_CTRL1,
> > > > DAR_PHY_CTRL1_SLOTTED, 0x0);
> > > > - if (ret < 0)
> > > > - return ret;
> > > > /* enable irq */
> > > > enable_irq(lp->spi->irq);
> > > > @@ -533,15 +531,11 @@ mcr20a_start(struct ieee802154_hw *hw)
> > > > /* Unmask SEQ interrupt */
> > > > ret = regmap_update_bits(lp->regmap_dar, DAR_PHY_CTRL2,
> > > > DAR_PHY_CTRL2_SEQMSK, 0x0);
> > > > - if (ret < 0)
> > > > - return ret;
> > > > /* Start the RX sequence */
> > > > dev_dbg(printdev(lp), "start the RX sequence\n");
> > > > ret = regmap_update_bits(lp->regmap_dar, DAR_PHY_CTRL1,
> > > > DAR_PHY_CTRL1_XCVSEQ_MASK, MCR20A_XCVSEQ_RX);
> > > > - if (ret < 0)
> > > > - return ret;
> > > > return 0;
> > > > }
> > > >
> > >
> > >
> > > Acked-by: Stefan Schmidt <[email protected]>
> >
> > Thanks for the review, but in re-reviewing this, I'll drop the revert as
> > it looks correct to me.
>
> It is correct. We missed the return checking when the driver came in
> initially.
>
> My Acked-by was really not about if the reverted patch was a security risk,
> but about the fact that you wanted to sort them out individually due to the
> Hypocrite Commits paper before getting them back in.
>
> If you are happy to change the approach to only revert patches you are in
> doubt (this one is really not one of them) I am happy to keep this patch in.
My first step was "revert them all so we know what to review", and now
I'm going back and reviewing them all (and taking the review comments
from everyone else who was nice enough to help out)"
So it's easy for me to drop this from the series now, thanks!
greg k-h
On Wed, Apr 21, 2021 at 03:39:47PM +0200, Johannes Berg wrote:
> On Wed, 2021-04-21 at 12:59 +0000, Greg Kroah-Hartman wrote:
> > This reverts commit 1ee7826ab68f7e9fa1a01533983acf6a6f62e297.
> >
>
> That commit was actually correct, though sort of irrelevant. I think we
> can go either way on it, but better not spend any (more) time on it.
I'll drop it, thanks!
greg k-h
On Wed, Apr 21, 2021 at 03:55:33PM +0200, Jan Kara wrote:
> On Wed 21-04-21 14:59:22, Greg Kroah-Hartman wrote:
> > This reverts commit 39416c5872db69859e867fa250b9cbb3f1e0d185.
> >
> > 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.
> >
> > Cc: Wenwen Wang <[email protected]>
> > Cc: Jan Kara <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> Hi Greg!
>
> I'm pretty confident this particular report & fix was valid (in fact it was
> me who suggested the particular change). So I don't see point in reverting
> it...
Thanks for letting me know, now dropped.
greg k-h
On Wed, Apr 21, 2021 at 05:51:01PM +0200, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Apr 21, 2021 at 02:58:46PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 1d7a7128a2e9e1f137c99b0a44e94d70a77343e3.
> >
> > 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.
> >
> > Cc: [email protected]
> > Cc: Qiushi Wu <[email protected]>
> > Cc: Sebastian Reichel <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
>
> Change is quite simple, so doing another review now:
>
> It is correct that power_supply_hwmon_bitmap_free() must be called
> when devm_add_action() fails. This is not already done in the error
> path, so the original patch is correct and the revert reintroduces a
> memory leak in error path.
>
> I suggest dropping the revert.
Now dropped, thanks!
greg k-h
On Wed, Apr 21, 2021 at 11:11:05AM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 21, 2021 at 02:58:23PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 90a239ee25fa3a483facec3de7c144361a3d3a51.
> >
> > 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.
> >
> > Cc: https
> > Cc: Aditya Pakki <[email protected]>
> > Cc: Dennis Dalessandro <[email protected]>
> > Cc: Jason Gunthorpe <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/infiniband/sw/rdmavt/qp.c | 6 ++----
> > 1 file changed, 2 insertions(+), 4 deletions(-)
>
> While I don't see anything obviously wrong here it is tricky enough
> that I would revert it unless Dennis says otherwise.
Thanks for the review, now dropped.
greg k-h
On Wed, Apr 21, 2021 at 11:07:00AM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 21, 2021 at 02:59:42PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit e2a438bd7116889af36304903b92e56d0f347228.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Shiraz, Saleem <[email protected]>
> > Cc: Jason Gunthorpe <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/infiniband/hw/i40iw/i40iw.h | 2 +-
> > drivers/infiniband/hw/i40iw/i40iw_cm.c | 18 +++---------------
> > drivers/infiniband/hw/i40iw/i40iw_main.c | 5 +----
> > 3 files changed, 5 insertions(+), 20 deletions(-)
>
> I don't see a reason to revert this one, the new code structure
> appears OK
Thanks, now dropped.
greg k-h
On Wed, Apr 21, 2021 at 09:05:44AM -0700, Bart Van Assche wrote:
> On 4/21/21 7:05 AM, Jason Gunthorpe wrote:
> > On Wed, Apr 21, 2021 at 11:02:47AM -0300, Jason Gunthorpe wrote:
> > > On Wed, Apr 21, 2021 at 02:58:54PM +0200, Greg Kroah-Hartman wrote:
> > > > This reverts commit 9f48db0d4a08624bb9ba847ea40c8abad753b396.
> > > >
> > > > 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.
> > > >
> > > > Cc: https
> > > > Cc: Aditya Pakki <[email protected]>
> > > > Cc: Bart Van Assche <[email protected]>
> > > > Cc: Jason Gunthorpe <[email protected]>
> > > > Cc: Jason Gunthorpe <[email protected]>
> > > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > > drivers/infiniband/ulp/srpt/ib_srpt.c | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > >
> > > I think this one is fine
> >
> > Sorry, I realize that is unclear. I mean I don't see a reason to
> > revert this patch.
>
> Greg, I share Jason's opinion and would like to see this revert dropped. The
> function srpt_queue_response() dereferences the 'ch' pointer before the
> BUG_ON(ch) statement is reached. I think this makes the BUG_ON() statement
> that would be reintroduced by this revert superfluous.
Thanks for the review, I will go drop this commit from my tree.
greg k-h
On Wed, Apr 21, 2021 at 12:25:17PM -0700, Roland Dreier wrote:
> This is a really weird one because the patch actually looks correct
> and the revert looks wrong??
>
> ret = pci_enable_device(pdev);
>
> [...dbg statements...]
>
> if (!(pci_resource_flags(pdev, 0) & IORESOURCE_MEM) ||
> !(pci_resource_flags(pdev, 1) & IORESOURCE_MEM)) {
> dev_err(&pdev->dev, "PCI BAR region not MMIO\n");
> ret = -ENOMEM;
> goto err_disable_pdev;
> }
>
> - R.
git revert sometimes does odd things :)
I'll go drop this from the tree, thanks.
greg k-h
On Wed, Apr 21, 2021 at 11:10:31AM -0300, Jason Gunthorpe wrote:
> On Wed, Apr 21, 2021 at 02:58:39PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit db857e6ae548f0f4f4a0f63fffeeedf3cca21f9d.
> >
> > 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.
> >
> > Cc: https
> > Cc: Qiushi Wu <[email protected]>
> > Cc: Jason Gunthorpe <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/infiniband/hw/vmw_pvrdma/pvrdma_main.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Can't see a reason to revert this one
thanks for the review, will drop this from my tree.
greg k-h
On Wed, Apr 21, 2021 at 07:45:34PM +0530, Devesh Sharma wrote:
> On Wed, Apr 21, 2021 at 7:38 PM Jason Gunthorpe <[email protected]> wrote:
> >
> > On Wed, Apr 21, 2021 at 03:00:41PM +0200, Greg Kroah-Hartman wrote:
> > > This reverts commit 94edd87a1c59f3efa6fdf4e98d6d492e6cec6173.
> > >
> > > 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.
> > >
> > > Cc: Aditya Pakki <[email protected]>
> > > Cc: Devesh Sharma <[email protected]>
> > > Cc: Jason Gunthorpe <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > ---
> > > drivers/infiniband/hw/bnxt_re/qplib_sp.c | 5 +++--
> > > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > Can't see a reason to revert this one, I re-checked the callers error
> > paths and it looks OK
> >
> > Jason
> Acked-By: Devesh Sharma <[email protected]>
Thanks for the review, I'll drop this as the original looks ok for now.
greg k-h
On Wed, Apr 21, 2021 at 03:00:14PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit d721fe99f6ada070ae8fc0ec3e01ce5a42def0d9.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/isdn/hardware/mISDN/mISDNinfineon.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/isdn/hardware/mISDN/mISDNinfineon.c b/drivers/isdn/hardware/mISDN/mISDNinfineon.c
> index a16c7a2a7f3d..fa9c491f9c38 100644
> --- a/drivers/isdn/hardware/mISDN/mISDNinfineon.c
> +++ b/drivers/isdn/hardware/mISDN/mISDNinfineon.c
> @@ -697,11 +697,8 @@ setup_io(struct inf_hw *hw)
> (ulong)hw->addr.start, (ulong)hw->addr.size);
> return err;
> }
> - if (hw->ci->addr_mode == AM_MEMIO) {
> + if (hw->ci->addr_mode == AM_MEMIO)
> hw->addr.p = ioremap(hw->addr.start, hw->addr.size);
> - if (unlikely(!hw->addr.p))
> - return -ENOMEM;
> - }
> hw->addr.mode = hw->ci->addr_mode;
> if (debug & DEBUG_HW)
> pr_notice("%s: IO addr %lx (%lu bytes) mode%d\n",
> --
> 2.31.1
>
This commit is wrong, so I will keep the revert. It should never have
used "unlikely()" and if it ever does trigger, resources are left
grabbed.
Given there are no users for this code around, I'll just revert this and
leave it "as is" as the odds that ioremap() will ever fail here is
horrendiously low.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 02:59:43PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 3de3dbe7c13210171ba8411e36b409a2c29c7415.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/usb/host/u132-hcd.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/usb/host/u132-hcd.c b/drivers/usb/host/u132-hcd.c
> index eb96e1e15b71..2b7bcbe2df4b 100644
> --- a/drivers/usb/host/u132-hcd.c
> +++ b/drivers/usb/host/u132-hcd.c
> @@ -3195,8 +3195,6 @@ static int __init u132_hcd_init(void)
> return -ENODEV;
> printk(KERN_INFO "driver %s\n", hcd_name);
> workqueue = create_singlethread_workqueue("u132");
> - if (!workqueue)
> - return -ENOMEM;
> retval = platform_driver_register(&u132_platform_driver);
> if (retval)
> destroy_workqueue(workqueue);
> --
> 2.31.1
>
This commit was correct, will drop this.
greg k-h
On Wed, Apr 21, 2021 at 03:00:15PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 38d22659803a033b1b66cd2624c33570c0dde77d.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/isdn/hardware/mISDN/hfcsusb.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c b/drivers/isdn/hardware/mISDN/hfcsusb.c
> index 70061991915a..4bb470d3963d 100644
> --- a/drivers/isdn/hardware/mISDN/hfcsusb.c
> +++ b/drivers/isdn/hardware/mISDN/hfcsusb.c
> @@ -249,9 +249,6 @@ hfcsusb_ph_info(struct hfcsusb *hw)
> int i;
>
> phi = kzalloc(struct_size(phi, bch, dch->dev.nrbchan), GFP_ATOMIC);
> - if (!phi)
> - return;
> -
> phi->dch.ch.protocol = hw->protocol;
> phi->dch.ch.Flags = dch->Flags;
> phi->dch.state = dch->state;
> --
> 2.31.1
>
While it looks like this commit is correct, it is not, as none of the
setup actually happens, and the error value is not propagated upwards.
So this is worse than the original code being that an atomic operation
can almost never fail, and if it did, a oops would be good here, instead
of failing to do something that the driver now claims has happened.
So I am keeping the revert.
greg k-h
On Wed, Apr 21, 2021 at 02:59:44PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 1a137b47ce6bd4f4b14662d2f5ace913ea7ffbf8.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Alan Stern <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/usb/storage/sierra_ms.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/storage/sierra_ms.c b/drivers/usb/storage/sierra_ms.c
> index b9f78ef3edc3..0f5c9cd8535f 100644
> --- a/drivers/usb/storage/sierra_ms.c
> +++ b/drivers/usb/storage/sierra_ms.c
> @@ -190,6 +190,8 @@ int sierra_ms_init(struct us_data *us)
> kfree(swocInfo);
> }
> complete:
> - return device_create_file(&us->pusb_intf->dev, &dev_attr_truinst);
> + result = device_create_file(&us->pusb_intf->dev, &dev_attr_truinst);
> +
> + return 0;
> }
>
> --
> 2.31.1
The original change here was correct, now dropping this patch.
greg k-h
>
On 4/27/21 8:03 AM, Peter Rosin wrote:
> On 2021-04-27 15:01, Greg KH wrote:
>> On Fri, Apr 23, 2021 at 08:20:30AM -0600, Jens Axboe wrote:
>>> On 4/22/21 3:29 PM, Peter Rosin wrote:
>>>>> This reverts commit 093c48213ee37c3c3ff1cf5ac1aa2a9d8bc66017.
>>>>
>>>> The reverted patch looks fishy.
>>>>
>>>> gc.cd_info is kzalloc:ed on probe. In case probe fails after this allocation, the
>>>> memory is kfree:d but the variable is NOT zeroed out.
>>>>
>>>> AFAICT, the above leads to a double-free on exit by the added line.
>>>>
>>>> I believe gd.cd_info should be kfree:d on remove instead.
>>>>
>>>> However, might not gc.toc also be kfree:d twice for similar reasons?
>>>>
>>>> I could easily be mistaken.
>>>
>>> >From taking a quick look the other day, that's my conclusion too. I
>>> don't think the patch is correct, but I don't think the surrounding code
>>> is correct right now either.
>>
>> Thanks for the review from both of you, I'll keep this commit in the
>> tree.
> Err, which commit is "this" and what tree are you keeping it in? I
> think you mean that you are keeping the revert in your tree with
> reverts, and not that you mean that we should keep the original
> commit in Linus' tree.
>
> In any case, I'd think that the original memory leak is somewhat
> better than the introduced double-free and therefore the revert
> should be done.
It should probably look like the below, though I doubt it matters
since only one device is supported anyway. As long as the free
happens post unregister, it likely won't make a difference. But
it is cleaner and easier to verify, and should double device support
ever be introduced, the existing code is buggy.
But given that, I don't think we should keep the revert patch.
diff --git a/drivers/cdrom/gdrom.c b/drivers/cdrom/gdrom.c
index 9874fc1c815b..02d369881165 100644
--- a/drivers/cdrom/gdrom.c
+++ b/drivers/cdrom/gdrom.c
@@ -831,6 +831,8 @@ static int remove_gdrom(struct platform_device *devptr)
if (gdrom_major)
unregister_blkdev(gdrom_major, GDROM_DEV_NAME);
unregister_cdrom(gd.cd_info);
+ kfree(gd.toc);
+ kfree(gd.cd_info);
return 0;
}
@@ -862,8 +864,6 @@ static void __exit exit_gdrom(void)
{
platform_device_unregister(pd);
platform_driver_unregister(&gdrom_driver);
- kfree(gd.toc);
- kfree(gd.cd_info);
}
module_init(init_gdrom);
--
Jens Axboe
On Wed, Apr 21, 2021 at 03:00:30PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 42daad3343be4a4e1ee03e30a5f5cc731dadfef5.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Kalle Valo <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
> index 586f4dfc638b..d2a803fc8ac6 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
> @@ -1586,10 +1586,6 @@ void brcmf_usb_exit(void)
>
> void brcmf_usb_register(void)
> {
> - int ret;
> -
> brcmf_dbg(USB, "Enter\n");
> - ret = usb_register(&brcmf_usbdrvr);
> - if (ret)
> - brcmf_err("usb_register failed %d\n", ret);
> + usb_register(&brcmf_usbdrvr);
> }
> --
> 2.31.1
>
This change was not ok, and did nothing to actually fix the root problem
here. I'll be keeping this revert and will fix it up "properly".
thanks,
greg k-h
On Wed, Apr 21, 2021 at 04:28:02PM +0200, Alexandre Belloni wrote:
> Hello,
>
> On 21/04/2021 15:00:17+0200, Greg Kroah-Hartman wrote:
> > This reverts commit 9a20b5e35a536d6bb4b2d4a3b14a0457e205356c.
> >
> > 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.
> >
>
> There is really nothing wrong in the patch, it was not completely useful
> but not wrong either.
Thanks for the review, I'll drop it.
greg k-h
On Wed, Apr 21, 2021 at 04:28:31PM +0200, Willy Tarreau wrote:
> On Wed, Apr 21, 2021 at 03:00:17PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 9a20b5e35a536d6bb4b2d4a3b14a0457e205356c.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Alexandre Belloni <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/rtc/rtc-hym8563.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/rtc/rtc-hym8563.c b/drivers/rtc/rtc-hym8563.c
> > index 0751cae27285..a9d033eff61e 100644
> > --- a/drivers/rtc/rtc-hym8563.c
> > +++ b/drivers/rtc/rtc-hym8563.c
> > @@ -94,8 +94,6 @@ static int hym8563_rtc_read_time(struct device *dev, struct rtc_time *tm)
> > int ret;
> >
> > ret = i2c_smbus_read_i2c_block_data(client, HYM8563_SEC, 7, buf);
> > - if (ret < 0)
> > - return ret;
> >
> > if (buf[0] & HYM8563_SEC_VL) {
> > dev_warn(&client->dev,
>
> Seems like this one was a valid fix, and that the description matched
> what was done; plenty of other drivers also proceed similarly. I suspect
> it should be kept.
Thanks for the review, I'll drop this revert from my tree.
greg k-h
On Wed, Apr 21, 2021 at 05:20:45PM +0200, Jiri Kosina wrote:
> On Wed, 21 Apr 2021, Greg Kroah-Hartman wrote:
>
> > This reverts commit 6c44b15e1c9076d925d5236ddadf1318b0a25ce2.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Jiri Kosina <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> This particular one doesn't have to be reverted, I have reviewed it again
> and it does fix an actual bug.
Thanks, I will drop the revert from my tree.
greg k-h
On Wed, Apr 21, 2021 at 02:58:35PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 4d8be4bc94f74bb7d096e1c2e44457b530d5a170.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: 4.10+ <[email protected]> # 4.10+
> Cc: Rafael J. Wysocki <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/acpi/cppc_acpi.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/acpi/cppc_acpi.c b/drivers/acpi/cppc_acpi.c
> index 69057fcd2c04..42650b34e45e 100644
> --- a/drivers/acpi/cppc_acpi.c
> +++ b/drivers/acpi/cppc_acpi.c
> @@ -830,7 +830,6 @@ int acpi_cppc_processor_probe(struct acpi_processor *pr)
> "acpi_cppc");
> if (ret) {
> per_cpu(cpc_desc_ptr, pr->id) = NULL;
> - kobject_put(&cpc_ptr->kobj);
> goto out_free;
> }
>
> --
> 2.31.1
>
The original change here looks correct, so I will drop this revert from
my tree.
greg k-h
On Wed, Apr 21, 2021 at 06:14:07PM +0200, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Apr 21, 2021 at 03:00:18PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 6f12e46eebf1a7d4fdd66df5e815df96b8f8b1b5.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Sebastian Reichel <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
>
> Doing another review:
>
> twl4030 is an I2C connected PMIC, so any read operation can
> result in -EIO. If this happens 's' will not be initialized,
> so without handling the error is_charging will be set to an
> arbitrary state in the following lines. Exiting early from
> twl4030_bci_get_property is ok and other HW read operation
> failures in the same function are exiting early with proper
> error code (as the patch introduced for the only read missing
> this).
>
> TL;DR: original patch is ok, I suggest to drop the revert.
Thanks for the review, now dropped.
greg k-h
On Wed, Apr 21, 2021 at 06:02:48PM +0200, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Apr 21, 2021 at 02:59:27PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 75cf4f5aa903604e1bd7bec2c0988d643c6fb946.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Sebastian Reichel <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
>
> Doing another review:
>
> create_freezable_workqueue can return NULL when allocations fails
> and it is the first call in late init call, so it's fine to just
> exit with -ENOMEM.
>
> I suggest to drop the revert.
Many thanks for doing the review, I have now dropped it.
greg k-h
On Wed, Apr 21, 2021 at 03:00:43PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 92ee77d148bf06d8c52664be4d1b862583fd5c0e.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 1767c60056c5..f1a70b37227f 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -7328,8 +7328,6 @@ static int mvpp2_probe(struct platform_device *pdev)
> if (has_acpi_companion(&pdev->dev)) {
> acpi_id = acpi_match_device(pdev->dev.driver->acpi_match_table,
> &pdev->dev);
> - if (!acpi_id)
> - return -EINVAL;
> priv->hw_version = (unsigned long)acpi_id->driver_data;
> } else {
> priv->hw_version =
> --
> 2.31.1
>
The original commit here looks correct, so I'll drop this revert.
greg k-h
On Wed, Apr 21, 2021 at 09:03:15AM -0700, Jakub Kicinski wrote:
> On Wed, 21 Apr 2021 14:58:45 +0200 Greg Kroah-Hartman wrote:
> > This reverts commit bd4af432cc71b5fbfe4833510359a6ad3ada250d.
> >
> > 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.
> >
> > Cc: Qiushi Wu <[email protected]>
> > Cc: Jakub Kicinski <[email protected]>
> > Cc: David S. Miller <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/net/ethernet/netronome/nfp/abm/main.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/netronome/nfp/abm/main.c b/drivers/net/ethernet/netronome/nfp/abm/main.c
> > index bdbf0726145e..341773b43a4d 100644
> > --- a/drivers/net/ethernet/netronome/nfp/abm/main.c
> > +++ b/drivers/net/ethernet/netronome/nfp/abm/main.c
> > @@ -283,7 +283,6 @@ nfp_abm_vnic_set_mac(struct nfp_pf *pf, struct nfp_abm *abm, struct nfp_net *nn,
> > if (!nfp_nsp_has_hwinfo_lookup(nsp)) {
> > nfp_warn(pf->cpp, "NSP doesn't support PF MAC generation\n");
> > eth_hw_addr_random(nn->dp.netdev);
> > - nfp_nsp_close(nsp);
> > return;
> > }
> >
>
> This one still looks correct to me :S
Thanks for the review, now dropped.
greg k-h
On Wed, Apr 21, 2021 at 11:13:29AM -0500, Tyler Hicks wrote:
> On 2021-04-21 16:04:02, Al Viro wrote:
> > On Wed, Apr 21, 2021 at 02:58:48PM +0200, Greg Kroah-Hartman wrote:
> > > This reverts commit 2c2a7552dd6465e8fde6bc9cccf8d66ed1c1eb72.
> > >
> > > 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.
> >
> > FWIW, commit message on the original (
> > ecryptfs: replace BUG_ON with error handling code
> >
> > In crypt_scatterlist, if the crypt_stat argument is not set up
> > correctly, the kernel crashes. Instead, by returning an error code
> > upstream, the error is handled safely.
> >
> > The issue is detected via a static analysis tool written by us.
> >
> > Fixes: 237fead619984 (ecryptfs: fs/Makefile and fs/Kconfig)
> > Signed-off-by: Aditya Pakki <[email protected]>
> > Signed-off-by: Tyler Hicks <[email protected]>
> > )
> > really stinks. First, the analysis: condition being tested is
> > (!crypt_stat || !crypt_stat->tfm
> > || !(crypt_stat->flags & ECRYPTFS_STRUCT_INITIALIZED))
> > and their patch replaces BUG_ON() with return of -EINVAL. So the
> > only thing their tool had detected the presence of BUG_ON().
> > Was it grep, by any chance?
> >
> > IOW, the commit message is "we'd found BUG_ON(); let's replace it
> > with returning some error value and hope everything works. Whaddya
> > mean, how do we know? Our tool [git grep BUG_ON, that is] says
> > it's there and look, it *is* there, so if it's ever reached there'll
> > be trouble. What, assertion that returning an error will be handled
> > safely? 'Cuz we saiz so, that's why"
> >
> >
> > It *is* functionally harmless, AFAICS, but only because the condition
> > is really impossible. However,
> > * it refers to vague (s)tool they'd produced, nevermind that
> > all they really do is "find BUG_ON(), replace with returning an error".
> > * unlike BUG_ON(), the replacement does *NOT* document the
> > fact that condition should be impossible.
> > IMO either should be sufficient for rejecting the patch.
>
> I agree that it was not a malicious change. There are other places
> within the same function that return -EINVAL and the expectation is that
> errors from this function should be handled safely.
>
> That said, I can find no real-world reports of this BUG_ON() ever being
> a problem and I don't think that there's any actual need for this
> change. So, I'm alright with it being reverted considering the
> circumstances.
>
> Acked-by: Tyler Hicks <[email protected]>
Thanks for the review, I've update the commit log message and added your
ack here.
greg k-h
On Wed, Apr 21, 2021 at 09:13:29PM -0500, Rob Herring wrote:
> On Wed, Apr 21, 2021 at 8:05 AM Greg Kroah-Hartman
> <[email protected]> wrote:
> >
> > This reverts commit 1d84353d205a953e2381044953b7fa31c8c9702d.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Aditya Pakki <[email protected]>
> > Cc: Finn Thain <[email protected]>
> > Cc: Rob Herring <[email protected]>
>
> Sigh, get_maintainers.pl likes to punish people for treewide clean-ups...
>
> > Cc: Greg Kroah-Hartman <[email protected]>
> > Cc: Bartlomiej Zolnierkiewicz <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/video/fbdev/imsttfb.c | 5 -----
> > 1 file changed, 5 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/imsttfb.c b/drivers/video/fbdev/imsttfb.c
> > index 3ac053b88495..e04411701ec8 100644
> > --- a/drivers/video/fbdev/imsttfb.c
> > +++ b/drivers/video/fbdev/imsttfb.c
> > @@ -1512,11 +1512,6 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> > info->fix.smem_start = addr;
> > info->screen_base = (__u8 *)ioremap(addr, par->ramdac == IBM ?
> > 0x400000 : 0x800000);
> > - if (!info->screen_base) {
> > - release_mem_region(addr, size);
> > - framebuffer_release(info);
> > - return -ENOMEM;
> > - }
>
> The original change appears to be valid, but incomplete...
>
> > info->fix.mmio_start = addr + 0x800000;
> > par->dc_regs = ioremap(addr + 0x800000, 0x1000);
>
> ...because what about cleanup when this ioremap fails.
>
> > par->cmap_regs_phys = addr + 0x840000;
>
> Then again, if anyone really cared about this driver and h/w (a
> PowerMac era PCI display card), it would not still be using fbdev and
> would use devm_* apis.
Thanks for the review, I've updated the changelog to reflect this mess :)
greg k-h
On Wed, Apr 21, 2021 at 02:59:33PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit ec7f6aad57ad29e4e66cc2e18e1e1599ddb02542.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Aditya Pakki <[email protected]>
> Cc: Ferenc Bakonyi <[email protected]>
> Cc: Bartlomiej Zolnierkiewicz <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/video/fbdev/hgafb.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/hgafb.c b/drivers/video/fbdev/hgafb.c
> index 8bbac7182ad3..fca29f219f8b 100644
> --- a/drivers/video/fbdev/hgafb.c
> +++ b/drivers/video/fbdev/hgafb.c
> @@ -285,8 +285,6 @@ static int hga_card_detect(void)
> hga_vram_len = 0x08000;
>
> hga_vram = ioremap(0xb0000, hga_vram_len);
> - if (!hga_vram)
> - goto error;
>
> if (request_region(0x3b0, 12, "hgafb"))
> release_io_ports = 1;
> --
> 2.31.1
>
This patch "looks" correct, but the driver keeps on running and will
fail horribly right afterward if this error condition ever trips.
So points for trying to resolve an issue, but a huge NEGATIVE value for
providing a "fake" fix for the problem as nothing actually got resolved
at all. I'll go fix this up properly...
{sigh}
greg k-h
On Tue, Apr 27, 2021 at 04:03:01PM +0200, Peter Rosin wrote:
> On 2021-04-27 15:01, Greg KH wrote:
> > On Fri, Apr 23, 2021 at 08:20:30AM -0600, Jens Axboe wrote:
> >> On 4/22/21 3:29 PM, Peter Rosin wrote:
> >>>> This reverts commit 093c48213ee37c3c3ff1cf5ac1aa2a9d8bc66017.
> >>>
> >>> The reverted patch looks fishy.
> >>>
> >>> gc.cd_info is kzalloc:ed on probe. In case probe fails after this allocation, the
> >>> memory is kfree:d but the variable is NOT zeroed out.
> >>>
> >>> AFAICT, the above leads to a double-free on exit by the added line.
> >>>
> >>> I believe gd.cd_info should be kfree:d on remove instead.
> >>>
> >>> However, might not gc.toc also be kfree:d twice for similar reasons?
> >>>
> >>> I could easily be mistaken.
> >>
> >> >From taking a quick look the other day, that's my conclusion too. I
> >> don't think the patch is correct, but I don't think the surrounding code
> >> is correct right now either.
> >
> > Thanks for the review from both of you, I'll keep this commit in the
> > tree.
> Err, which commit is "this" and what tree are you keeping it in? I
> think you mean that you are keeping the revert in your tree with
> reverts, and not that you mean that we should keep the original
> commit in Linus' tree.
That is correct, I will be keeping this revert in my tree.
> In any case, I'd think that the original memory leak is somewhat
> better than the introduced double-free and therefore the revert
> should be done.
Will do that.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 02:58:25PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit deca195383a6085be62cb453079e03e04d618d6e.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: Jon Hunter <[email protected]>
> Cc: https
> Cc: Mark Brown <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> sound/soc/tegra/tegra30_ahub.c | 4 +---
> sound/soc/tegra/tegra30_i2s.c | 4 +---
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/sound/soc/tegra/tegra30_ahub.c b/sound/soc/tegra/tegra30_ahub.c
> index 9ef05ca4f6c4..b116b05e4e72 100644
> --- a/sound/soc/tegra/tegra30_ahub.c
> +++ b/sound/soc/tegra/tegra30_ahub.c
> @@ -657,10 +657,8 @@ static int tegra30_ahub_resume(struct device *dev)
> int ret;
>
> ret = pm_runtime_get_sync(dev);
> - if (ret < 0) {
> - pm_runtime_put(dev);
> + if (ret < 0)
> return ret;
> - }
> ret = regcache_sync(ahub->regmap_ahub);
> ret |= regcache_sync(ahub->regmap_apbif);
> pm_runtime_put(dev);
> diff --git a/sound/soc/tegra/tegra30_i2s.c b/sound/soc/tegra/tegra30_i2s.c
> index 6740df541508..3187a0f0c07a 100644
> --- a/sound/soc/tegra/tegra30_i2s.c
> +++ b/sound/soc/tegra/tegra30_i2s.c
> @@ -567,10 +567,8 @@ static int tegra30_i2s_resume(struct device *dev)
> int ret;
>
> ret = pm_runtime_get_sync(dev);
> - if (ret < 0) {
> - pm_runtime_put(dev);
> + if (ret < 0)
> return ret;
> - }
> ret = regcache_sync(i2s->regmap);
> pm_runtime_put(dev);
>
> --
> 2.31.1
>
Looks correct, dropping.
greg k-h
On Tue, Apr 27, 2021 at 08:39:15AM -0600, Jens Axboe wrote:
> On 4/27/21 8:03 AM, Peter Rosin wrote:
> > On 2021-04-27 15:01, Greg KH wrote:
> >> On Fri, Apr 23, 2021 at 08:20:30AM -0600, Jens Axboe wrote:
> >>> On 4/22/21 3:29 PM, Peter Rosin wrote:
> >>>>> This reverts commit 093c48213ee37c3c3ff1cf5ac1aa2a9d8bc66017.
> >>>>
> >>>> The reverted patch looks fishy.
> >>>>
> >>>> gc.cd_info is kzalloc:ed on probe. In case probe fails after this allocation, the
> >>>> memory is kfree:d but the variable is NOT zeroed out.
> >>>>
> >>>> AFAICT, the above leads to a double-free on exit by the added line.
> >>>>
> >>>> I believe gd.cd_info should be kfree:d on remove instead.
> >>>>
> >>>> However, might not gc.toc also be kfree:d twice for similar reasons?
> >>>>
> >>>> I could easily be mistaken.
> >>>
> >>> >From taking a quick look the other day, that's my conclusion too. I
> >>> don't think the patch is correct, but I don't think the surrounding code
> >>> is correct right now either.
> >>
> >> Thanks for the review from both of you, I'll keep this commit in the
> >> tree.
> > Err, which commit is "this" and what tree are you keeping it in? I
> > think you mean that you are keeping the revert in your tree with
> > reverts, and not that you mean that we should keep the original
> > commit in Linus' tree.
> >
> > In any case, I'd think that the original memory leak is somewhat
> > better than the introduced double-free and therefore the revert
> > should be done.
>
> It should probably look like the below, though I doubt it matters
> since only one device is supported anyway. As long as the free
> happens post unregister, it likely won't make a difference. But
> it is cleaner and easier to verify, and should double device support
> ever be introduced, the existing code is buggy.
>
> But given that, I don't think we should keep the revert patch.
>
> diff --git a/drivers/cdrom/gdrom.c b/drivers/cdrom/gdrom.c
> index 9874fc1c815b..02d369881165 100644
> --- a/drivers/cdrom/gdrom.c
> +++ b/drivers/cdrom/gdrom.c
> @@ -831,6 +831,8 @@ static int remove_gdrom(struct platform_device *devptr)
> if (gdrom_major)
> unregister_blkdev(gdrom_major, GDROM_DEV_NAME);
> unregister_cdrom(gd.cd_info);
> + kfree(gd.toc);
> + kfree(gd.cd_info);
>
> return 0;
> }
> @@ -862,8 +864,6 @@ static void __exit exit_gdrom(void)
> {
> platform_device_unregister(pd);
> platform_driver_unregister(&gdrom_driver);
> - kfree(gd.toc);
> - kfree(gd.cd_info);
> }
>
> module_init(init_gdrom);
>
> --
> Jens Axboe
>
I'll add this fix to the tree after the revert, and give you the credit
for the fix :)
thanks,
greg k-h
On Wed, Apr 21, 2021 at 02:58:27PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 6b9fbb073636906eee9fe4d4c05a4f445b9e2a23.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: https
> Cc: Mark Brown <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> sound/soc/img/img-parallel-out.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/sound/soc/img/img-parallel-out.c b/sound/soc/img/img-parallel-out.c
> index 4da49a42e854..5ddbe3a31c2e 100644
> --- a/sound/soc/img/img-parallel-out.c
> +++ b/sound/soc/img/img-parallel-out.c
> @@ -163,10 +163,8 @@ static int img_prl_out_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
> }
>
> ret = pm_runtime_get_sync(prl->dev);
> - if (ret < 0) {
> - pm_runtime_put_noidle(prl->dev);
> + if (ret < 0)
> return ret;
> - }
>
> reg = img_prl_out_readl(prl, IMG_PRL_OUT_CTL);
> reg = (reg & ~IMG_PRL_OUT_CTL_EDGE_MASK) | control_set;
> --
> 2.31.1
>
Looks correct, dropping.
On Wed, Apr 21, 2021 at 02:58:12PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit a2cdf39536b0d21fb06113f5e16692513d7bcb9c.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Ben Skeggs <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index 1c9c0cdf85db..8ae298ab1cfb 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -2320,10 +2320,8 @@ nv50_disp_atomic_commit(struct drm_device *dev,
> int ret, i;
>
> ret = pm_runtime_get_sync(dev->dev);
> - if (ret < 0 && ret != -EACCES) {
> - pm_runtime_put_autosuspend(dev->dev);
> + if (ret < 0 && ret != -EACCES)
> return ret;
> - }
>
> ret = drm_atomic_helper_setup_commit(state, nonblock);
> if (ret)
> --
> 2.31.1
>
Looks correct, dropping this.
greg k-h
On Wed, Apr 21, 2021 at 02:58:28PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit c4c59b95b7f7d4cef5071b151be2dadb33f3287b.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: https
> Cc: Mark Brown <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> sound/soc/img/img-i2s-in.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/sound/soc/img/img-i2s-in.c b/sound/soc/img/img-i2s-in.c
> index 0843235d73c9..e30b66b94bf6 100644
> --- a/sound/soc/img/img-i2s-in.c
> +++ b/sound/soc/img/img-i2s-in.c
> @@ -343,10 +343,8 @@ static int img_i2s_in_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
> chan_control_mask = IMG_I2S_IN_CH_CTL_CLK_TRANS_MASK;
>
> ret = pm_runtime_get_sync(i2s->dev);
> - if (ret < 0) {
> - pm_runtime_put_noidle(i2s->dev);
> + if (ret < 0)
> return ret;
> - }
>
> for (i = 0; i < i2s->active_channels; i++)
> img_i2s_in_ch_disable(i2s, i);
> --
> 2.31.1
>
Looks correct, dropping.
greg k-h
On Wed, Apr 21, 2021 at 02:58:37PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 25bf943e4e7b47282bd86ae7d39e039217ebb007.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: https
> Cc: Mark Brown <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> sound/soc/img/img-i2s-in.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/sound/soc/img/img-i2s-in.c b/sound/soc/img/img-i2s-in.c
> index e30b66b94bf6..a495d1050d49 100644
> --- a/sound/soc/img/img-i2s-in.c
> +++ b/sound/soc/img/img-i2s-in.c
> @@ -482,7 +482,6 @@ static int img_i2s_in_probe(struct platform_device *pdev)
> if (IS_ERR(rst)) {
> if (PTR_ERR(rst) == -EPROBE_DEFER) {
> ret = -EPROBE_DEFER;
> - pm_runtime_put(&pdev->dev);
> goto err_suspend;
> }
>
> --
> 2.31.1
>
Looks correct, dropping.
greg k-h
On Wed, Apr 21, 2021 at 02:59:13PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit a2be42f18d409213bb7e7a736e3ef6ba005115bb.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Mark Brown <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> sound/soc/codecs/cs43130.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/sound/soc/codecs/cs43130.c b/sound/soc/codecs/cs43130.c
> index 80bc7c10ed75..c2b6f0ae6d57 100644
> --- a/sound/soc/codecs/cs43130.c
> +++ b/sound/soc/codecs/cs43130.c
> @@ -2319,8 +2319,6 @@ static int cs43130_probe(struct snd_soc_component *component)
> return ret;
>
> cs43130->wq = create_singlethread_workqueue("cs43130_hp");
> - if (!cs43130->wq)
> - return -ENOMEM;
> INIT_WORK(&cs43130->work, cs43130_imp_meas);
> }
>
> --
> 2.31.1
>
The original patch here is not correct, lots of resources are allocated
and files created that are not unwound. I will keep this revert and fix
it up "properly".
thanks,
greg k-h
On Wed, Apr 21, 2021 at 02:59:17PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit d5414c2355b20ea8201156d2e874265f1cb0d775.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Kalle Valo <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/wireless/rsi/rsi_91x_mac80211.c | 30 +++++++++------------
> 1 file changed, 12 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> index 16025300cddb..714d4d53236c 100644
> --- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> +++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> @@ -188,27 +188,27 @@ bool rsi_is_cipher_wep(struct rsi_common *common)
> * @adapter: Pointer to the adapter structure.
> * @band: Operating band to be set.
> *
> - * Return: int - 0 on success, negative error on failure.
> + * Return: None.
> */
> -static int rsi_register_rates_channels(struct rsi_hw *adapter, int band)
> +static void rsi_register_rates_channels(struct rsi_hw *adapter, int band)
> {
> struct ieee80211_supported_band *sbands = &adapter->sbands[band];
> void *channels = NULL;
>
> if (band == NL80211_BAND_2GHZ) {
> - channels = kmemdup(rsi_2ghz_channels, sizeof(rsi_2ghz_channels),
> - GFP_KERNEL);
> - if (!channels)
> - return -ENOMEM;
> + channels = kmalloc(sizeof(rsi_2ghz_channels), GFP_KERNEL);
> + memcpy(channels,
> + rsi_2ghz_channels,
> + sizeof(rsi_2ghz_channels));
> sbands->band = NL80211_BAND_2GHZ;
> sbands->n_channels = ARRAY_SIZE(rsi_2ghz_channels);
> sbands->bitrates = rsi_rates;
> sbands->n_bitrates = ARRAY_SIZE(rsi_rates);
> } else {
> - channels = kmemdup(rsi_5ghz_channels, sizeof(rsi_5ghz_channels),
> - GFP_KERNEL);
> - if (!channels)
> - return -ENOMEM;
> + channels = kmalloc(sizeof(rsi_5ghz_channels), GFP_KERNEL);
> + memcpy(channels,
> + rsi_5ghz_channels,
> + sizeof(rsi_5ghz_channels));
> sbands->band = NL80211_BAND_5GHZ;
> sbands->n_channels = ARRAY_SIZE(rsi_5ghz_channels);
> sbands->bitrates = &rsi_rates[4];
> @@ -227,7 +227,6 @@ static int rsi_register_rates_channels(struct rsi_hw *adapter, int band)
> sbands->ht_cap.mcs.rx_mask[0] = 0xff;
> sbands->ht_cap.mcs.tx_params = IEEE80211_HT_MCS_TX_DEFINED;
> /* sbands->ht_cap.mcs.rx_highest = 0x82; */
> - return 0;
> }
>
> static int rsi_mac80211_hw_scan_start(struct ieee80211_hw *hw,
> @@ -2067,16 +2066,11 @@ int rsi_mac80211_attach(struct rsi_common *common)
> wiphy->available_antennas_rx = 1;
> wiphy->available_antennas_tx = 1;
>
> - status = rsi_register_rates_channels(adapter, NL80211_BAND_2GHZ);
> - if (status)
> - return status;
> + rsi_register_rates_channels(adapter, NL80211_BAND_2GHZ);
> wiphy->bands[NL80211_BAND_2GHZ] =
> &adapter->sbands[NL80211_BAND_2GHZ];
> if (common->num_supp_bands > 1) {
> - status = rsi_register_rates_channels(adapter,
> - NL80211_BAND_5GHZ);
> - if (status)
> - return status;
> + rsi_register_rates_channels(adapter, NL80211_BAND_5GHZ);
> wiphy->bands[NL80211_BAND_5GHZ] =
> &adapter->sbands[NL80211_BAND_5GHZ];
> }
> --
> 2.31.1
>
This looks correct, will drop the revert.
greg k-h
On Wed, Apr 21, 2021 at 07:53:46PM +0200, Rafael J. Wysocki wrote:
> On 4/21/2021 2:58 PM, Greg Kroah-Hartman wrote:
> > This reverts commit c343bf1ba5efcbf2266a1fe3baefec9cc82f867f.
> >
> > 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.
> >
> > Cc: Qiushi Wu <[email protected]>
> > Cc: Rafael J. Wysocki <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> Acked-by: Rafael J. Wysocki <[email protected]>
>
>
> > ---
> > drivers/cpuidle/sysfs.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
> > index 53ec9585ccd4..23a219cedbdb 100644
> > --- a/drivers/cpuidle/sysfs.c
> > +++ b/drivers/cpuidle/sysfs.c
> > @@ -487,7 +487,7 @@ static int cpuidle_add_state_sysfs(struct cpuidle_device *device)
> > ret = kobject_init_and_add(&kobj->kobj, &ktype_state_cpuidle,
> > &kdev->kobj, "state%d", i);
> > if (ret) {
> > - kobject_put(&kobj->kobj);
> > + kfree(kobj);
> > goto error_state;
> > }
> > cpuidle_add_s2idle_attr_group(kobj);
> > @@ -618,7 +618,7 @@ static int cpuidle_add_driver_sysfs(struct cpuidle_device *dev)
> > ret = kobject_init_and_add(&kdrv->kobj, &ktype_driver_cpuidle,
> > &kdev->kobj, "driver");
> > if (ret) {
> > - kobject_put(&kdrv->kobj);
> > + kfree(kdrv);
> > return ret;
> > }
> > @@ -712,7 +712,7 @@ int cpuidle_add_sysfs(struct cpuidle_device *dev)
> > error = kobject_init_and_add(&kdev->kobj, &ktype_cpuidle, &cpu_dev->kobj,
> > "cpuidle");
> > if (error) {
> > - kobject_put(&kdev->kobj);
> > + kfree(kdev);
> > return error;
> > }
>
>
This looks correct so I'll drop the revert.
greg k-h
On Wed, Apr 21, 2021 at 02:59:14PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 51dd97d1df5fb9ac58b9b358e63e67b530f6ae21.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Mark Brown <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> sound/soc/codecs/rt5645.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
> index 63a7e052eaa0..ab06133a85da 100644
> --- a/sound/soc/codecs/rt5645.c
> +++ b/sound/soc/codecs/rt5645.c
> @@ -3407,9 +3407,6 @@ static int rt5645_probe(struct snd_soc_component *component)
> RT5645_HWEQ_NUM, sizeof(struct rt5645_eq_param_s),
> GFP_KERNEL);
>
> - if (!rt5645->eq_param)
> - return -ENOMEM;
> -
> return 0;
> }
>
> --
> 2.31.1
>
Lots of things seem to be still allocated here, when this returns, so
I'm going to keep this revert and go back to it later and try to fix it
up properly...
thanks,
greg k-h
On Wed, Apr 21, 2021 at 02:59:53PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 63a06181d7ce169d09843645c50fea1901bc9f0a.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Avri Altman <[email protected]>
> Cc: Martin K. Petersen <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/scsi/ufs/ufs-hisi.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/scsi/ufs/ufs-hisi.c b/drivers/scsi/ufs/ufs-hisi.c
> index 0aa58131e791..7d1e07a9d9dd 100644
> --- a/drivers/scsi/ufs/ufs-hisi.c
> +++ b/drivers/scsi/ufs/ufs-hisi.c
> @@ -468,10 +468,6 @@ static int ufs_hisi_init_common(struct ufs_hba *hba)
> ufshcd_set_variant(hba, host);
>
> host->rst = devm_reset_control_get(dev, "rst");
> - if (IS_ERR(host->rst)) {
> - dev_err(dev, "%s: failed to get reset control\n", __func__);
> - return PTR_ERR(host->rst);
> - }
>
> ufs_hisi_set_pm_lvl(hba);
>
> --
> 2.31.1
>
This commit is incorrect, it does not properly clean up on the error
path, so I'll keep the revert and fix it up properly.
thanks,
greg k-h
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
> <[email protected]> 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 <[email protected]>
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
On Wed, Apr 21, 2021 at 06:26:47PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 21, 2021 at 12:18:44PM -0400, Paul Moore wrote:
> > On Wed, Apr 21, 2021 at 9:04 AM Greg Kroah-Hartman
> > <[email protected]> wrote:
> > >
> > > This reverts commit 70c4cf17e445264453bc5323db3e50aa0ac9e81f.
> > >
> > > 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.
> > >
> > > Cc: Wenwen Wang <[email protected]>
> > > Cc: Richard Guy Briggs <[email protected]>
> > > Cc: Paul Moore <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > ---
> > > kernel/auditfilter.c | 12 +++++-------
> > > 1 file changed, 5 insertions(+), 7 deletions(-)
> >
> > NACK on this revert. I've looked at the original patch again this
> > morning, and the original patch still looks correct and doesn't appear
> > to introduce any new faults to the best of my understanding.
> >
>
> Thanks for the review, much appreciate it, I'll drop it.
Now dropped.
On Wed, Apr 21, 2021 at 09:09:56PM -0700, Joe Stringer wrote:
> On Wed, Apr 21, 2021 at 5:01 PM Matteo Croce <[email protected]> wrote:
> >
> > On Wed, 21 Apr 2021 15:00:01 +0200
> > Greg Kroah-Hartman <[email protected]> wrote:
> >
> > > This reverts commit 6f19893b644a9454d85e593b5e90914e7a72b7dd.
> > >
> > > 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.
> > >
> > > Cc: Kangjie Lu <[email protected]>
> > > Cc: David S. Miller <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > ---
> > > net/openvswitch/datapath.c | 4 ----
> > > 1 file changed, 4 deletions(-)
> > >
> > > diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
> > > index 9d6ef6cb9b26..99e63f4bbcaf 100644
> > > --- a/net/openvswitch/datapath.c
> > > +++ b/net/openvswitch/datapath.c
> > > @@ -443,10 +443,6 @@ static int queue_userspace_packet(struct
> > > datapath *dp, struct sk_buff *skb,
> > > upcall = genlmsg_put(user_skb, 0, 0, &dp_packet_genl_family,
> > > 0, upcall_info->cmd);
> > > - if (!upcall) {
> > > - err = -EINVAL;
> > > - goto out;
> > > - }
> > > upcall->dp_ifindex = dp_ifindex;
> > >
> > > err = ovs_nla_put_key(key, key, OVS_PACKET_ATTR_KEY, false,
> > > user_skb);
> >
> > This patch seems good to me, but given the situation I'd like another
> > pair of eyes on it, at least.
>
> The revert LGTM.
>
> A few lines above:
>
> len = upcall_msg_size(upcall_info, hlen - cutlen,
> OVS_CB(skb)->acts_origlen);
> user_skb = genlmsg_new(len, GFP_ATOMIC);
> if (!user_skb) {
> err = -ENOMEM;
> goto out;
> }
>
> upcall_msg_size() calculates the expected size of the buffer,
> including at the very least a nlmsg-aligned sizeof(struct ovs_header),
> plus other constants and also potential (likely) variable lengths
> based on the current flow context.
>
> genlmsg_new() adds the (nlmsg-aligned) nlmsg header length to the
> calculated length when allocating the buffer, and if the memory
> allocation fails here then the error is already returned.
>
> I don't then see a way for genlmsg_put() to fail per the hunk in the
> commit here given that its buffer reservation is calculated based on:
>
> nlh = nlmsg_put(skb, portid, seq, family->id, GENL_HDRLEN +
> family->hdrsize, flags);
>
> Where family->hdrsize would be sizeof(struct ovs_header) since
> dp_packet_genl_family is the family passed into the genlmsg_put()
> call:
>
> static struct genl_family dp_packet_genl_family __ro_after_init = {
> .hdrsize = sizeof(struct ovs_header),
>
> Even if there were some allocation bug here to be fixed (due to
> miscalculating the buffer size in the first place), I don't see how
> the extra error path in the included patch could catch such an error.
> The original patch doesn't seem necessarily problematic, but it
> doesn't seem like it adds anything of value either (or at least,
> nothing a comment couldn't clearly explain).
>
> Cheers,
> Joe
Many thanks for the review, now dropping this revert from my tree.
greg k-h
On Wed, Apr 21, 2021 at 04:20:24PM -0700, Florian Fainelli wrote:
>
>
> On 4/21/2021 6:00 AM, Greg Kroah-Hartman wrote:
> > This reverts commit e49505f7255be8ced695919c08a29bf2c3d79616.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: David S. Miller <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> While this commit does not fix a known problem, the driver should have
> arguably propagated the return values and it did not, so I would be
> inclined to keep it.
Looks good, I'll drop my revert, thanks for the review.
greg k-h
On Wed, Apr 21, 2021 at 11:45:26PM +0300, Kirill Tkhai wrote:
> On 21.04.2021 16:00, Greg Kroah-Hartman wrote:
> > This reverts commit 0eb987c874dc93f9c9d85a6465dbde20fdd3884c.
> >
> > 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.
> >
> > Cc: Aditya Pakki <[email protected]>
> > Cc: Kirill Tkhai <[email protected]>
> > Cc: David S. Miller <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > net/core/net_namespace.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> > index 43b6ac4c4439..9ae0b275238e 100644
> > --- a/net/core/net_namespace.c
> > +++ b/net/core/net_namespace.c
> > @@ -1101,8 +1101,7 @@ static int __init net_ns_init(void)
> > init_net_initialized = true;
> > up_write(&pernet_ops_rwsem);
> >
> > - if (register_pernet_subsys(&net_ns_ops))
> > - panic("Could not register network namespace subsystems");
> > + register_pernet_subsys(&net_ns_ops);
>
> Nacked-by: Kirill Tkhai <[email protected]>
>
> This patch does not have any problem, since it has been already carefully reviewed.
> Kernel panics here only, if we can't allocate ns_common::inum for init_net.
> This can be only a result of a critical deficiency of memory during boot.
Odd, ok, I'll drop this but this feels strange...
greg k-h
On Thu, Apr 22, 2021 at 06:26:23AM +1000, James Morris wrote:
> On Wed, 21 Apr 2021, Greg Kroah-Hartman wrote:
>
> > This reverts commit 106204b56f60abf1bead7dceb88f2be3e34433da.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Mika Westerberg <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/thunderbolt/property.c | 5 -----
> > 1 file changed, 5 deletions(-)
>
> The original patch looks correct.
>
>
> Reviewed-by: James Morris <[email protected]>
Thanks for the review, now dropping this revert.
greg k-h
On Wed, Apr 21, 2021 at 10:03:33AM -0700, Dmitry Torokhov wrote:
> Hi Greg,
>
> On Wed, Apr 21, 2021 at 03:00:32PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit e85bb0beb6498c0dffe18a2f1f16d575bc175c32.
> >
> > 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 one looks really OK to me and does not have to be reverted (unless
> Aditya will come clean and show the error introduced?).
I'll drop this revert, but it isn't usually good to be calling printk()
from an irq.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 03:01:03PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 9899e4d3523faaef17c67141aa80ff2088f17871.
>
> 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.
>
> Cc: Wenwen Wang <[email protected]>
> Cc: Adam Radford <[email protected]>
> Cc: Martin K. Petersen <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/scsi/3w-xxxx.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/scsi/3w-xxxx.c b/drivers/scsi/3w-xxxx.c
> index d90b9fca4aea..8f52f35e40f1 100644
> --- a/drivers/scsi/3w-xxxx.c
> +++ b/drivers/scsi/3w-xxxx.c
> @@ -1035,9 +1035,6 @@ static int tw_chrdev_open(struct inode *inode, struct file *file)
>
> dprintk(KERN_WARNING "3w-xxxx: tw_ioctl_open()\n");
>
> - if (!capable(CAP_SYS_ADMIN))
> - return -EACCES;
> -
> minor_number = iminor(inode);
> if (minor_number >= tw_device_extension_count)
> return -ENODEV;
> --
> 2.31.1
>
The original commit was correct, dropping this revert.
greg k-h
On Wed, Apr 21, 2021 at 03:01:00PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 2c05d88818ab6571816b93edce4d53703870d7ae.
>
> 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.
>
> Cc: Wenwen Wang <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 17 -----------------
> 1 file changed, 17 deletions(-)
>
> diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
> index 84ad7261e243..cc6314aa0154 100644
> --- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
> +++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
> @@ -2157,8 +2157,6 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
> return -EPERM;
> if (copy_from_user(&t, useraddr, sizeof(t)))
> return -EFAULT;
> - if (t.cmd != CHELSIO_SET_QSET_PARAMS)
> - return -EINVAL;
> if (t.qset_idx >= SGE_QSETS)
> return -EINVAL;
> if (!in_range(t.intr_lat, 0, M_NEWTIMER) ||
> @@ -2258,9 +2256,6 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
> if (copy_from_user(&t, useraddr, sizeof(t)))
> return -EFAULT;
>
> - if (t.cmd != CHELSIO_GET_QSET_PARAMS)
> - return -EINVAL;
> -
> /* Display qsets for all ports when offload enabled */
> if (test_bit(OFFLOAD_DEVMAP_BIT, &adapter->open_device_map)) {
> q1 = 0;
> @@ -2306,8 +2301,6 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
> return -EBUSY;
> if (copy_from_user(&edata, useraddr, sizeof(edata)))
> return -EFAULT;
> - if (edata.cmd != CHELSIO_SET_QSET_NUM)
> - return -EINVAL;
> if (edata.val < 1 ||
> (edata.val > 1 && !(adapter->flags & USING_MSIX)))
> return -EINVAL;
> @@ -2348,8 +2341,6 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
> return -EPERM;
> if (copy_from_user(&t, useraddr, sizeof(t)))
> return -EFAULT;
> - if (t.cmd != CHELSIO_LOAD_FW)
> - return -EINVAL;
> /* Check t.len sanity ? */
> fw_data = memdup_user(useraddr + sizeof(t), t.len);
> if (IS_ERR(fw_data))
> @@ -2373,8 +2364,6 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
> return -EBUSY;
> if (copy_from_user(&m, useraddr, sizeof(m)))
> return -EFAULT;
> - if (m.cmd != CHELSIO_SETMTUTAB)
> - return -EINVAL;
> if (m.nmtus != NMTUS)
> return -EINVAL;
> if (m.mtus[0] < 81) /* accommodate SACK */
> @@ -2416,8 +2405,6 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
> return -EBUSY;
> if (copy_from_user(&m, useraddr, sizeof(m)))
> return -EFAULT;
> - if (m.cmd != CHELSIO_SET_PM)
> - return -EINVAL;
> if (!is_power_of_2(m.rx_pg_sz) ||
> !is_power_of_2(m.tx_pg_sz))
> return -EINVAL; /* not power of 2 */
> @@ -2453,8 +2440,6 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
> return -EIO; /* need the memory controllers */
> if (copy_from_user(&t, useraddr, sizeof(t)))
> return -EFAULT;
> - if (t.cmd != CHELSIO_GET_MEM)
> - return -EINVAL;
> if ((t.addr & 7) || (t.len & 7))
> return -EINVAL;
> if (t.mem_id == MEM_CM)
> @@ -2507,8 +2492,6 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
> return -EAGAIN;
> if (copy_from_user(&t, useraddr, sizeof(t)))
> return -EFAULT;
> - if (t.cmd != CHELSIO_SET_TRACE_FILTER)
> - return -EINVAL;
>
> tp = (const struct trace_params *)&t.sip;
> if (t.config_tx)
> --
> 2.31.1
>
The original commit looks correct, dropping this revert.
greg k-h
On Wed, Apr 21, 2021 at 03:00:55PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit b6168562c8ce2bd5a30e213021650422e08764dc.
>
> 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.
>
> Cc: Wenwen Wang <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> net/socket.c | 11 +++--------
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/net/socket.c b/net/socket.c
> index 84a8049c2b09..d4176362a27b 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -3182,14 +3182,9 @@ static int ethtool_ioctl(struct net *net, struct compat_ifreq __user *ifr32)
> copy_in_user(&rxnfc->fs.ring_cookie,
> &compat_rxnfc->fs.ring_cookie,
> (void __user *)(&rxnfc->fs.location + 1) -
> - (void __user *)&rxnfc->fs.ring_cookie))
> - return -EFAULT;
> - if (ethcmd == ETHTOOL_GRXCLSRLALL) {
> - if (put_user(rule_cnt, &rxnfc->rule_cnt))
> - return -EFAULT;
> - } else if (copy_in_user(&rxnfc->rule_cnt,
> - &compat_rxnfc->rule_cnt,
> - sizeof(rxnfc->rule_cnt)))
> + (void __user *)&rxnfc->fs.ring_cookie) ||
> + copy_in_user(&rxnfc->rule_cnt, &compat_rxnfc->rule_cnt,
> + sizeof(rxnfc->rule_cnt)))
> return -EFAULT;
> }
>
> --
> 2.31.1
>
Original looks correct, dropping this revert.
greg k-h
On Wed, Apr 21, 2021 at 03:00:56PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 800a7340ab7dd667edf95e74d8e4f23a17e87076.
>
> 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.
>
> Cc: [email protected]
> Cc: Wenwen Wang <[email protected]>
> Cc: Mike Snitzer <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/md/dm-ioctl.c | 18 ++++++++++++------
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
> index 1ca65b434f1f..820342de92cd 100644
> --- a/drivers/md/dm-ioctl.c
> +++ b/drivers/md/dm-ioctl.c
> @@ -1747,7 +1747,8 @@ static void free_params(struct dm_ioctl *param, size_t param_size, int param_fla
> }
>
> static int copy_params(struct dm_ioctl __user *user, struct dm_ioctl *param_kernel,
> - int ioctl_flags, struct dm_ioctl **param, int *param_flags)
> + int ioctl_flags,
> + struct dm_ioctl **param, int *param_flags)
> {
> struct dm_ioctl *dmi;
> int secure_data;
> @@ -1788,13 +1789,18 @@ static int copy_params(struct dm_ioctl __user *user, struct dm_ioctl *param_kern
>
> *param_flags |= DM_PARAMS_MALLOC;
>
> - /* Copy from param_kernel (which was already copied from user) */
> - memcpy(dmi, param_kernel, minimum_data_size);
> -
> - if (copy_from_user(&dmi->data, (char __user *)user + minimum_data_size,
> - param_kernel->data_size - minimum_data_size))
> + if (copy_from_user(dmi, user, param_kernel->data_size))
> goto bad;
> +
> data_copied:
> + /*
> + * Abort if something changed the ioctl data while it was being copied.
> + */
> + if (dmi->data_size != param_kernel->data_size) {
> + DMERR("rejecting ioctl: data size modified while processing parameters");
> + goto bad;
> + }
> +
> /* Wipe the user buffer so we do not return it to userspace */
> if (secure_data && clear_user(user, param_kernel->data_size))
> goto bad;
> --
> 2.31.1
>
Original looks correct, dropping this commit now.
greg k-h
On Wed, Apr 21, 2021 at 03:00:59PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 0781168e23a2fc8dceb989f11fc5b39b3ccacc35.
>
> 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.
>
> Cc: Wenwen Wang <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/hamradio/yam.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/net/hamradio/yam.c b/drivers/net/hamradio/yam.c
> index 5ab53e9942f3..616db3a0d2f4 100644
> --- a/drivers/net/hamradio/yam.c
> +++ b/drivers/net/hamradio/yam.c
> @@ -951,8 +951,6 @@ static int yam_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
> sizeof(struct yamdrv_ioctl_mcs));
> if (IS_ERR(ym))
> return PTR_ERR(ym);
> - if (ym->cmd != SIOCYAMSMCS)
> - return -EINVAL;
> if (ym->bitrate > YAM_MAXBITRATE) {
> kfree(ym);
> return -EINVAL;
> @@ -968,8 +966,6 @@ static int yam_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
> if (copy_from_user(&yi, ifr->ifr_data, sizeof(struct yamdrv_ioctl_cfg)))
> return -EFAULT;
>
> - if (yi.cmd != SIOCYAMSCFG)
> - return -EINVAL;
> if ((yi.cfg.mask & YAM_IOBASE) && netif_running(dev))
> return -EINVAL; /* Cannot change this parameter when up */
> if ((yi.cfg.mask & YAM_IRQ) && netif_running(dev))
> --
> 2.31.1
>
Original looks correct, dropping this revert.
greg k-h
On Wed, Apr 21, 2021 at 03:00:54PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 966e927bf8cc6a44f8b72582a1d6d3ffc73b12ad.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Mark Brown <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/regulator/palmas-regulator.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/regulator/palmas-regulator.c b/drivers/regulator/palmas-regulator.c
> index 337dd614695e..f27ad8254291 100644
> --- a/drivers/regulator/palmas-regulator.c
> +++ b/drivers/regulator/palmas-regulator.c
> @@ -438,16 +438,13 @@ static int palmas_ldo_write(struct palmas *palmas, unsigned int reg,
> static int palmas_set_mode_smps(struct regulator_dev *dev, unsigned int mode)
> {
> int id = rdev_get_id(dev);
> - int ret;
> struct palmas_pmic *pmic = rdev_get_drvdata(dev);
> struct palmas_pmic_driver_data *ddata = pmic->palmas->pmic_ddata;
> struct palmas_regs_info *rinfo = &ddata->palmas_regs_info[id];
> unsigned int reg;
> bool rail_enable = true;
>
> - ret = palmas_smps_read(pmic->palmas, rinfo->ctrl_addr, ®);
> - if (ret)
> - return ret;
> + palmas_smps_read(pmic->palmas, rinfo->ctrl_addr, ®);
>
> reg &= ~PALMAS_SMPS12_CTRL_MODE_ACTIVE_MASK;
>
> --
> 2.31.1
>
Original looks correct, dropping.
greg k-h
On Wed, Apr 21, 2021 at 03:00:50PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit f0fb9b288d0a7e9cc324ae362e2dfd2cc2217ded.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> net/ipv6/route.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 373d48073106..0e85741423d7 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -6169,16 +6169,12 @@ static int ipv6_sysctl_rtcache_flush(struct ctl_table *ctl, int write,
> {
> struct net *net;
> int delay;
> - int ret;
> if (!write)
> return -EINVAL;
>
> net = (struct net *)ctl->extra1;
> delay = net->ipv6.sysctl.flush_delay;
> - ret = proc_dointvec(ctl, write, buffer, lenp, ppos);
> - if (ret)
> - return ret;
> -
> + proc_dointvec(ctl, write, buffer, lenp, ppos);
> fib6_run_gc(delay <= 0 ? 0 : (unsigned long)delay, net, delay > 0);
> return 0;
> }
> --
> 2.31.1
>
Original looks correct, dropping this revert.
greg k-h
On Wed, Apr 21, 2021 at 03:00:49PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit ca19fcb6285bfce1601c073bf4b9d2942e2df8d9.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c b/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
> index 23a2ebdfd503..c7378da78a83 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cudbg_lib.c
> @@ -1638,10 +1638,6 @@ int cudbg_collect_hw_sched(struct cudbg_init *pdbg_init,
>
> rc = cudbg_get_buff(pdbg_init, dbg_buff, sizeof(struct cudbg_hw_sched),
> &temp_buff);
> -
> - if (rc)
> - return rc;
> -
> hw_sched_buff = (struct cudbg_hw_sched *)temp_buff.data;
> hw_sched_buff->map = t4_read_reg(padap, TP_TX_MOD_QUEUE_REQ_MAP_A);
> hw_sched_buff->mode = TIMERMODE_G(t4_read_reg(padap, TP_MOD_CONFIG_A));
> --
> 2.31.1
>
Original looks correct, dropping this revert.
greg k-h
On 4/27/21 10:12 AM, Greg KH wrote:
> On Tue, Apr 27, 2021 at 08:39:15AM -0600, Jens Axboe wrote:
>> On 4/27/21 8:03 AM, Peter Rosin wrote:
>>> On 2021-04-27 15:01, Greg KH wrote:
>>>> On Fri, Apr 23, 2021 at 08:20:30AM -0600, Jens Axboe wrote:
>>>>> On 4/22/21 3:29 PM, Peter Rosin wrote:
>>>>>>> This reverts commit 093c48213ee37c3c3ff1cf5ac1aa2a9d8bc66017.
>>>>>>
>>>>>> The reverted patch looks fishy.
>>>>>>
>>>>>> gc.cd_info is kzalloc:ed on probe. In case probe fails after this allocation, the
>>>>>> memory is kfree:d but the variable is NOT zeroed out.
>>>>>>
>>>>>> AFAICT, the above leads to a double-free on exit by the added line.
>>>>>>
>>>>>> I believe gd.cd_info should be kfree:d on remove instead.
>>>>>>
>>>>>> However, might not gc.toc also be kfree:d twice for similar reasons?
>>>>>>
>>>>>> I could easily be mistaken.
>>>>>
>>>>> >From taking a quick look the other day, that's my conclusion too. I
>>>>> don't think the patch is correct, but I don't think the surrounding code
>>>>> is correct right now either.
>>>>
>>>> Thanks for the review from both of you, I'll keep this commit in the
>>>> tree.
>>> Err, which commit is "this" and what tree are you keeping it in? I
>>> think you mean that you are keeping the revert in your tree with
>>> reverts, and not that you mean that we should keep the original
>>> commit in Linus' tree.
>>>
>>> In any case, I'd think that the original memory leak is somewhat
>>> better than the introduced double-free and therefore the revert
>>> should be done.
>>
>> It should probably look like the below, though I doubt it matters
>> since only one device is supported anyway. As long as the free
>> happens post unregister, it likely won't make a difference. But
>> it is cleaner and easier to verify, and should double device support
>> ever be introduced, the existing code is buggy.
>>
>> But given that, I don't think we should keep the revert patch.
>>
>> diff --git a/drivers/cdrom/gdrom.c b/drivers/cdrom/gdrom.c
>> index 9874fc1c815b..02d369881165 100644
>> --- a/drivers/cdrom/gdrom.c
>> +++ b/drivers/cdrom/gdrom.c
>> @@ -831,6 +831,8 @@ static int remove_gdrom(struct platform_device *devptr)
>> if (gdrom_major)
>> unregister_blkdev(gdrom_major, GDROM_DEV_NAME);
>> unregister_cdrom(gd.cd_info);
>> + kfree(gd.toc);
>> + kfree(gd.cd_info);
>>
>> return 0;
>> }
>> @@ -862,8 +864,6 @@ static void __exit exit_gdrom(void)
>> {
>> platform_device_unregister(pd);
>> platform_driver_unregister(&gdrom_driver);
>> - kfree(gd.toc);
>> - kfree(gd.cd_info);
>> }
>>
>> module_init(init_gdrom);
>>
>> --
>> Jens Axboe
>>
>
> I'll add this fix to the tree after the revert, and give you the credit
> for the fix :)
Sounds good, thanks Greg.
--
Jens Axboe
On Wed, Apr 21, 2021 at 03:00:04PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 5bf7295fe34a5251b1d241b9736af4697b590670.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
> index d8a3ecaed3fc..985cf8cb2ec0 100644
> --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
> +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ethtool.c
> @@ -1047,8 +1047,6 @@ int qlcnic_do_lb_test(struct qlcnic_adapter *adapter, u8 mode)
>
> for (i = 0; i < QLCNIC_NUM_ILB_PKT; i++) {
> skb = netdev_alloc_skb(adapter->netdev, QLCNIC_ILB_PKT_SIZE);
> - if (!skb)
> - break;
> qlcnic_create_loopback_buff(skb->data, adapter->mac_addr);
> skb_put(skb, QLCNIC_ILB_PKT_SIZE);
> adapter->ahw->diag_cnt = 0;
> --
> 2.31.1
>
This commit does not properly detect if an error happens because the
logic after this loop will not detect that there was a failed
allocation. I will keep this revert and fix it up properly later.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 02:59:45PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit fba1bdd2a9a93f3e2181ec1936a3c2f6b37e7ed6.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Manish Rangankar <[email protected]>
> Cc: Mukesh Ojha <[email protected]>
> Cc: Martin K. Petersen <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/scsi/qla4xxx/ql4_os.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/scsi/qla4xxx/ql4_os.c b/drivers/scsi/qla4xxx/ql4_os.c
> index 7bd9a4a04ad5..5cb0dfe7a83b 100644
> --- a/drivers/scsi/qla4xxx/ql4_os.c
> +++ b/drivers/scsi/qla4xxx/ql4_os.c
> @@ -3229,8 +3229,6 @@ static int qla4xxx_conn_bind(struct iscsi_cls_session *cls_session,
> if (iscsi_conn_bind(cls_session, cls_conn, is_leading))
> return -EINVAL;
> ep = iscsi_lookup_endpoint(transport_fd);
> - if (!ep)
> - return -EINVAL;
> conn = cls_conn->dd_data;
> qla_conn = conn->dd_data;
> qla_conn->qla_ep = ep->dd_data;
> --
> 2.31.1
>
Looks to be correct. Odd that you do not have to "unbind" after calling
iscsi_conn_bind(), but hey, it's scsi functions, they are always odd :)
I'll drop this revert.
greg k-h
On Wed, Apr 21, 2021 at 02:58:57PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 52b894393cecdc303990e834778d39b85d0553fc.
>
> 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.
>
> Cc: https
> Cc: Hannes Reinecke <[email protected]>
> Cc: Aditya Pakki <[email protected]>
> Cc: Martin K. Petersen <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/target/tcm_fc/tfc_io.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/target/tcm_fc/tfc_io.c b/drivers/target/tcm_fc/tfc_io.c
> index bbe2e29612fa..15d557a11f63 100644
> --- a/drivers/target/tcm_fc/tfc_io.c
> +++ b/drivers/target/tcm_fc/tfc_io.c
> @@ -220,6 +220,7 @@ void ft_recv_write_data(struct ft_cmd *cmd, struct fc_frame *fp)
> ep = fc_seq_exch(seq);
> lport = ep->lp;
> if (cmd->was_ddp_setup) {
> + BUG_ON(!ep);
> BUG_ON(!lport);
> /*
> * Since DDP (Large Rx offload) was setup for this request,
> --
> 2.31.1
>
The original was obviously correct, so I'll drop this revert.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 02:58:44PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit b975abbd382fe442713a4c233549abb90e57c22b.
>
> 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.
>
> Cc: Qiushi Wu <[email protected]>
> Cc: Chris Wilson <[email protected]>
> Cc: Chris Wilson <[email protected]>
> Cc: https
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/char/agp/intel-gtt.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
> index 5bfdf222d5f9..4b34a5195c65 100644
> --- a/drivers/char/agp/intel-gtt.c
> +++ b/drivers/char/agp/intel-gtt.c
> @@ -304,10 +304,8 @@ static int intel_gtt_setup_scratch_page(void)
> if (intel_private.needs_dmar) {
> dma_addr = pci_map_page(intel_private.pcidev, page, 0,
> PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
> - if (pci_dma_mapping_error(intel_private.pcidev, dma_addr)) {
> - __free_page(page);
> + if (pci_dma_mapping_error(intel_private.pcidev, dma_addr))
> return -EINVAL;
> - }
>
> intel_private.scratch_page_dma = dma_addr;
> } else
> --
> 2.31.1
>
Original looks correct, I'll drop this revert.
greg k-h
On Wed, Apr 21, 2021 at 03:00:13PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit fe543b2f174f34a7a751aa08b334fe6b105c4569.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ethernet/cavium/liquidio/lio_main.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/liquidio/lio_main.c b/drivers/net/ethernet/cavium/liquidio/lio_main.c
> index 7c5af4beedc6..6fa570068648 100644
> --- a/drivers/net/ethernet/cavium/liquidio/lio_main.c
> +++ b/drivers/net/ethernet/cavium/liquidio/lio_main.c
> @@ -1166,11 +1166,6 @@ static void send_rx_ctrl_cmd(struct lio *lio, int start_stop)
> sc = (struct octeon_soft_command *)
> octeon_alloc_soft_command(oct, OCTNET_CMD_SIZE,
> 16, 0);
> - if (!sc) {
> - netif_info(lio, rx_err, lio->netdev,
> - "Failed to allocate octeon_soft_command\n");
> - return;
> - }
>
> ncmd = (union octnet_cmd *)sc->virtdptr;
>
> --
> 2.31.1
>
While this does keep the immediate "NULL dereference" from happening, it
does not properly propagate the error back to the callers, AND it does
not fix this same identical issue in the
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c for some reason. I
will revert this and fix up both files properly in a later on patch.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 02:59:59PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit f37d8e67f39e6d3eaf4cc5471e8a3d21209843c6.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Mark Brown <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/spi/spi-topcliff-pch.c | 15 ++-------------
> 1 file changed, 2 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/spi/spi-topcliff-pch.c b/drivers/spi/spi-topcliff-pch.c
> index b459e369079f..12d749e9436b 100644
> --- a/drivers/spi/spi-topcliff-pch.c
> +++ b/drivers/spi/spi-topcliff-pch.c
> @@ -1290,27 +1290,18 @@ static void pch_free_dma_buf(struct pch_spi_board_data *board_dat,
> dma->rx_buf_virt, dma->rx_buf_dma);
> }
>
> -static int pch_alloc_dma_buf(struct pch_spi_board_data *board_dat,
> +static void pch_alloc_dma_buf(struct pch_spi_board_data *board_dat,
> struct pch_spi_data *data)
> {
> struct pch_spi_dma_ctrl *dma;
> - int ret;
>
> dma = &data->dma;
> - ret = 0;
> /* Get Consistent memory for Tx DMA */
> dma->tx_buf_virt = dma_alloc_coherent(&board_dat->pdev->dev,
> PCH_BUF_SIZE, &dma->tx_buf_dma, GFP_KERNEL);
> - if (!dma->tx_buf_virt)
> - ret = -ENOMEM;
> -
> /* Get Consistent memory for Rx DMA */
> dma->rx_buf_virt = dma_alloc_coherent(&board_dat->pdev->dev,
> PCH_BUF_SIZE, &dma->rx_buf_dma, GFP_KERNEL);
> - if (!dma->rx_buf_virt)
> - ret = -ENOMEM;
> -
> - return ret;
> }
>
> static int pch_spi_pd_probe(struct platform_device *plat_dev)
> @@ -1387,9 +1378,7 @@ static int pch_spi_pd_probe(struct platform_device *plat_dev)
>
> if (use_dma) {
> dev_info(&plat_dev->dev, "Use DMA for data transfers\n");
> - ret = pch_alloc_dma_buf(board_dat, data);
> - if (ret)
> - goto err_spi_register_master;
> + pch_alloc_dma_buf(board_dat, data);
> }
>
> ret = spi_register_master(master);
> --
> 2.31.1
>
THis looks correct, so I'll drop the revert.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 02:59:06PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 02a896ca84874bbfcedc006303f2951dda89b298.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ppp/pppoe.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ppp/pppoe.c b/drivers/net/ppp/pppoe.c
> index d7f50b835050..803a4fe1ca18 100644
> --- a/drivers/net/ppp/pppoe.c
> +++ b/drivers/net/ppp/pppoe.c
> @@ -119,6 +119,8 @@ static inline bool stage_session(__be16 sid)
>
> static inline struct pppoe_net *pppoe_pernet(struct net *net)
> {
> + BUG_ON(!net);
> +
> return net_generic(net, pppoe_net_id);
> }
>
> --
> 2.31.1
>
THe original here was correct so I'll drop this revert.
greg k-h
On Wed, Apr 21, 2021 at 02:59:34PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 31fa6e2ae65feed0de10823c5d1eea21a93086c9.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Kangjie Lu <[email protected]>
> Cc: Bartlomiej Zolnierkiewicz <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c b/drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c
> index 0ae0cab252d3..05d87dcbdd8b 100644
> --- a/drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c
> +++ b/drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c
> @@ -100,8 +100,6 @@ static void __init omapdss_omapify_node(struct device_node *node)
>
> new_len = prop->length + strlen(prefix) * num_strs;
> new_compat = kmalloc(new_len, GFP_KERNEL);
> - if (!new_compat)
> - return;
>
> omapdss_prefix_strcpy(new_compat, new_len, prop->value, prop->length);
>
> --
> 2.31.1
>
Original looks correct, I'll drop this revert.
greg k-h
On Wed, Apr 21, 2021 at 02:59:12PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 23015b22e47c5409620b1726a677d69e5cd032ba.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Alexandre Bounine <[email protected]>
> Cc: Matt Porter <[email protected]>
> Cc: Andrew Morton <[email protected]>
> Cc: Linus Torvalds <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/rapidio/rio_cm.c | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/rapidio/rio_cm.c b/drivers/rapidio/rio_cm.c
> index 50ec53d67a4c..e6c16f04f2b4 100644
> --- a/drivers/rapidio/rio_cm.c
> +++ b/drivers/rapidio/rio_cm.c
> @@ -2138,14 +2138,6 @@ static int riocm_add_mport(struct device *dev,
> mutex_init(&cm->rx_lock);
> riocm_rx_fill(cm, RIOCM_RX_RING_SIZE);
> cm->rx_wq = create_workqueue(DRV_NAME "/rxq");
> - if (!cm->rx_wq) {
> - riocm_error("failed to allocate IBMBOX_%d on %s",
> - cmbox, mport->name);
> - rio_release_outb_mbox(mport, cmbox);
> - kfree(cm);
> - return -ENOMEM;
> - }
> -
> INIT_WORK(&cm->rx_work, rio_ibmsg_handler);
>
> cm->tx_slot = 0;
> --
> 2.31.1
>
This patch has a memory leak on the error path here, it does not clean
up everything properly. So I'll keep the revert and fix it up properly
in a follow-on patch.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 03:00:16PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 434256833d8eb988cb7f3b8a41699e2fe48d9332.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Kalle Valo <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/wireless/marvell/libertas/mesh.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/libertas/mesh.c b/drivers/net/wireless/marvell/libertas/mesh.c
> index f5b78257d551..c611e6668b21 100644
> --- a/drivers/net/wireless/marvell/libertas/mesh.c
> +++ b/drivers/net/wireless/marvell/libertas/mesh.c
> @@ -805,12 +805,7 @@ static void lbs_persist_config_init(struct net_device *dev)
> {
> int ret;
> ret = sysfs_create_group(&(dev->dev.kobj), &boot_opts_group);
> - if (ret)
> - pr_err("failed to create boot_opts_group.\n");
> -
> ret = sysfs_create_group(&(dev->dev.kobj), &mesh_ie_group);
> - if (ret)
> - pr_err("failed to create mesh_ie_group.\n");
> }
>
> static void lbs_persist_config_remove(struct net_device *dev)
> --
> 2.31.1
>
The original change here is incorrect, the error needs to be propagated
back to the caller AND if the second group call fails, the first needs
to be removed. There are much better ways to solve this, the driver
should NOT be calling sysfs_create_group() on its own as it is racing
userspace and loosing. I will keep this revert and fix it up properly
in a follow-on patch.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 03:00:29PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit fc6a6521556c8250e356ddc6a3f2391aa62dc976.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Kalle Valo <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/wireless/ath/ath6kl/wmi.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath6kl/wmi.c b/drivers/net/wireless/ath/ath6kl/wmi.c
> index b137e7f34397..aca9732ec1ee 100644
> --- a/drivers/net/wireless/ath/ath6kl/wmi.c
> +++ b/drivers/net/wireless/ath/ath6kl/wmi.c
> @@ -776,8 +776,10 @@ int ath6kl_wmi_set_roam_lrssi_cmd(struct wmi *wmi, u8 lrssi)
> cmd->info.params.roam_rssi_floor = DEF_LRSSI_ROAM_FLOOR;
> cmd->roam_ctrl = WMI_SET_LRSSI_SCAN_PARAMS;
>
> - return ath6kl_wmi_cmd_send(wmi, 0, skb, WMI_SET_ROAM_CTRL_CMDID,
> + ath6kl_wmi_cmd_send(wmi, 0, skb, WMI_SET_ROAM_CTRL_CMDID,
> NO_SYNC_WMIFLAG);
> +
> + return 0;
> }
>
> int ath6kl_wmi_force_roam_cmd(struct wmi *wmi, const u8 *bssid)
> --
> 2.31.1
>
This change does NOTHING as the caller to this function does not even
look at the return value of the call. So the "claim" that this fixed an
an issue is not true. I will keep this revert and fix it up properly by
propagating the error up the stack correctly.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 02:59:03PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit bbd20c939c8aa3f27fa30e86691af250bf92973a.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/atm/fore200e.c | 25 +++++++------------------
> 1 file changed, 7 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
> index 495fd0a1f040..e83286e3216e 100644
> --- a/drivers/atm/fore200e.c
> +++ b/drivers/atm/fore200e.c
> @@ -1412,14 +1412,12 @@ fore200e_open(struct atm_vcc *vcc)
> static void
> fore200e_close(struct atm_vcc* vcc)
> {
> + struct fore200e* fore200e = FORE200E_DEV(vcc->dev);
> struct fore200e_vcc* fore200e_vcc;
> - struct fore200e* fore200e;
> struct fore200e_vc_map* vc_map;
> unsigned long flags;
>
> ASSERT(vcc);
> - fore200e = FORE200E_DEV(vcc->dev);
> -
> ASSERT((vcc->vpi >= 0) && (vcc->vpi < 1<<FORE200E_VPI_BITS));
> ASSERT((vcc->vci >= 0) && (vcc->vci < 1<<FORE200E_VCI_BITS));
>
> @@ -1464,10 +1462,10 @@ fore200e_close(struct atm_vcc* vcc)
> static int
> fore200e_send(struct atm_vcc *vcc, struct sk_buff *skb)
> {
> - struct fore200e* fore200e;
> - struct fore200e_vcc* fore200e_vcc;
> + struct fore200e* fore200e = FORE200E_DEV(vcc->dev);
> + struct fore200e_vcc* fore200e_vcc = FORE200E_VCC(vcc);
> struct fore200e_vc_map* vc_map;
> - struct host_txq* txq;
> + struct host_txq* txq = &fore200e->host_txq;
> struct host_txq_entry* entry;
> struct tpd* tpd;
> struct tpd_haddr tpd_haddr;
> @@ -1480,18 +1478,9 @@ fore200e_send(struct atm_vcc *vcc, struct sk_buff *skb)
> unsigned char* data;
> unsigned long flags;
>
> - if (!vcc)
> - return -EINVAL;
> -
> - fore200e = FORE200E_DEV(vcc->dev);
> - fore200e_vcc = FORE200E_VCC(vcc);
> -
> - if (!fore200e)
> - return -EINVAL;
> -
> - txq = &fore200e->host_txq;
> - if (!fore200e_vcc)
> - return -EINVAL;
> + ASSERT(vcc);
> + ASSERT(fore200e);
> + ASSERT(fore200e_vcc);
>
> if (!test_bit(ATM_VF_READY, &vcc->flags)) {
> DPRINTK(1, "VC %d.%d.%d not ready for tx\n", vcc->itf, vcc->vpi, vcc->vpi);
> --
> 2.31.1
>
Wow, the names in this code bring back memories...
Anyway, the original looks correct, but could have been written a lot
better, it's quite "twisty" for something that should have been very
simple to make "obvious".
I'll drop this revert.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 02:59:25PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit e183d4e414b64711baf7a04e214b61969ca08dfa.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Ursula Braun <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> net/smc/smc_ism.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/net/smc/smc_ism.c b/net/smc/smc_ism.c
> index 9c6e95882553..6558cf7643a7 100644
> --- a/net/smc/smc_ism.c
> +++ b/net/smc/smc_ism.c
> @@ -417,11 +417,6 @@ struct smcd_dev *smcd_alloc_dev(struct device *parent, const char *name,
> init_waitqueue_head(&smcd->lgrs_deleted);
> smcd->event_wq = alloc_ordered_workqueue("ism_evt_wq-%s)",
> WQ_MEM_RECLAIM, name);
> - if (!smcd->event_wq) {
> - kfree(smcd->conn);
> - kfree(smcd);
> - return NULL;
> - }
> return smcd;
> }
> EXPORT_SYMBOL_GPL(smcd_alloc_dev);
> --
> 2.31.1
>
The original is incorrect and causes a memory leak. I will keep this
revert and fix it up properly with a follow-on patch.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 03:00:47PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 2d822f2dbab7f4c820f72eb8570aacf3f35855bd.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ethernet/ti/cpts.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/ti/cpts.c b/drivers/net/ethernet/ti/cpts.c
> index 43222a34cba0..60fde1bb9665 100644
> --- a/drivers/net/ethernet/ti/cpts.c
> +++ b/drivers/net/ethernet/ti/cpts.c
> @@ -778,9 +778,7 @@ struct cpts *cpts_create(struct device *dev, void __iomem *regs,
> return ERR_CAST(cpts->refclk);
> }
>
> - ret = clk_prepare(cpts->refclk);
> - if (ret)
> - return ERR_PTR(ret);
> + clk_prepare(cpts->refclk);
>
> cpts->cc.read = cpts_systim_read;
> cpts->cc.mask = CLOCKSOURCE_MASK(32);
> --
> 2.31.1
>
Original looks correct, revert now dropped.
greg k-h
On Wed, Apr 21, 2021 at 03:00:46PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit f86a3b83833e7cfe558ca4d70b64ebc48903efec.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
> index 0e1ca2cba3c7..0e86553fc06f 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sunxi.c
> @@ -50,9 +50,7 @@ static int sun7i_gmac_init(struct platform_device *pdev, void *priv)
> gmac->clk_enabled = 1;
> } else {
> clk_set_rate(gmac->tx_clk, SUN7I_GMAC_MII_RATE);
> - ret = clk_prepare(gmac->tx_clk);
> - if (ret)
> - return ret;
> + clk_prepare(gmac->tx_clk);
> }
>
> return 0;
> --
> 2.31.1
>
The original commit here can cause a memory leak so I will keep this
revert and submit a change that fixes this up properly.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 03:00:44PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit ff07d48d7bc0974d4f96a85a4df14564fb09f1ef.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
> index ff9f96de74b8..85f9cb769e30 100644
> --- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
> +++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
> @@ -455,9 +455,7 @@ static void atl1e_mdio_write(struct net_device *netdev, int phy_id,
> {
> struct atl1e_adapter *adapter = netdev_priv(netdev);
>
> - if (atl1e_write_phy_reg(&adapter->hw,
> - reg_num & MDIO_REG_ADDR_MASK, val))
> - netdev_err(netdev, "write phy register failed\n");
> + atl1e_write_phy_reg(&adapter->hw, reg_num & MDIO_REG_ADDR_MASK, val);
> }
>
> static int atl1e_mii_ioctl(struct net_device *netdev,
> --
> 2.31.1
>
The original change here is a mess, what is a user supposed to do if
this call fails? I will revert it and properly pass the error value up
to the callers, as that is the correct thing to do here, not paper over
the issue with a commit message that claims this change "fixes"
anything.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 03:00:38PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 7c97381e7a9a5ec359007c0d491a143e3d9f787c.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Vinod Koul <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/dma/mv_xor.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/dma/mv_xor.c b/drivers/dma/mv_xor.c
> index 23b232b57518..78bd52565571 100644
> --- a/drivers/dma/mv_xor.c
> +++ b/drivers/dma/mv_xor.c
> @@ -1144,10 +1144,7 @@ mv_xor_channel_add(struct mv_xor_device *xordev,
> dma_has_cap(DMA_MEMCPY, dma_dev->cap_mask) ? "cpy " : "",
> dma_has_cap(DMA_INTERRUPT, dma_dev->cap_mask) ? "intr " : "");
>
> - ret = dma_async_device_register(dma_dev);
> - if (ret)
> - goto err_free_irq;
> -
> + dma_async_device_register(dma_dev);
> return mv_chan;
>
> err_free_irq:
> --
> 2.31.1
>
The original commit here is correct, I will drop this revert.
greg k-h
On Wed, Apr 21, 2021 at 03:00:12PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 41af8b3a097c6fd17a4867efa25966927094f57c.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ethernet/cavium/liquidio/lio_core.c | 10 ----------
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/liquidio/lio_core.c b/drivers/net/ethernet/cavium/liquidio/lio_core.c
> index 2a0d64e5797c..3532730eb936 100644
> --- a/drivers/net/ethernet/cavium/liquidio/lio_core.c
> +++ b/drivers/net/ethernet/cavium/liquidio/lio_core.c
> @@ -1211,11 +1211,6 @@ int liquidio_change_mtu(struct net_device *netdev, int new_mtu)
>
> sc = (struct octeon_soft_command *)
> octeon_alloc_soft_command(oct, OCTNET_CMD_SIZE, 16, 0);
> - if (!sc) {
> - netif_info(lio, rx_err, lio->netdev,
> - "Failed to allocate soft command\n");
> - return -ENOMEM;
> - }
>
> ncmd = (union octnet_cmd *)sc->virtdptr;
>
> @@ -1689,11 +1684,6 @@ int liquidio_set_fec(struct lio *lio, int on_off)
>
> sc = octeon_alloc_soft_command(oct, OCTNET_CMD_SIZE,
> sizeof(struct oct_nic_seapi_resp), 0);
> - if (!sc) {
> - dev_err(&oct->pci_dev->dev,
> - "Failed to allocate soft command\n");
> - return -ENOMEM;
> - }
>
> ncmd = sc->virtdptr;
> resp = sc->virtrptr;
> --
> 2.31.1
>
Original here looks correct, I'll drop my revert.
greg k-h
On Wed, Apr 21, 2021 at 03:00:19PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit b05ae01fdb8966afff5b153e7a7ee24684745e2d.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Greg Kroah-Hartman <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/misc/ics932s401.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/misc/ics932s401.c b/drivers/misc/ics932s401.c
> index 2bdf560ee681..733e5c2b57ce 100644
> --- a/drivers/misc/ics932s401.c
> +++ b/drivers/misc/ics932s401.c
> @@ -133,8 +133,6 @@ static struct ics932s401_data *ics932s401_update_device(struct device *dev)
> */
> for (i = 0; i < NUM_MIRRORED_REGS; i++) {
> temp = i2c_smbus_read_word_data(client, regs_to_copy[i]);
> - if (temp < 0)
> - data->regs[regs_to_copy[i]] = 0;
> data->regs[regs_to_copy[i]] = temp >> 8;
> }
>
> --
> 2.31.1
>
While ackward, the original looks good enough for now, so I'll drop this
revert.
greg k-h
On Wed, Apr 21, 2021 at 03:00:08PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit eb32cfcdef2305dc0e44a65d42801315669bb27e.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ethernet/qlogic/qla3xxx.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c b/drivers/net/ethernet/qlogic/qla3xxx.c
> index 214e347097a7..50dbb8205e6c 100644
> --- a/drivers/net/ethernet/qlogic/qla3xxx.c
> +++ b/drivers/net/ethernet/qlogic/qla3xxx.c
> @@ -3863,12 +3863,6 @@ static int ql3xxx_probe(struct pci_dev *pdev,
> netif_stop_queue(ndev);
>
> qdev->workqueue = create_singlethread_workqueue(ndev->name);
> - if (!qdev->workqueue) {
> - unregister_netdev(ndev);
> - err = -ENOMEM;
> - goto err_out_iounmap;
> - }
> -
> INIT_DELAYED_WORK(&qdev->reset_work, ql_reset_work);
> INIT_DELAYED_WORK(&qdev->tx_timeout_work, ql_tx_timeout_work);
> INIT_DELAYED_WORK(&qdev->link_state_work, ql_link_state_machine_work);
> --
> 2.31.1
>
Ideally you would have added a new goto tag and put the
unregister_netdev() call in that, but the logic here still seems to be
correct, so I'll drop this revert.
greg k-h
On Wed, Apr 21, 2021 at 03:00:06PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit c7cbc3e937b885c9394bf9d0ca21ceb75c2ac262.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ethernet/8390/pcnet_cs.c | 10 ----------
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/8390/pcnet_cs.c b/drivers/net/ethernet/8390/pcnet_cs.c
> index 9d3b1e0e425c..0a408fa2b7a4 100644
> --- a/drivers/net/ethernet/8390/pcnet_cs.c
> +++ b/drivers/net/ethernet/8390/pcnet_cs.c
> @@ -289,11 +289,6 @@ static struct hw_info *get_hwinfo(struct pcmcia_device *link)
>
> virt = ioremap(link->resource[2]->start,
> resource_size(link->resource[2]));
> - if (unlikely(!virt)) {
> - pcmcia_release_window(link, link->resource[2]);
> - return NULL;
> - }
> -
> for (i = 0; i < NR_INFO; i++) {
> pcmcia_map_mem_page(link, link->resource[2],
> hw_info[i].offset & ~(resource_size(link->resource[2])-1));
> @@ -1430,11 +1425,6 @@ static int setup_shmem_window(struct pcmcia_device *link, int start_pg,
> /* Try scribbling on the buffer */
> info->base = ioremap(link->resource[3]->start,
> resource_size(link->resource[3]));
> - if (unlikely(!info->base)) {
> - ret = -ENOMEM;
> - goto failed;
> - }
> -
> for (i = 0; i < (TX_PAGES<<8); i += 2)
> __raw_writew((i>>1), info->base+offset+i);
> udelay(100);
> --
> 2.31.1
>
This change causes a memory leak on the error path, so I will keep the
revert.
But really, a pcmcia card with a failed ioremap() call? That can never
happen here, so I'll just keep it reverted, it's not worth touching
again.
thanks,
greg k-h
On Tue, Apr 27, 2021 at 06:55:10PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 21, 2021 at 10:03:33AM -0700, Dmitry Torokhov wrote:
> > Hi Greg,
> >
> > On Wed, Apr 21, 2021 at 03:00:32PM +0200, Greg Kroah-Hartman wrote:
> > > This reverts commit e85bb0beb6498c0dffe18a2f1f16d575bc175c32.
> > >
> > > 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 one looks really OK to me and does not have to be reverted (unless
> > Aditya will come clean and show the error introduced?).
>
> I'll drop this revert, but it isn't usually good to be calling printk()
> from an irq.
How else do you suggest we tell that something is wrong when
communicating with the device? For these types of devices the
communication is essentially unsolicited so we can't pass failure to a
caller to deal with it (i.e. unlike USB there is no URB posted that we
could fail and use as a mechanism to signal error to some other layer)
and while we could invent "something went wrong" input event so far
there was no interest in having anything like that.
I'd suggest sending KOBJ_ERROR uevent when a device driver detects
anomaly in the device it controls, but I wonder how systemd would react
given past experiences with KOBJ_BIND/KOBJ_UNBIND.
The message is ratelimited so it will not overfill the logs...
Thanks.
--
Dmitry
On Wed, Apr 21, 2021 at 02:59:31PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit e5b9b206f3f6376b9a1406b67eafe4e7bb9f123c.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Kalle Valo <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/wireless/marvell/mwifiex/cmdevt.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/cmdevt.c b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> index 3a11342a6bde..bda8a236e386 100644
> --- a/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> +++ b/drivers/net/wireless/marvell/mwifiex/cmdevt.c
> @@ -339,12 +339,6 @@ static int mwifiex_dnld_sleep_confirm_cmd(struct mwifiex_adapter *adapter)
> sleep_cfm_tmp =
> dev_alloc_skb(sizeof(struct mwifiex_opt_sleep_confirm)
> + MWIFIEX_TYPE_LEN);
> - if (!sleep_cfm_tmp) {
> - mwifiex_dbg(adapter, ERROR,
> - "SLEEP_CFM: dev_alloc_skb failed\n");
> - return -ENOMEM;
> - }
> -
> skb_put(sleep_cfm_tmp, sizeof(struct mwifiex_opt_sleep_confirm)
> + MWIFIEX_TYPE_LEN);
> put_unaligned_le32(MWIFIEX_USB_TYPE_CMD, sleep_cfm_tmp->data);
> --
> 2.31.1
>
This looks fine, I'll drop this revert.
greg k-h
On Wed, Apr 21, 2021 at 02:59:07PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 60f5c4aaae452ae9252128ef7f9ae222aa70c569.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> net/atm/clip.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/atm/clip.c b/net/atm/clip.c
> index 294cb9efe3d3..a7972da7235d 100644
> --- a/net/atm/clip.c
> +++ b/net/atm/clip.c
> @@ -89,7 +89,7 @@ static void unlink_clip_vcc(struct clip_vcc *clip_vcc)
> struct clip_vcc **walk;
>
> if (!entry) {
> - pr_err("!clip_vcc->entry (clip_vcc %p)\n", clip_vcc);
> + pr_crit("!clip_vcc->entry (clip_vcc %p)\n", clip_vcc);
> return;
> }
> netif_tx_lock_bh(entry->neigh->dev); /* block clip_start_xmit() */
> @@ -109,10 +109,10 @@ static void unlink_clip_vcc(struct clip_vcc *clip_vcc)
> error = neigh_update(entry->neigh, NULL, NUD_NONE,
> NEIGH_UPDATE_F_ADMIN, 0);
> if (error)
> - pr_err("neigh_update failed with %d\n", error);
> + pr_crit("neigh_update failed with %d\n", error);
> goto out;
> }
> - pr_err("ATMARP: failed (entry %p, vcc 0x%p)\n", entry, clip_vcc);
> + pr_crit("ATMARP: failed (entry %p, vcc 0x%p)\n", entry, clip_vcc);
> out:
> netif_tx_unlock_bh(entry->neigh->dev);
> }
> --
> 2.31.1
>
The original here was pointless, but did not cause a problem, so I'll
drop this revert.
greg k-h
On Wed, Apr 21, 2021 at 02:59:11PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 20d437ee8f4899573e6ea76c06ef0206e98bccb6.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Andrew Bowers <[email protected]>
> Cc: Mukesh Ojha <[email protected]>
> Cc: Jeff Kirsher <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ethernet/intel/ixgbevf/vf.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
> index bfe6dfcec4ab..501823f2d1c0 100644
> --- a/drivers/net/ethernet/intel/ixgbevf/vf.c
> +++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
> @@ -508,8 +508,9 @@ static s32 ixgbevf_update_mc_addr_list_vf(struct ixgbe_hw *hw,
> vector_list[i++] = ixgbevf_mta_vector(hw, ha->addr);
> }
>
> - return ixgbevf_write_msg_read_ack(hw, msgbuf, msgbuf,
> - IXGBE_VFMAILBOX_SIZE);
> + ixgbevf_write_msg_read_ack(hw, msgbuf, msgbuf, IXGBE_VFMAILBOX_SIZE);
> +
> + return 0;
> }
>
> /**
> --
> 2.31.1
>
This commit is fine, I'll drop the revert.
greg k-h
On Wed, Apr 21, 2021 at 02:59:02PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit c5dea815834c7d2e9fc633785455bc428b7a1956.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/caif/caif_serial.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/caif/caif_serial.c b/drivers/net/caif/caif_serial.c
> index 8215cd77301f..4720a7bac4fb 100644
> --- a/drivers/net/caif/caif_serial.c
> +++ b/drivers/net/caif/caif_serial.c
> @@ -269,9 +269,7 @@ static netdev_tx_t caif_xmit(struct sk_buff *skb, struct net_device *dev)
> {
> struct ser_device *ser;
>
> - if (WARN_ON(!dev))
> - return -EINVAL;
> -
> + BUG_ON(dev == NULL);
> ser = netdev_priv(dev);
>
> /* Send flow off once, on high water mark */
> --
> 2.31.1
>
This commit was pointless, the check should just be removed entirely as
it is impossible to hit. I'll keep the revert and fix it up properly in
a follow-on patch.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 03:00:03PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 228cd2dba27cee9956c1af97e6445be056881e41.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> net/strparser/strparser.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/net/strparser/strparser.c b/net/strparser/strparser.c
> index b3815c1e8f2e..efce4ddaa320 100644
> --- a/net/strparser/strparser.c
> +++ b/net/strparser/strparser.c
> @@ -542,8 +542,6 @@ EXPORT_SYMBOL_GPL(strp_check_rcv);
> static int __init strp_dev_init(void)
> {
> strp_wq = create_singlethread_workqueue("kstrp");
> - if (unlikely(!strp_wq))
> - return -ENOMEM;
>
> return 0;
> }
> --
> 2.31.1
>
In the original commit "unlikely" should not have been used as it is not
needed at all (the compiler and CPU already know this), but the commit
is correct so I'll drop this revert.
greg k-h
On Wed, Apr 21, 2021 at 03:00:07PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 9f4d6358e11bbc7b839f9419636188e4151fb6e4.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ethernet/fujitsu/fmvj18x_cs.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/fujitsu/fmvj18x_cs.c b/drivers/net/ethernet/fujitsu/fmvj18x_cs.c
> index a7b7a4aace79..dc90c61fc827 100644
> --- a/drivers/net/ethernet/fujitsu/fmvj18x_cs.c
> +++ b/drivers/net/ethernet/fujitsu/fmvj18x_cs.c
> @@ -547,11 +547,6 @@ static int fmvj18x_get_hwinfo(struct pcmcia_device *link, u_char *node_id)
> return -1;
>
> base = ioremap(link->resource[2]->start, resource_size(link->resource[2]));
> - if (!base) {
> - pcmcia_release_window(link, link->resource[2]);
> - return -ENOMEM;
> - }
> -
> pcmcia_map_mem_page(link, link->resource[2], 0);
>
> /*
> --
> 2.31.1
>
Original commit looks correct here, I'll drop the revert.
greg k-h
On Wed, Apr 21, 2021 at 03:00:00PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 4589e28db46ee4961edfd794c5bb43887d38c8e5.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> net/tipc/group.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/net/tipc/group.c b/net/tipc/group.c
> index 3e137d8c9d2f..d18d497af4de 100644
> --- a/net/tipc/group.c
> +++ b/net/tipc/group.c
> @@ -927,9 +927,6 @@ int tipc_group_fill_sock_diag(struct tipc_group *grp, struct sk_buff *skb)
> {
> struct nlattr *group = nla_nest_start_noflag(skb, TIPC_NLA_SOCK_GROUP);
>
> - if (!group)
> - return -EMSGSIZE;
> -
> if (nla_put_u32(skb, TIPC_NLA_SOCK_GROUP_ID,
> grp->type) ||
> nla_put_u32(skb, TIPC_NLA_SOCK_GROUP_INSTANCE,
> --
> 2.31.1
>
The original commit here was fine, I'll drop this revert.
greg k-h
On Wed, Apr 21, 2021 at 03:00:09PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit e406f12dde1a8375d77ea02d91f313fb1a9c6aec.
>
> 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.
>
> Cc: [email protected] # v3.16+
> Cc: Guoqing Jiang <[email protected]>
> Cc: Aditya Pakki <[email protected]>
> Cc: Song Liu <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/md/raid10.c | 2 --
> drivers/md/raid5.c | 2 --
> 2 files changed, 4 deletions(-)
>
> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> index a9ae7d113492..4fec1cdd4207 100644
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
> @@ -3896,8 +3896,6 @@ static int raid10_run(struct mddev *mddev)
> set_bit(MD_RECOVERY_RUNNING, &mddev->recovery);
> mddev->sync_thread = md_register_thread(md_do_sync, mddev,
> "reshape");
> - if (!mddev->sync_thread)
> - goto out_free_conf;
> }
>
> return 0;
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 5d57a5bd171f..9b2bd50beee7 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -7677,8 +7677,6 @@ static int raid5_run(struct mddev *mddev)
> set_bit(MD_RECOVERY_RUNNING, &mddev->recovery);
> mddev->sync_thread = md_register_thread(md_do_sync, mddev,
> "reshape");
> - if (!mddev->sync_thread)
> - goto abort;
> }
>
> /* Ok, everything is just fine now */
> --
> 2.31.1
>
These changes look ok, but the error handling logic seems to be freeing
the incorrect thread, not the one that these functions create. That's
independant of this change, but seems odd. If someone cares about it,
it should probably be looked at, or if correct, a comment would be nice
as it's really confusing.
Dropping this revert.
greg k-h
Am Wed, Apr 28, 2021 at 07:40:49AM +0200 schrieb Greg Kroah-Hartman:
> On Wed, Apr 21, 2021 at 03:00:07PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 9f4d6358e11bbc7b839f9419636188e4151fb6e4.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: David S. Miller <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/net/ethernet/fujitsu/fmvj18x_cs.c | 5 -----
> > 1 file changed, 5 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/fujitsu/fmvj18x_cs.c b/drivers/net/ethernet/fujitsu/fmvj18x_cs.c
> > index a7b7a4aace79..dc90c61fc827 100644
> > --- a/drivers/net/ethernet/fujitsu/fmvj18x_cs.c
> > +++ b/drivers/net/ethernet/fujitsu/fmvj18x_cs.c
> > @@ -547,11 +547,6 @@ static int fmvj18x_get_hwinfo(struct pcmcia_device *link, u_char *node_id)
> > return -1;
> >
> > base = ioremap(link->resource[2]->start, resource_size(link->resource[2]));
> > - if (!base) {
> > - pcmcia_release_window(link, link->resource[2]);
> > - return -ENOMEM;
> > - }
> > -
> > pcmcia_map_mem_page(link, link->resource[2], 0);
> >
> > /*
> > --
> > 2.31.1
> >
>
> Original commit looks correct here, I'll drop the revert.
NAK. The only caller of that function checks only for "== -1" as error
condition, so this error is not handled correctly. So this patch was/is
obviously broken.
Thanks,
Dominik
On Wed, Apr 28, 2021 at 07:54:34AM +0200, Dominik Brodowski wrote:
> Am Wed, Apr 28, 2021 at 07:40:49AM +0200 schrieb Greg Kroah-Hartman:
> > On Wed, Apr 21, 2021 at 03:00:07PM +0200, Greg Kroah-Hartman wrote:
> > > This reverts commit 9f4d6358e11bbc7b839f9419636188e4151fb6e4.
> > >
> > > 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.
> > >
> > > Cc: Kangjie Lu <[email protected]>
> > > Cc: David S. Miller <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > ---
> > > drivers/net/ethernet/fujitsu/fmvj18x_cs.c | 5 -----
> > > 1 file changed, 5 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/fujitsu/fmvj18x_cs.c b/drivers/net/ethernet/fujitsu/fmvj18x_cs.c
> > > index a7b7a4aace79..dc90c61fc827 100644
> > > --- a/drivers/net/ethernet/fujitsu/fmvj18x_cs.c
> > > +++ b/drivers/net/ethernet/fujitsu/fmvj18x_cs.c
> > > @@ -547,11 +547,6 @@ static int fmvj18x_get_hwinfo(struct pcmcia_device *link, u_char *node_id)
> > > return -1;
> > >
> > > base = ioremap(link->resource[2]->start, resource_size(link->resource[2]));
> > > - if (!base) {
> > > - pcmcia_release_window(link, link->resource[2]);
> > > - return -ENOMEM;
> > > - }
> > > -
> > > pcmcia_map_mem_page(link, link->resource[2], 0);
> > >
> > > /*
> > > --
> > > 2.31.1
> > >
> >
> > Original commit looks correct here, I'll drop the revert.
>
> NAK. The only caller of that function checks only for "== -1" as error
> condition, so this error is not handled correctly. So this patch was/is
> obviously broken.
Ah, missed that, thanks! I'll keep the revert and then submit a fix for
this properly.
Many thanks for the re-review.
greg k-h
On Wed, Apr 21, 2021 at 03:00:48PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 26fd962bde0b15e54234fe762d86bc0349df1de4.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Shannon Nelson <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/net/ethernet/sun/niu.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
> index 707ccdd03b19..d70cdea756d1 100644
> --- a/drivers/net/ethernet/sun/niu.c
> +++ b/drivers/net/ethernet/sun/niu.c
> @@ -8097,8 +8097,6 @@ static int niu_pci_vpd_scan_props(struct niu *np, u32 start, u32 end)
> start += 3;
>
> prop_len = niu_pci_eeprom_read(np, start + 4);
> - if (prop_len < 0)
> - return prop_len;
> err = niu_pci_vpd_get_propname(np, start + 5, namebuf, 64);
> if (err < 0)
> return err;
> @@ -8143,12 +8141,8 @@ static int niu_pci_vpd_scan_props(struct niu *np, u32 start, u32 end)
> netif_printk(np, probe, KERN_DEBUG, np->dev,
> "VPD_SCAN: Reading in property [%s] len[%d]\n",
> namebuf, prop_len);
> - for (i = 0; i < prop_len; i++) {
> - err = niu_pci_eeprom_read(np, off + i);
> - if (err >= 0)
> - *prop_buf = err;
> - ++prop_buf;
> - }
> + for (i = 0; i < prop_len; i++)
> + *prop_buf++ = niu_pci_eeprom_read(np, off + i);
> }
>
> start += len;
> --
> 2.31.1
>
The commit here was incorrect, while it is nice to check if
niu_pci_eeprom_read() succeeded or not when using the data, any error
that might have happened was not propagated upwards properly, causing
the kernel to assume that these reads were successful, which results in
invalid data in the buffer that was to contain the successfully read
data.
I will keep the revert and fix this up properly in a latter submission.
greg k-h
On Wed, Apr 21, 2021 at 02:58:26PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit a6379f0ad6375a707e915518ecd5c2270afcd395.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: David S. Miller <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> lib/test_objagg.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lib/test_objagg.c b/lib/test_objagg.c
> index da137939a410..72c1abfa154d 100644
> --- a/lib/test_objagg.c
> +++ b/lib/test_objagg.c
> @@ -979,10 +979,10 @@ static int test_hints_case(const struct hints_case *hints_case)
> err_world2_obj_get:
> for (i--; i >= 0; i--)
> world_obj_put(&world2, objagg, hints_case->key_ids[i]);
> - i = hints_case->key_ids_count;
> + objagg_hints_put(hints);
> objagg_destroy(objagg2);
> + i = hints_case->key_ids_count;
> err_check_expect_hints_stats:
> - objagg_hints_put(hints);
> err_hints_get:
> err_check_expect_stats:
> err_world_obj_get:
> --
> 2.31.1
>
This commit looks correct to me, so I will drop the revert.
greg k-h
On Thu, Apr 22, 2021 at 10:08:45AM +0200, Ulf Hansson wrote:
> On Wed, 21 Apr 2021 at 15:19, Laurent Pinchart
> <[email protected]> wrote:
> >
> > Hi Greg,
> >
> > Thank you for the patch.
> >
> > On Wed, Apr 21, 2021 at 02:59:23PM +0200, Greg Kroah-Hartman wrote:
> > > This reverts commit 611025983b7976df0183390a63a2166411d177f1.
> > >
> > > 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.
> > >
> > > Cc: Kangjie Lu <[email protected]>
> > > Cc: Laurent Pinchart <[email protected]>
> > > Cc: Ulf Hansson <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >
> > Acked-by: Laurent Pinchart <[email protected]>
> >
> > I don't spot an obvious issue with the original patch though.
> >
> > > ---
> > > drivers/mmc/host/mmc_spi.c | 4 ----
> > > 1 file changed, 4 deletions(-)
> > >
> > > diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
> > > index 02f4fd26e76a..cc40b050e302 100644
> > > --- a/drivers/mmc/host/mmc_spi.c
> > > +++ b/drivers/mmc/host/mmc_spi.c
> > > @@ -800,10 +800,6 @@ mmc_spi_readblock(struct mmc_spi_host *host, struct spi_transfer *t,
> > > }
> > >
> > > status = spi_sync_locked(spi, &host->m);
> > > - if (status < 0) {
> > > - dev_dbg(&spi->dev, "read error %d\n", status);
> > > - return status;
> > > - }
>
> Returning here means we never give back the ownership of the buffer to
> the CPU. Can that be considered as vulnerability?
It's a "resource leak", which is a bug. If you want to declare that as
a "vulnerability" or not, I do not know. Personally I do not think it
is...
> If that is that a problem, I can point out that there is already one
> more case in this file, where this pattern is repeated. See
> mmc_spi_writeblock(). This code has been there since 2007.
Yeah, these error paths are impossible to hit anyway.
I'll go drop this patch as it is not correct and will create a "correct"
patch for this as well.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 04:19:07PM +0300, Laurent Pinchart wrote:
> Hi Greg,
>
> Thank you for the patch.
>
> On Wed, Apr 21, 2021 at 02:59:23PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 611025983b7976df0183390a63a2166411d177f1.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: Laurent Pinchart <[email protected]>
> > Cc: Ulf Hansson <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> Acked-by: Laurent Pinchart <[email protected]>
Thanks for the review!
> I don't spot an obvious issue with the original patch though.
Ulf did :)
Hi Greg,
On Wed, Apr 28, 2021 at 09:18:03AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Apr 22, 2021 at 10:08:45AM +0200, Ulf Hansson wrote:
> > On Wed, 21 Apr 2021 at 15:19, Laurent Pinchart wrote:
> > > On Wed, Apr 21, 2021 at 02:59:23PM +0200, Greg Kroah-Hartman wrote:
> > > > This reverts commit 611025983b7976df0183390a63a2166411d177f1.
> > > >
> > > > 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.
> > > >
> > > > Cc: Kangjie Lu <[email protected]>
> > > > Cc: Laurent Pinchart <[email protected]>
> > > > Cc: Ulf Hansson <[email protected]>
> > > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > >
> > > Acked-by: Laurent Pinchart <[email protected]>
> > >
> > > I don't spot an obvious issue with the original patch though.
> > >
> > > > ---
> > > > drivers/mmc/host/mmc_spi.c | 4 ----
> > > > 1 file changed, 4 deletions(-)
> > > >
> > > > diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
> > > > index 02f4fd26e76a..cc40b050e302 100644
> > > > --- a/drivers/mmc/host/mmc_spi.c
> > > > +++ b/drivers/mmc/host/mmc_spi.c
> > > > @@ -800,10 +800,6 @@ mmc_spi_readblock(struct mmc_spi_host *host, struct spi_transfer *t,
> > > > }
> > > >
> > > > status = spi_sync_locked(spi, &host->m);
> > > > - if (status < 0) {
> > > > - dev_dbg(&spi->dev, "read error %d\n", status);
> > > > - return status;
> > > > - }
> >
> > Returning here means we never give back the ownership of the buffer to
> > the CPU. Can that be considered as vulnerability?
>
> It's a "resource leak", which is a bug. If you want to declare that as
> a "vulnerability" or not, I do not know. Personally I do not think it
> is...
How is that a resource leak ? The dma_sync_single_for_device() calls
above this block don't take the buffer ownership away from the CPU in a
way that leaks it.
> > If that is that a problem, I can point out that there is already one
> > more case in this file, where this pattern is repeated. See
> > mmc_spi_writeblock(). This code has been there since 2007.
>
> Yeah, these error paths are impossible to hit anyway.
>
> I'll go drop this patch as it is not correct and will create a "correct"
> patch for this as well.
--
Regards,
Laurent Pinchart
Hi Greg,
On Wed, Apr 28, 2021 at 09:18:18AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 21, 2021 at 04:19:07PM +0300, Laurent Pinchart wrote:
> > On Wed, Apr 21, 2021 at 02:59:23PM +0200, Greg Kroah-Hartman wrote:
> > > This reverts commit 611025983b7976df0183390a63a2166411d177f1.
> > >
> > > 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.
> > >
> > > Cc: Kangjie Lu <[email protected]>
> > > Cc: Laurent Pinchart <[email protected]>
> > > Cc: Ulf Hansson <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >
> > Acked-by: Laurent Pinchart <[email protected]>
>
> Thanks for the review!
>
> > I don't spot an obvious issue with the original patch though.
>
> Ulf did :)
I've replied separately, I still think it's not an issue :-)
--
Regards,
Laurent Pinchart
On Wed, Apr 21, 2021 at 02:59:37PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit aeb0d0f581e2079868e64a2e5ee346d340376eae.
>
> 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.
>
> Cc: Kangjie Lu <[email protected]>
> Cc: Philipp Zabel <[email protected]>
> Cc: Hans Verkuil <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/media/platform/video-mux.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/media/platform/video-mux.c b/drivers/media/platform/video-mux.c
> index 133122e38515..a754e20850c2 100644
> --- a/drivers/media/platform/video-mux.c
> +++ b/drivers/media/platform/video-mux.c
> @@ -442,14 +442,9 @@ static int video_mux_probe(struct platform_device *pdev)
> vmux->active = -1;
> vmux->pads = devm_kcalloc(dev, num_pads, sizeof(*vmux->pads),
> GFP_KERNEL);
> - if (!vmux->pads)
> - return -ENOMEM;
> -
> vmux->format_mbus = devm_kcalloc(dev, num_pads,
> sizeof(*vmux->format_mbus),
> GFP_KERNEL);
> - if (!vmux->format_mbus)
> - return -ENOMEM;
>
> for (i = 0; i < num_pads; i++) {
> vmux->pads[i].flags = (i < num_pads - 1) ? MEDIA_PAD_FL_SINK
> --
> 2.31.1
>
This looks correct, dropping from revert list.
greg k-h
On Tue, Apr 27, 2021 at 08:34:26PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 21, 2021 at 03:00:06PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit c7cbc3e937b885c9394bf9d0ca21ceb75c2ac262.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: David S. Miller <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/net/ethernet/8390/pcnet_cs.c | 10 ----------
> > 1 file changed, 10 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/8390/pcnet_cs.c b/drivers/net/ethernet/8390/pcnet_cs.c
> > index 9d3b1e0e425c..0a408fa2b7a4 100644
> > --- a/drivers/net/ethernet/8390/pcnet_cs.c
> > +++ b/drivers/net/ethernet/8390/pcnet_cs.c
> > @@ -289,11 +289,6 @@ static struct hw_info *get_hwinfo(struct pcmcia_device *link)
> >
> > virt = ioremap(link->resource[2]->start,
> > resource_size(link->resource[2]));
> > - if (unlikely(!virt)) {
> > - pcmcia_release_window(link, link->resource[2]);
> > - return NULL;
> > - }
> > -
> > for (i = 0; i < NR_INFO; i++) {
> > pcmcia_map_mem_page(link, link->resource[2],
> > hw_info[i].offset & ~(resource_size(link->resource[2])-1));
> > @@ -1430,11 +1425,6 @@ static int setup_shmem_window(struct pcmcia_device *link, int start_pg,
> > /* Try scribbling on the buffer */
> > info->base = ioremap(link->resource[3]->start,
> > resource_size(link->resource[3]));
> > - if (unlikely(!info->base)) {
> > - ret = -ENOMEM;
> > - goto failed;
> > - }
> > -
> > for (i = 0; i < (TX_PAGES<<8); i += 2)
> > __raw_writew((i>>1), info->base+offset+i);
> > udelay(100);
> > --
> > 2.31.1
> >
>
> This change causes a memory leak on the error path, so I will keep the
> revert.
>
> But really, a pcmcia card with a failed ioremap() call? That can never
> happen here, so I'll just keep it reverted, it's not worth touching
> again.
I'm afraid that I have to disagree with your analysis.
However, first thing is, it would help immensely if you actually said
where the memory leak is, rather than using this boiler plate and
rushing through the changes.
On IRC, you mentioned it was due to the change in setup_shmem_window(),
specifically "no call to pcmcia_release_window()". This seems to imply
that you have no problem with the change to get_hwinfo(), and indeed
that part of the original change looks fully correct to me. So,
concentrating on the setup_shmem_window() change in this patch:
First, let's analyse pcmcia_request_window() and pcmcia_release_window().
pcmcia_request_window() allocates some memory for a struct resource,
which pcmcia_release_window() releases. So, on the face of it, calling
the former without a subsequent call to the latter looks like a memory
leak, unless one gets a deeper understanding first.
When pcmcia_request_window() is called and is successful, the resource
is marked with the window number that has been allocated to it, which
is always non-zero:
#define WIN_FLAGS_REQ 0x1c
/* Configure the socket controller */
win->map = w+1;
...
res->flags &= ~WIN_FLAGS_REQ;
res->flags |= (win->map << 2) | IORESOURCE_MEM;
When a window is released, this is checked:
w = ((res->flags & IORESOURCE_BITS & WIN_FLAGS_REQ) >> 2) - 1;
if (w >= MAX_WIN)
return -EINVAL;
However, there is another path where a driver's resources are released,
which is if the driver makes a call to pcmcia_disable_device():
for (i = 0; i < MAX_WIN; i++) {
struct resource *res = p_dev->resource[MAX_IO_WIN + i];
if (res->flags & WIN_FLAGS_REQ)
pcmcia_release_window(p_dev, res);
}
This walks all the memory resources for the card, releasing any that are
currently requested (have non-zero WIN_FLAGS_REQ bits) at the time of
this call.
pcnet_cs makes a call to pcmcia_disable_device() from pcnet_release()
which is called in two cases: firstly on any probe failure, and secondly
on device removal in pcnet_detach().
Consequently, the best that can be said about the setup_shmem_window()
memory leak is that it is a temporary leak - the allocated memory will
be freed if either the probe eventually fails, or the driver is unbound.
Second point. setup_shmem_window() "failure" itself does not lead to
probe failure. The function returns a value that indicates whether shmem
can be used by the driver or not - it needs a subsequent call to fail.
setup_shmem_window() merely returns a value to indicate whether shmem
should be configured or not.
Third point. setup_shmem_window() can already "leak" this window
allocation. If pcmcia_map_mem_page() fails, then the window is not
released in a timely fashion. So, the "leak" is pre-existing in this
driver, and the "leak" introduced by this patch already exists in
other paths.
Fourth point. If setup_shmem_window() is successful, which means we use
shmem, and we then fail to register the netdev in the subsequent
register_netdev() call, we are reliant on pcmcia_disable_device() to
clean up that allocation. We are also reliant on pcmcia_disable_device()
to clean that up when the driver is unbound. So, this is an entirely
normal state of affairs to rely on the action of this call to clean up
these resources.
Fifth point. The effect of reverting the original patch will be a kernel
oops should this ioremap() fail:
info->base = ioremap(link->resource[3]->start,
resource_size(link->resource[3]));
- if (unlikely(!info->base)) {
- ret = -ENOMEM;
- goto failed;
- }
-
for (i = 0; i < (TX_PAGES<<8); i += 2)
__raw_writew((i>>1), info->base+offset+i);
^^^^^^^^^^^^^^^^^^^^
So, is the patch of net benefit or net harm?
1) it does not introduce any new issue that doesn't already exist. The
driver has a short-term memory leak in certain circumstances already
that is cleaned up via the normal action of other pcmcia_* calls.
2) it removes an opportunity for a NULL or close-to-NULL pointer
dereference.
Therefore, the original patch is of net _benefit_ and should not be
reverted.
It would have been nice to have had a patch that addresses the
temporary leak in the driver, but I really don't see that as any
justification for reverting this patch. Therefore, I NAK your revert of
this change as that will result in more harm than good.
You said on IRC early this morning when you thought there was still a
leak in the probe path: "the leak happens from probe, that is where it
needs to be cleaned up properly, the patch was incorrect. You owe me
a bottle of wine for even debating this crap..."
I think you now owe me more than just a bottle of wine... and I think
you need to realise that your attitude also needs to be altered. Yes,
I fully understand _why_ you made that comment - it's because you're
swamped. However, we *need* to review and debate your reverts, and that
is something you should DEFINITELY NOT be discouraging with such
comments. If we discourage review and debate in the way you seem to be
doing when someone raises a concern, we're yet again proving that our
approach to review is broken.
It really concerns me that there seems to be a slap-dash attitude here,
and push-back when one of your fellow kernel developers disagrees with
your abbreviated unexplained analysis.
Are you sure you aren't causing harm?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Tue, Apr 27, 2021 at 04:52:14PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 21, 2021 at 03:00:43PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit 92ee77d148bf06d8c52664be4d1b862583fd5c0e.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: David S. Miller <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > index 1767c60056c5..f1a70b37227f 100644
> > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > @@ -7328,8 +7328,6 @@ static int mvpp2_probe(struct platform_device *pdev)
> > if (has_acpi_companion(&pdev->dev)) {
> > acpi_id = acpi_match_device(pdev->dev.driver->acpi_match_table,
> > &pdev->dev);
> > - if (!acpi_id)
> > - return -EINVAL;
> > priv->hw_version = (unsigned long)acpi_id->driver_data;
> > } else {
> > priv->hw_version =
> > --
> > 2.31.1
> >
>
> The original commit here looks correct, so I'll drop this revert.
Agreed, the original patch looks fine to me and the revert is
unnecessary.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Tue, Apr 27, 2021 at 12:22:12PM -0700, Dmitry Torokhov wrote:
> On Tue, Apr 27, 2021 at 06:55:10PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Apr 21, 2021 at 10:03:33AM -0700, Dmitry Torokhov wrote:
> > > Hi Greg,
> > >
> > > On Wed, Apr 21, 2021 at 03:00:32PM +0200, Greg Kroah-Hartman wrote:
> > > > This reverts commit e85bb0beb6498c0dffe18a2f1f16d575bc175c32.
> > > >
> > > > 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 one looks really OK to me and does not have to be reverted (unless
> > > Aditya will come clean and show the error introduced?).
> >
> > I'll drop this revert, but it isn't usually good to be calling printk()
> > from an irq.
>
> How else do you suggest we tell that something is wrong when
> communicating with the device? For these types of devices the
> communication is essentially unsolicited so we can't pass failure to a
> caller to deal with it (i.e. unlike USB there is no URB posted that we
> could fail and use as a mechanism to signal error to some other layer)
> and while we could invent "something went wrong" input event so far
> there was no interest in having anything like that.
>
> I'd suggest sending KOBJ_ERROR uevent when a device driver detects
> anomaly in the device it controls, but I wonder how systemd would react
> given past experiences with KOBJ_BIND/KOBJ_UNBIND.
>
> The message is ratelimited so it will not overfill the logs...
Sending uevents from an irq is not a good idea, as you say :)
I don't know what the best way to "fail" this is, a ratelimited printk()
seems to be about all you can do. Luckily hardware doesn't fail that
often in this manner.
thanks,
greg k-h
On Wed, Apr 21, 2021 at 02:59:26PM +0200, Greg Kroah-Hartman wrote:
> This reverts commit 1adc90c7395742827d754a5f02f446818a77c379.
>
> 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.
>
> Cc: Aditya Pakki <[email protected]>
> Cc: Linus Walleij <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/pinctrl/pinctrl-axp209.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-axp209.c b/drivers/pinctrl/pinctrl-axp209.c
> index 207cbae3a7bf..58f7149dd39b 100644
> --- a/drivers/pinctrl/pinctrl-axp209.c
> +++ b/drivers/pinctrl/pinctrl-axp209.c
> @@ -365,8 +365,6 @@ static int axp20x_build_funcs_groups(struct platform_device *pdev)
> pctl->funcs[i].groups = devm_kcalloc(&pdev->dev,
> npins, sizeof(char *),
> GFP_KERNEL);
> - if (!pctl->funcs[i].groups)
> - return -ENOMEM;
> for (pin = 0; pin < npins; pin++)
> pctl->funcs[i].groups[pin] = pctl->desc->pins[pin].name;
> }
> --
> 2.31.1
>
This change looks correct, dropping the revert from my tree.
greg k-h
On Wed, Apr 28, 2021 at 11:08:47AM +0100, Russell King - ARM Linux admin wrote:
> On Tue, Apr 27, 2021 at 08:34:26PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Apr 21, 2021 at 03:00:06PM +0200, Greg Kroah-Hartman wrote:
> > > This reverts commit c7cbc3e937b885c9394bf9d0ca21ceb75c2ac262.
> > >
> > > 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.
> > >
> > > Cc: Kangjie Lu <[email protected]>
> > > Cc: David S. Miller <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > ---
> > > drivers/net/ethernet/8390/pcnet_cs.c | 10 ----------
> > > 1 file changed, 10 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/8390/pcnet_cs.c b/drivers/net/ethernet/8390/pcnet_cs.c
> > > index 9d3b1e0e425c..0a408fa2b7a4 100644
> > > --- a/drivers/net/ethernet/8390/pcnet_cs.c
> > > +++ b/drivers/net/ethernet/8390/pcnet_cs.c
> > > @@ -289,11 +289,6 @@ static struct hw_info *get_hwinfo(struct pcmcia_device *link)
> > >
> > > virt = ioremap(link->resource[2]->start,
> > > resource_size(link->resource[2]));
> > > - if (unlikely(!virt)) {
> > > - pcmcia_release_window(link, link->resource[2]);
> > > - return NULL;
> > > - }
> > > -
> > > for (i = 0; i < NR_INFO; i++) {
> > > pcmcia_map_mem_page(link, link->resource[2],
> > > hw_info[i].offset & ~(resource_size(link->resource[2])-1));
> > > @@ -1430,11 +1425,6 @@ static int setup_shmem_window(struct pcmcia_device *link, int start_pg,
> > > /* Try scribbling on the buffer */
> > > info->base = ioremap(link->resource[3]->start,
> > > resource_size(link->resource[3]));
> > > - if (unlikely(!info->base)) {
> > > - ret = -ENOMEM;
> > > - goto failed;
> > > - }
> > > -
> > > for (i = 0; i < (TX_PAGES<<8); i += 2)
> > > __raw_writew((i>>1), info->base+offset+i);
> > > udelay(100);
> > > --
> > > 2.31.1
> > >
> >
> > This change causes a memory leak on the error path, so I will keep the
> > revert.
> >
> > But really, a pcmcia card with a failed ioremap() call? That can never
> > happen here, so I'll just keep it reverted, it's not worth touching
> > again.
>
> I'm afraid that I have to disagree with your analysis.
>
> However, first thing is, it would help immensely if you actually said
> where the memory leak is, rather than using this boiler plate and
> rushing through the changes.
>
> On IRC, you mentioned it was due to the change in setup_shmem_window(),
> specifically "no call to pcmcia_release_window()". This seems to imply
> that you have no problem with the change to get_hwinfo(), and indeed
> that part of the original change looks fully correct to me. So,
> concentrating on the setup_shmem_window() change in this patch:
<snip>
Fair enough, I'll drop this revert from my tree as you feel the original
commit was correct.
thanks for the review.
greg k-h
On Wed, Apr 28, 2021 at 6:47 AM Russell King - ARM Linux admin
<[email protected]> wrote:
>
> On Tue, Apr 27, 2021 at 04:52:14PM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Apr 21, 2021 at 03:00:43PM +0200, Greg Kroah-Hartman wrote:
> > > This reverts commit 92ee77d148bf06d8c52664be4d1b862583fd5c0e.
> > >
> > > 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.
> > >
> > > Cc: Kangjie Lu <[email protected]>
> > > Cc: David S. Miller <[email protected]>
> > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > ---
> > > drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 --
> > > 1 file changed, 2 deletions(-)
> > >
> > > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > index 1767c60056c5..f1a70b37227f 100644
> > > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > @@ -7328,8 +7328,6 @@ static int mvpp2_probe(struct platform_device *pdev)
> > > if (has_acpi_companion(&pdev->dev)) {
> > > acpi_id = acpi_match_device(pdev->dev.driver->acpi_match_table,
> > > &pdev->dev);
> > > - if (!acpi_id)
> > > - return -EINVAL;
> > > priv->hw_version = (unsigned long)acpi_id->driver_data;
> > > } else {
> > > priv->hw_version =
> > > --
> > > 2.31.1
> > >
> >
> > The original commit here looks correct, so I'll drop this revert.
>
> Agreed, the original patch looks fine to me and the revert is
> unnecessary.
I wonder how useful these kinds of patches/checks are. If we are
dealing with ACPI platform device we must have matched on ACPI node
before getting into the probe, so we would match here as well. The
exception would be someone playing with "driver_override" device
attribute, but that someone must be root as therefore have many
options of shooting themselves into foot. So I guess the question is:
do we need to bloat the code with such checks?
Thanks.
--
Dmitry
On Wed, Apr 28, 2021 at 12:50:16PM -0700, Dmitry Torokhov wrote:
> On Wed, Apr 28, 2021 at 6:47 AM Russell King - ARM Linux admin
> <[email protected]> wrote:
> >
> > On Tue, Apr 27, 2021 at 04:52:14PM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Apr 21, 2021 at 03:00:43PM +0200, Greg Kroah-Hartman wrote:
> > > > This reverts commit 92ee77d148bf06d8c52664be4d1b862583fd5c0e.
> > > >
> > > > 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.
> > > >
> > > > Cc: Kangjie Lu <[email protected]>
> > > > Cc: David S. Miller <[email protected]>
> > > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > > ---
> > > > drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 --
> > > > 1 file changed, 2 deletions(-)
> > > >
> > > > diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > > index 1767c60056c5..f1a70b37227f 100644
> > > > --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > > +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> > > > @@ -7328,8 +7328,6 @@ static int mvpp2_probe(struct platform_device *pdev)
> > > > if (has_acpi_companion(&pdev->dev)) {
> > > > acpi_id = acpi_match_device(pdev->dev.driver->acpi_match_table,
> > > > &pdev->dev);
> > > > - if (!acpi_id)
> > > > - return -EINVAL;
> > > > priv->hw_version = (unsigned long)acpi_id->driver_data;
> > > > } else {
> > > > priv->hw_version =
> > > > --
> > > > 2.31.1
> > > >
> > >
> > > The original commit here looks correct, so I'll drop this revert.
> >
> > Agreed, the original patch looks fine to me and the revert is
> > unnecessary.
>
> I wonder how useful these kinds of patches/checks are. If we are
> dealing with ACPI platform device we must have matched on ACPI node
> before getting into the probe, so we would match here as well. The
> exception would be someone playing with "driver_override" device
> attribute, but that someone must be root as therefore have many
> options of shooting themselves into foot. So I guess the question is:
> do we need to bloat the code with such checks?
It's probably way too late now to think about it (due to the quantity
of drivers) but in many cases, it seems there's a pattern. On probe,
re-lookup the matching ID to fetch the data pointer, and store it in
some way. Had we known that such a pattern would be common, it probably
would have been a good idea to provide a "match_data" member inside
struct device, which the bus probe code can set appropriately from the
match tables. That would also have the benefit of elimianting any
patches such as this, and likely would reduce bloat too.
As I say, likely way too late for that idea now though.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Wed, Apr 28, 2021 at 11:41:25AM +0300, Laurent Pinchart wrote:
> Hi Greg,
>
> On Wed, Apr 28, 2021 at 09:18:03AM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Apr 22, 2021 at 10:08:45AM +0200, Ulf Hansson wrote:
> > > On Wed, 21 Apr 2021 at 15:19, Laurent Pinchart wrote:
> > > > On Wed, Apr 21, 2021 at 02:59:23PM +0200, Greg Kroah-Hartman wrote:
> > > > > This reverts commit 611025983b7976df0183390a63a2166411d177f1.
> > > > >
> > > > > 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.
> > > > >
> > > > > Cc: Kangjie Lu <[email protected]>
> > > > > Cc: Laurent Pinchart <[email protected]>
> > > > > Cc: Ulf Hansson <[email protected]>
> > > > > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > > >
> > > > Acked-by: Laurent Pinchart <[email protected]>
> > > >
> > > > I don't spot an obvious issue with the original patch though.
> > > >
> > > > > ---
> > > > > drivers/mmc/host/mmc_spi.c | 4 ----
> > > > > 1 file changed, 4 deletions(-)
> > > > >
> > > > > diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
> > > > > index 02f4fd26e76a..cc40b050e302 100644
> > > > > --- a/drivers/mmc/host/mmc_spi.c
> > > > > +++ b/drivers/mmc/host/mmc_spi.c
> > > > > @@ -800,10 +800,6 @@ mmc_spi_readblock(struct mmc_spi_host *host, struct spi_transfer *t,
> > > > > }
> > > > >
> > > > > status = spi_sync_locked(spi, &host->m);
> > > > > - if (status < 0) {
> > > > > - dev_dbg(&spi->dev, "read error %d\n", status);
> > > > > - return status;
> > > > > - }
> > >
> > > Returning here means we never give back the ownership of the buffer to
> > > the CPU. Can that be considered as vulnerability?
> >
> > It's a "resource leak", which is a bug. If you want to declare that as
> > a "vulnerability" or not, I do not know. Personally I do not think it
> > is...
>
> How is that a resource leak ? The dma_sync_single_for_device() calls
> above this block don't take the buffer ownership away from the CPU in a
> way that leaks it.
Ick, this is really twisty.
The calls to dma_sync_single_for_device() call down to
dma_direct_sync_single_for_device() for when you can directly talk to
the hardware, or to the platform sync_single_for_device() callback for
arches that can not.
Those are messy, but the worst they all seem to do is invalidate or
flush some caches, no type of resource allocation that I could determine
here.
So I'll trust you, and drop the revert and mark this one as "good
patch" :)
Thanks again for the review, much appreciated.
greg k-h
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 <[email protected]>
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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> Cc: Aditya Pakki <[email protected]>
> Cc: Hans Verkuil <[email protected]>
> Cc: Mauro Carvalho Chehab <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> ---
> drivers/media/common/saa7146/saa7146_fops.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/common/saa7146/saa7146_fops.c b/drivers/media/common/saa7146/saa7146_fops.c
> index baf5772c52a9..c256146fd3b6 100644
> --- a/drivers/media/common/saa7146/saa7146_fops.c
> +++ b/drivers/media/common/saa7146/saa7146_fops.c
> @@ -95,6 +95,8 @@ void saa7146_buffer_finish(struct saa7146_dev *dev,
> DEB_EE("dev:%p, dmaq:%p, state:%d\n", dev, q, state);
> DEB_EE("q->curr:%p\n", q->curr);
>
> + BUG_ON(!q->curr);
> +
> /* finish current buffer */
> if (NULL == q->curr) {
> DEB_D("aiii. no current buffer\n");
The code is obviously crazy _after_ the revert, so I'd suggest not
reverting it.
But whether this code has any security problems is quite hard to
decide, it was not written with readability in mind :-(.
Pavel
--
http://www.livejournal.com/~pavelmachek
Hi!
This is no big deal either way, and I doubt it is malicious. It will
only hit during development. Returning error is more in line with
linux style.
I'd suggest keeping it.
Best regards,
Pavel
ci/vpfe_capture.c
> index f9f7dd17c57c..bcedaf4523e0 100644
> --- a/drivers/media/platform/davinci/vpfe_capture.c
> +++ b/drivers/media/platform/davinci/vpfe_capture.c
> @@ -168,22 +168,21 @@ int vpfe_register_ccdc_device(const struct ccdc_hw_device *dev)
> int ret = 0;
> printk(KERN_NOTICE "vpfe_register_ccdc_device: %s\n", dev->name);
>
> - if (!dev->hw_ops.open ||
> - !dev->hw_ops.enable ||
> - !dev->hw_ops.set_hw_if_params ||
> - !dev->hw_ops.configure ||
> - !dev->hw_ops.set_buftype ||
> - !dev->hw_ops.get_buftype ||
> - !dev->hw_ops.enum_pix ||
> - !dev->hw_ops.set_frame_format ||
> - !dev->hw_ops.get_frame_format ||
> - !dev->hw_ops.get_pixel_format ||
> - !dev->hw_ops.set_pixel_format ||
> - !dev->hw_ops.set_image_window ||
> - !dev->hw_ops.get_image_window ||
> - !dev->hw_ops.get_line_length ||
> - !dev->hw_ops.getfid)
> - return -EINVAL;
> + BUG_ON(!dev->hw_ops.open);
> + BUG_ON(!dev->hw_ops.enable);
> + BUG_ON(!dev->hw_ops.set_hw_if_params);
> + BUG_ON(!dev->hw_ops.configure);
> + BUG_ON(!dev->hw_ops.set_buftype);
> + BUG_ON(!dev->hw_ops.get_buftype);
> + BUG_ON(!dev->hw_ops.enum_pix);
> + BUG_ON(!dev->hw_ops.set_frame_format);
> + BUG_ON(!dev->hw_ops.get_frame_format);
> + BUG_ON(!dev->hw_ops.get_pixel_format);
> + BUG_ON(!dev->hw_ops.set_pixel_format);
> + BUG_ON(!dev->hw_ops.set_image_window);
> + BUG_ON(!dev->hw_ops.get_image_window);
> + BUG_ON(!dev->hw_ops.get_line_length);
> + BUG_ON(!dev->hw_ops.getfid);
>
> mutex_lock(&ccdc_lock);
> if (!ccdc_cfg) {
--
http://www.livejournal.com/~pavelmachek
Hi!
i2c.c
> index c6659253c6fb..f33b6a077d57 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-i2c.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-i2c.c
> @@ -515,8 +515,7 @@ int cx231xx_i2c_register(struct cx231xx_i2c *bus)
> {
> struct cx231xx *dev = bus->dev;
>
> - if (!dev->cx231xx_send_usb_command)
> - return -EINVAL;
> + BUG_ON(!dev->cx231xx_send_usb_command);
>
> bus->i2c_adap = cx231xx_adap_template;
> bus->i2c_adap.dev.parent = dev->dev;
No big deal either way, and this will only be hit during
development. Linus does not like BUGs, so I'd keep this.
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
Hi!
I doubt this is malicious, and BUG()s are ugly. I'd suggest keeping
this.
Best regards,
Pavel
> diff --git a/drivers/media/common/saa7146/saa7146_video.c b/drivers/media/common/saa7146/saa7146_video.c
> index 7b8795eca589..d9d7d82ca451 100644
> --- a/drivers/media/common/saa7146/saa7146_video.c
> +++ b/drivers/media/common/saa7146/saa7146_video.c
> @@ -345,8 +345,7 @@ static int video_begin(struct saa7146_fh *fh)
>
> fmt = saa7146_format_by_fourcc(dev, vv->video_fmt.pixelformat);
> /* we need to have a valid format set here */
> - if (!fmt)
> - return -EINVAL;
> + BUG_ON(NULL == fmt);
>
> if (0 != (fmt->flags & FORMAT_IS_PLANAR)) {
> resource = RESOURCE_DMA1_HPS|RESOURCE_DMA2_CLP|RESOURCE_DMA3_BRS;
> @@ -399,8 +398,7 @@ static int video_end(struct saa7146_fh *fh, struct file *file)
>
> fmt = saa7146_format_by_fourcc(dev, vv->video_fmt.pixelformat);
> /* we need to have a valid format set here */
> - if (!fmt)
> - return -EINVAL;
> + BUG_ON(NULL == fmt);
>
> if (0 != (fmt->flags & FORMAT_IS_PLANAR)) {
> resource = RESOURCE_DMA1_HPS|RESOURCE_DMA2_CLP|RESOURCE_DMA3_BRS;
--
http://www.livejournal.com/~pavelmachek
Hi!
> drivers/gpu/drm/gma500/cdv_intel_display.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c b/drivers/gpu/drm/gma500/cdv_intel_display.c
> index 5d3302249779..f89c2088dc2d 100644
> --- a/drivers/gpu/drm/gma500/cdv_intel_display.c
> +++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
> @@ -405,8 +405,6 @@ static bool cdv_intel_find_dp_pll(const struct gma_limit_t *limit,
> struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
> struct gma_clock_t clock;
>
> - memset(&clock, 0, sizeof(clock));
> -
> switch (refclk) {
> case 27000:
> if (target < 200000) {
Original description is correct, we are returning with .vco and .dot
unitialized which is at least very very ugly, so we should keep the
memset and not revert this.
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
> On Apr 27, 2021, at 10:46 PM, Greg Kroah-Hartman <[email protected]> wrote:
>
> On Wed, Apr 21, 2021 at 03:00:09PM +0200, Greg Kroah-Hartman wrote:
>> This reverts commit e406f12dde1a8375d77ea02d91f313fb1a9c6aec.
>>
>> 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.
>>
>> Cc: [email protected] # v3.16+
>> Cc: Guoqing Jiang <[email protected]>
>> Cc: Aditya Pakki <[email protected]>
>> Cc: Song Liu <[email protected]>
>> Signed-off-by: Greg Kroah-Hartman <[email protected]>
>> ---
>> drivers/md/raid10.c | 2 --
>> drivers/md/raid5.c | 2 --
>> 2 files changed, 4 deletions(-)
>>
>> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
>> index a9ae7d113492..4fec1cdd4207 100644
>> --- a/drivers/md/raid10.c
>> +++ b/drivers/md/raid10.c
>> @@ -3896,8 +3896,6 @@ static int raid10_run(struct mddev *mddev)
>> set_bit(MD_RECOVERY_RUNNING, &mddev->recovery);
>> mddev->sync_thread = md_register_thread(md_do_sync, mddev,
>> "reshape");
>> - if (!mddev->sync_thread)
>> - goto out_free_conf;
>> }
>>
>> return 0;
>> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
>> index 5d57a5bd171f..9b2bd50beee7 100644
>> --- a/drivers/md/raid5.c
>> +++ b/drivers/md/raid5.c
>> @@ -7677,8 +7677,6 @@ static int raid5_run(struct mddev *mddev)
>> set_bit(MD_RECOVERY_RUNNING, &mddev->recovery);
>> mddev->sync_thread = md_register_thread(md_do_sync, mddev,
>> "reshape");
>> - if (!mddev->sync_thread)
>> - goto abort;
>> }
>>
>> /* Ok, everything is just fine now */
>> --
>> 2.31.1
>>
>
> These changes look ok, but the error handling logic seems to be freeing
> the incorrect thread, not the one that these functions create. That's
> independant of this change, but seems odd. If someone cares about it,
> it should probably be looked at, or if correct, a comment would be nice
> as it's really confusing.
I don't think this is confusing. raid[5|10]_run() creates two threads:
first mddev->thread, then mddev->sync_thread. If we fail to create the
second thread (sync_thread), we free the first thread (mddev->thread) in
the error handling logic.
Thanks,
Song
On Fri, Apr 30, 2021 at 06:10:24AM +0000, Song Liu wrote:
>
>
> > On Apr 27, 2021, at 10:46 PM, Greg Kroah-Hartman <[email protected]> wrote:
> >
> > On Wed, Apr 21, 2021 at 03:00:09PM +0200, Greg Kroah-Hartman wrote:
> >> This reverts commit e406f12dde1a8375d77ea02d91f313fb1a9c6aec.
> >>
> >> 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.
> >>
> >> Cc: [email protected] # v3.16+
> >> Cc: Guoqing Jiang <[email protected]>
> >> Cc: Aditya Pakki <[email protected]>
> >> Cc: Song Liu <[email protected]>
> >> Signed-off-by: Greg Kroah-Hartman <[email protected]>
> >> ---
> >> drivers/md/raid10.c | 2 --
> >> drivers/md/raid5.c | 2 --
> >> 2 files changed, 4 deletions(-)
> >>
> >> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> >> index a9ae7d113492..4fec1cdd4207 100644
> >> --- a/drivers/md/raid10.c
> >> +++ b/drivers/md/raid10.c
> >> @@ -3896,8 +3896,6 @@ static int raid10_run(struct mddev *mddev)
> >> set_bit(MD_RECOVERY_RUNNING, &mddev->recovery);
> >> mddev->sync_thread = md_register_thread(md_do_sync, mddev,
> >> "reshape");
> >> - if (!mddev->sync_thread)
> >> - goto out_free_conf;
> >> }
> >>
> >> return 0;
> >> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> >> index 5d57a5bd171f..9b2bd50beee7 100644
> >> --- a/drivers/md/raid5.c
> >> +++ b/drivers/md/raid5.c
> >> @@ -7677,8 +7677,6 @@ static int raid5_run(struct mddev *mddev)
> >> set_bit(MD_RECOVERY_RUNNING, &mddev->recovery);
> >> mddev->sync_thread = md_register_thread(md_do_sync, mddev,
> >> "reshape");
> >> - if (!mddev->sync_thread)
> >> - goto abort;
> >> }
> >>
> >> /* Ok, everything is just fine now */
> >> --
> >> 2.31.1
> >>
> >
> > These changes look ok, but the error handling logic seems to be freeing
> > the incorrect thread, not the one that these functions create. That's
> > independant of this change, but seems odd. If someone cares about it,
> > it should probably be looked at, or if correct, a comment would be nice
> > as it's really confusing.
>
> I don't think this is confusing. raid[5|10]_run() creates two threads:
> first mddev->thread, then mddev->sync_thread. If we fail to create the
> second thread (sync_thread), we free the first thread (mddev->thread) in
> the error handling logic.
Look a bit lower, in "abort:" you do clean up "->thread", but never
"->sync_thread" You can get to "abort:" after sync_thread is properly
registered.
That is what I was trying to say above, as it's not obvious because
"->thread" was created in a different function, setup_conf(), to see it
be freed here in the error path of raid[5|10]_run() wasn't all that
clear to me.
Anyway, these are code paths that are obviously never hit, so it's
probably not a big deal.
thanks,
greg k-h
On Tue, Apr 27, 2021 at 08:13:25PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 21, 2021 at 03:00:44PM +0200, Greg Kroah-Hartman wrote:
> > This reverts commit ff07d48d7bc0974d4f96a85a4df14564fb09f1ef.
> >
> > 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.
> >
> > Cc: Kangjie Lu <[email protected]>
> > Cc: David S. Miller <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
> > ---
> > drivers/net/ethernet/atheros/atl1e/atl1e_main.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
> > index ff9f96de74b8..85f9cb769e30 100644
> > --- a/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
> > +++ b/drivers/net/ethernet/atheros/atl1e/atl1e_main.c
> > @@ -455,9 +455,7 @@ static void atl1e_mdio_write(struct net_device *netdev, int phy_id,
> > {
> > struct atl1e_adapter *adapter = netdev_priv(netdev);
> >
> > - if (atl1e_write_phy_reg(&adapter->hw,
> > - reg_num & MDIO_REG_ADDR_MASK, val))
> > - netdev_err(netdev, "write phy register failed\n");
> > + atl1e_write_phy_reg(&adapter->hw, reg_num & MDIO_REG_ADDR_MASK, val);
> > }
> >
> > static int atl1e_mii_ioctl(struct net_device *netdev,
> > --
> > 2.31.1
> >
>
> The original change here is a mess, what is a user supposed to do if
> this call fails? I will revert it and properly pass the error value up
> to the callers, as that is the correct thing to do here, not paper over
> the issue with a commit message that claims this change "fixes"
> anything.
In looking at this further, Du has pointed out to me that the
atl1e_mdio_write function can not easily be changed to return an error
value, because that would require all callbacks for mdio_write in struct
mii_if_info would need to be changed and handled properly.
So the original commit was as correct as is possible at the moment,
making a much larger change like this really isn't needed, so I'll drop
the revert.
thanks to Du Cheng for the additional review, it is much appreciated.
greg k-h
On Thu, Apr 29, 2021 at 10:23:01PM +0200, Pavel Machek wrote:
> Hi!
>
> > drivers/gpu/drm/gma500/cdv_intel_display.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c b/drivers/gpu/drm/gma500/cdv_intel_display.c
> > index 5d3302249779..f89c2088dc2d 100644
> > --- a/drivers/gpu/drm/gma500/cdv_intel_display.c
> > +++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
> > @@ -405,8 +405,6 @@ static bool cdv_intel_find_dp_pll(const struct gma_limit_t *limit,
> > struct gma_crtc *gma_crtc = to_gma_crtc(crtc);
> > struct gma_clock_t clock;
> >
> > - memset(&clock, 0, sizeof(clock));
> > -
> > switch (refclk) {
> > case 27000:
> > if (target < 200000) {
>
> Original description is correct, we are returning with .vco and .dot
> unitialized which is at least very very ugly, so we should keep the
> memset and not revert this.
Good point, revert now dropped, thanks.
greg k-h